SOFTWAREENTWICKLUNG MIT CLAUDE

Die Softwareentwicklung im Jahr 2026 mit Claude als wichtigstem technischen Partner verändert die Kostenkurve und die Zusammensetzung des Teams, nicht jedoch das zugrunde liegende Handwerk. Die entscheidungsintensiven Aspekte der Softwareentwicklung (was entwickelt werden soll, warum und wie sich die Software im Fehlerfall verhalten soll) erfordern nach wie vor menschliche Aufmerksamkeit. Die ausführenden Aufgaben (Code schreiben, Refactoring, Generieren von Boilerplate-Code, Durchführen von Migrationen) lassen sich hingegen drastisch reduzieren. Zu wissen, was was ist, macht im Jahr 2026 die gesamte Kompetenz aus.

Dieser Guide ist der Workflow, den ich bei Seahawk Media zum Versand von Custom-Produkten nutzte und noch immer auf persönlichen Projekten wie HostList.io, gautamkhorana.com und Deluxe Astrology nutze. Kein Claude-Tutorial, kein Prompt-Engineering-Manual. Die Prozessdisziplin, die versandfähige Software mit Claude als tragender Ingenieur hervorbringt.

Phase 1: Strukturiertes Brainstorming

Bevor ich auch nur eine Zeile Code schreibe, führe ich mit Claude ein strukturiertes Brainstorming durch. Die Vorgabe lautet: Beschreibe das Problem in einfacher Sprache, bitte Claude, fünf Fragen zu formulieren, deren Antworten das Design verändern würden, beantworte diese Fragen und bitte Claude anschließend, die daraus resultierende Produktspezifikation in 200 Wörtern zusammenzufassen. Diese Phase dauert 30 bis 60 Minuten und liefert eine schriftliche Spezifikation, auf der die weitere Arbeit aufbaut.

Phase 2: Technische Entscheidungen

Mit den Spezifikationen in der Hand bitte ich Claude, die Architekturentscheidungen zu identifizieren, die im weiteren Verlauf am stärksten zum Tragen kommen. Datenbankstruktur, API-Oberfläche, Rendering-Strategie, Bereitstellungsmodell. Für jeden Punkt schlägt Claude zwei oder drei Optionen sowie die jeweiligen Vor- und Nachteile vor. Ich treffe die Auswahl. Die Entscheidungen werden im selben Dokument festgehalten, sodass für die Entwicklungsphase eine einzige verlässliche Informationsquelle zur Verfügung steht.

Phase 3: Spezifikationsgestützte Umsetzung

Die Codegenerierung ist der letzte Schritt und verläuft am schnellsten, da die Spezifikation bereits vollständig ist. Claude schreibt das Schema, die Abfragen, die Komponenten, die Routen und die Tests – in etwa in dieser Reihenfolge. Ich überprüfe jeden Commit. Bei den meisten Überprüfungen fallen kleine Refactorings oder fehlende Randfälle auf; vollständige Neuprogrammierungen sind selten, wenn die Spezifikation klar war.

Das Wichtigste auf einen Blick: Betrachten Sie den „Workflow vom Brainstorming bis zur Spezifikation“ in erster Linie als operative Entscheidung. Die Tools funktionieren nur, wenn die Verantwortlichkeiten klar geregelt sind.

Hervorragend geeignet für

Neuentwicklung von Code nach bewährten Mustern: REST-APIs, CRUD-Admin-Panels, Authentifizierungsabläufe, Blog-Engines, Marketing-Websites. Refactoring von bestehendem Code, wenn die Zielstruktur klar definiert ist. Erstellen von Tests für Code mit eindeutigen Ein- und Ausgabewerten. Schreiben von Migrationsskripten, wenn die Schema-Differenz eindeutig ist. Erstellen von Dokumentation. Debuggen von Code, bei dem das Symptom reproduzierbar ist und der Ablaufkontext klar ist.

Nicht so gut in

Architektonische Entscheidungen in unbekannten Bereichen. Integrationscode, bei dem die API eines Drittanbieters nur unzureichend dokumentiert ist oder kürzlich geändert wurde. Leistungsoptimierung, bei der der Engpass nicht offensichtlich ist. Codegenerierung in wenig verbreiteten Sprachen oder Frameworks, für die nur wenige Trainingsdaten vorliegen. Alles, wo die Anforderungen mehrdeutig sind und das LLM plausibel klingende Standardwerte vorschlägt, die für Ihren konkreten Fall jedoch falsch sind.

Die Urteilslücke

Claude ist beim Schreiben der nächsten Codezeile durchweg besser als der durchschnittliche Entwickler. Claude ist bei der Entscheidung, ob die nächste Codezeile überhaupt geschrieben werden sollte, durchweg schlechter als ein erfahrener Entwickler. Die Erfahrung und das Urteilsvermögen bringen Sie ein. Die Ausführungsgeschwindigkeit bringt Claude ein. Diese Kombination ist besser als jede der beiden Komponenten für sich allein.

Claude Code als primäre Oberfläche

Claude Code ist die IDE für KI-gestützte Entwicklung. Einmaliges Laden des Projektkontexts, Terminalzugriff, Dateisystemzugriff, MCP-Tool-Integration. Das Tool, das ich 2025 in mein Arbeitsumfeld aufgenommen habe und das ich am häufigsten nutze. Der Großteil der Entwicklungsarbeit findet mittlerweile in Claude Code statt und nicht mehr direkt in VS Code oder Cursor.

Cursor für direkte Bearbeitungen im Editor

Cursor bietet nach wie vor das beste Editor-Erlebnis für die Zusammenarbeit mit KI an einer einzelnen Datei. Tab-Vervollständigung, Inline-Bearbeitung, Side-by-Side-Diff. Ich nutze Cursor, wenn sich die Arbeit auf eine oder zwei Dateien konzentriert; ich wechsle zu Claude Code, wenn sich die Arbeit über das gesamte Projekt erstreckt.

Claude Sonnet über die API für die Stapelverarbeitung

Wenn ich Hunderte von Seiten programmgesteuert generieren oder umschreiben muss (Auto-Blog-Pipeline, Humanisierung von Inhalten, Schema-Generierung), rufe ich die Claude-API direkt über Sonnet auf. Geringere Latenz als bei der Chat-Oberfläche, vorhersehbare Kosten, skriptfähig. Das richtige Tool speziell für Content-Pipelines.

OpenAI GPT-4o für das Prompt-Engineering

Ende 2025 stellte ich fest, dass Prompts für Kimi, Minimax oder jeden anderen Agenten am besten von Claude oder GPT verfasst werden und nicht von Hand. Ich beschreibe das Ziel, bitte GPT-4o, den Prompt zu verfassen, und lasse diesen Prompt dann vom Executor ausführen. Die Qualität der Ausgabe ist deutlich besser als bei manuell verfassten Prompts.

Kimi-Forscher und Minimax-Agent

Tiefgehende Recherche und vollständige App-Design-Mockups entsprechend. Der Post /blog/kimi-minimax-deep-research-design-mockups/ deckt den gesamten Workflow ab. Beide waren tragende Werkzeuge bei Seahawk für Kundenrecherche und schnelle Prototypisierung.

Kleine Commits, aussagekräftige Nachrichten

Bei der KI-gestützten Entwicklung entstehen häufig große Diffs, da es leicht passieren kann, dass 800 Zeilen generierten Codes in einem einzigen Commit übermittelt werden. Zwinge dich dazu, kleinere Commits zu erstellen. Eine Commit-Meldung, die beschreibt, was sich geändert hat und warum, ist das einzige Hilfsmittel, das dir in Zukunft zur Verfügung stehen wird, um eine Regression zu beheben. Achte darauf, dass sie gut lesbar ist.

Tests als Vertrag

Claude kann Code schreiben, der sich kompilieren lässt und läuft, dabei jedoch unbemerkt gegen eine in der Spezifikation implizit enthaltene Einschränkung verstößt. Tests, die diese Einschränkungen als ausführbare Verträge kodieren, decken solche Verstöße auf. Die „Test-First“-Methode ist im Zeitalter der KI-Unterstützung von größerer Bedeutung als zu Zeiten, als noch Menschen jede einzelne Zeile geschrieben haben.

Die Code-Prüfung wird vorerst ausschließlich von Menschen durchgeführt.

Ich lasse Claude seine eigenen Pull-Anfragen nicht genehmigen. Die Überprüfung ist die wichtigste Qualitätskontrolle, die noch dem Menschen vorbehalten ist, und sie an dasselbe Modell auszulagern, das den Code geschrieben hat, würde den Zweck verfehlen. Das Anthropic SDK und die Claude Code-Workflows erleichtern die KI-gestützte Überprüfung, aber die endgültige Genehmigung liegt bei mir.

Versionsgebundene Abhängigkeiten und Lockfiles

Fixieren Sie jede Abhängigkeit. Verwenden Sie Lockfiles. Führen Sie bei jedem Build ein „npm audit“ durch. Die Angriffsfläche der Lieferkette ist real, und bei der KI-gestützten Entwicklung kommen tendenziell mehr Abhängigkeiten hinzu als bei von Menschen geschriebenen Äquivalenten, da das Hinzufügen eines Pakets schnell geht. Durch die konsequente Verwendung von Lockfiles bleibt die Angriffsfläche überprüfbar.

Das Wichtigste auf einen Blick: Betrachten Sie „Repository-Disziplin, die auch bei KI-gestützter Entwicklung Bestand hat“ in erster Linie als operative Entscheidung. Die Tools funktionieren nur, wenn die Zuständigkeiten klar geregelt sind.

Fünf Entscheidungsbereiche, in denen Claude nicht das richtige Werkzeug ist:

Was soll überhaupt entwickelt werden? Die Produktentscheidung erfordert viel Urteilsvermögen, hängt vom Nutzungskontext ab – über den Claude keine Informationen hat – und ist die Entscheidung mit den weitreichendsten Konsequenzen bei jedem Produkt. Die Verantwortung dafür liegt bei den Gründern und Produktmanagern; die KI kann hier höchstens unterstützend wirken.

Was soll eingeführt und was gestrichen werden? Entscheidungen über den Umfang während der Entwicklung hängen immer von Einschränkungen ab, die das Modell nicht berücksichtigt. Zeitdruck, Teammoral, Partnerbeziehungen, Marketingpositionierung. Entscheiden Sie als Mensch, dokumentieren Sie die Begründung und beauftragen Sie dann Claude mit der Umsetzung des festgelegten Umfangs.

Auslegungsansatz für Fehlerfälle. Wie sich das System verhalten soll, wenn etwas schiefgeht, wird selten im Vorfeld festgelegt – und genau hier liegen die Ursachen für die meisten Produktionsstörungen. Widmen Sie den Fehlerfällen unverhältnismäßig viel Zeit; sie ergeben sich nicht von selbst aus der Codegenerierung für den „Happy Path“.

Die ethische Ebene. Was Sie entwickeln, hat Konsequenzen. Datenschutz, Datenstandort, Barrierefreiheit, Umweltkosten. Das sind menschliche Entscheidungen, keine Ergebnisse von Optimierungsverfahren. Stellen Sie diese Frage bereits in der Entwurfsphase ausdrücklich.

Langfristige Wartbarkeit. Wenn das zukünftige Ich den Code des zukünftigen Claude liest, der wiederum den Code des gegenwärtigen Claude liest, ist das die extremste Form technischer Schulden. Optimieren Sie den aktuellen Code so, dass er in erster Linie für Menschen lesbar ist – erst in zweiter Linie für KI.

Konkrete Beispiele aus meinen letzten zwölf Monaten bei Seahawk und aus persönlichen Projekten:

HostList.io (28.000 programmatisch generierte Seiten auf Next.js + Supabase): Innerhalb von fünf Tagen mit Claude Code erstellt, Inhaltspipeline von Claude geschrieben mit Tavily-Rechercheintegration, Hero-Generierung über FAL, Schema-Markup automatisch generiert. Der gesamte Entwicklungsaufwand betrug etwa ein Drittel dessen, was ich vor drei Jahren geschätzt hätte.

gautamkhorana.com (diese Website, auf Astro + Supabase): an einem Wochenende innerhalb von 24 Stunden neu erstellt, wobei Claude Code der wichtigste Mitwirkende war. Die Benutzeroberfläche des Website-Editors, das Blog-System, die Schema-Ebene und die i18n-Funktionen wurden alle generiert, überprüft und überarbeitet. Der Aufwand für die Erstellung einer persönlichen Website in dieser Qualität hat sich auf ein Wochenende konzentrierter Arbeit reduziert.

Deluxe Astrology Auto-Blog und Übersetzungspipeline: Der Kreislauf „Tavily-Recherche – Claude-Entwurf – Winston-Prüfung – FAL-Hero – Supabase-Veröffentlichung“ läuft täglich in 30 Sprachen auf über 91.000 Seiten. Die Pipeline selbst umfasst etwa 800 Zeilen Claude Code, die Claude in rund 12 Stunden konzentrierter Arbeit geschrieben hat – ein Großteil davon hätte bei einem rein menschlichen Team eine Woche gedauert.

Interne Admin-Dashboards bei Seahawk: Minimax Agent erstellt anhand einer sechszeiligen Beschreibung einen ersten Prototyp, Claude verfeinert diesen, und das Ergebnis ist innerhalb einer Stunde einsatzbereit. Die Zeit von „Wir brauchen ein internes Tool“ bis „Wir nutzen das interne Tool“ hat sich von mehreren Tagen auf weniger als einen Arbeitstag verkürzt.

Die Entwicklung maßgeschneiderter Software im Jahr 2026 ist ein Handwerk, bei dem sich die Ausführungsgeschwindigkeit um eine Größenordnung verkürzt hat, während die Komplexität der Entscheidungsfindung in etwa konstant geblieben ist. Die Teams, die sich anpassen, sind diejenigen, die mehr Entscheidungsarbeit leisten (bessere Spezifikationen, bessere Architekturentscheidungen, besseres Design hinsichtlich Fehlermodi) und die Ausführung stärker an KI auslagern. Die Teams, die sich nicht anpassen, produzieren Software in wettbewerbsfähiger Geschwindigkeit, büßen jedoch an Qualität ein – oder umgekehrt.

Sie müssen nicht jedes Werkzeug aus diesem Leitfaden verwenden. Sie müssen jedoch wissen, welche Entscheidungen Sie selbst treffen müssen und welche Sie delegieren können. Die Kompetenz liegt in der Abgrenzung, nicht in der Werkzeugkette.

Falls du Hilfe beim Versand eines Custom-Software-Projekts bei dieser Kostenstruktur willst, führe ich Produktentwicklungen direkt durch. Das Gespräch ist kostenlos; die Projektpreisgestaltung spiegelt die KI-unterstützte Kostenrealität wider, nicht die 2018er Stundenhonorar-Realität.

Das Wichtigste auf einen Blick: Betrachten Sie „das Endergebnis“ in erster Linie als operative Entscheidung. Das Instrumentarium funktioniert nur, wenn die Verantwortlichen ehrlich sind.