Noch nie war es so einfach, Software zu entwickeln – und gleichzeitig so leicht, ein Projekt in eine falsche Richtung laufen zu lassen. Moderne Coding Agents erzeugen in wenigen Minuten Hunderte Zeilen Code. Was sie jedoch nicht ersetzen, ist ein gemeinsames Verständnis davon, was überhaupt gebaut werden soll.
Ein Coding Agent kann eine Aufgabe brillant lösen – aber nur die Aufgabe, die er kennt. Was er nicht kennt, entscheidet er selbst, plausibel und konsequent, und oft an drei verschiedenen Stellen unterschiedlich. Das Ergebnis sieht dann nicht nach schlechter Arbeit aus. Es sieht nach drei verschiedenen Meinungen darüber aus, was das Produkt eigentlich ist.
Dieser Leitfaden beschreibt den Weg von der ersten Idee bis zum ersten Implementierungs-Prompt – nicht als starre 18-Punkte-Checkliste, sondern als sechs Etappen, die aufeinander aufbauen. Jede Etappe klärt Fragen, die sonst der Agent für dich beantwortet. Am Ende steht ein kurzer Abschnitt dazu, wann man sich einen Teil davon sparen kann.
Etappe 1: Problem und Vision
Warum das zuerst kommt: Ein Agent, der die Lösung kennt, aber nicht das Problem dahinter, trifft bei jeder Detailentscheidung eine Münzwurf-Wahl. Er weiß nicht, ob eine Funktion Kernnutzen oder Nebensache ist – und behandelt beides gleich sorgfältig, oder gleich nachlässig.
Leitfragen:
- Welches konkrete Problem löst die Software, und für wen?
- Warum reichen bestehende Lösungen dafür nicht aus?
- Wer nutzt die Software – mit welchem Vorwissen, welchen Zielen, welchen Einschränkungen?
Ergebnis: Ein Problem Statement in drei bis fünf Sätzen und eine kurze Beschreibung der wichtigsten Nutzergruppe(n). Kein Pflichtenheft, keine Feature-Liste – nur die Frage “warum entsteht das hier überhaupt” beantwortet, so konkret wie möglich. “Verwaltung digitalisieren” ist noch kein Problem Statement, “eine bestimmte Aufgabe dauert aktuell zu lange, weil zu viele Personen manuell eingreifen müssen” schon eher.
Etappe 2: Fachliches Modell
Warum das zuerst kommt, bevor Technik ins Spiel kommt: Ein Datenmodell, das aus einer unklaren Fachlichkeit entsteht, überträgt die Unklarheit eins zu eins in die Datenbank – nur schwerer wieder änderbar.
Leitfragen:
- Welche fachlichen Objekte gibt es, und wie hängen sie zusammen?
- Welche Regeln gelten zwischen ihnen – was ist Pflicht, was optional, was schließt sich aus?
- Wo verlaufen die Grenzen zwischen unabhängigen Teilbereichen des Systems?
Ergebnis: Eine Skizze der zentralen Entitäten mit ihren Beziehungen (kein vollständiges ER-Diagramm, aber mehr als Stichworte) und eine kurze Liste offener fachlicher Fragen, die noch nicht beantwortet sind.
Scheinbar kleine Detailfragen gehören explizit in diese Liste, nicht ins Prompten hinein verschoben. Eine Frage wie “kann aus dieser Auswahl nur eine oder mehrere Optionen gewählt werden” wirkt trivial, verzweigt sich aber in mehrere technische Entscheidungen zugleich – Datenmodell, Berechnungslogik, Datenbankbeziehung, Oberfläche. Bleibt sie unbeantwortet, wird sie an jeder dieser Stellen einzeln und womöglich unterschiedlich beantwortet.
Etappe 3: Anforderungen und Prozesse
Warum diese Etappe eigenständig ist: Fachliches Modell und Anforderungen werden oft vermischt. Das Modell beschreibt, was existiert. Die Anforderungen beschreiben, was damit passieren muss – als Abläufe und als Qualitätsmerkmale.
Leitfragen:
- Welche Abläufe durchläuft ein typischer Nutzungsfall, Schritt für Schritt?
- Was muss die Software leisten, das nicht direkt sichtbar ist – Performance, Sicherheit, Datenschutz, Nachvollziehbarkeit?
- Welche Randfälle und Fehlerfälle sind bekannt, bevor der erste Code entsteht?
Ergebnis: Für die wichtigsten zwei oder drei Abläufe eine kurze Schritt-für-Schritt-Beschreibung, plus eine kurze Liste nichtfunktionaler Anforderungen, die tatsächlich relevant sind – nicht eine Standardliste, die für jedes Projekt gleich aussieht.
Etappe 4: Architektur und Schnittstellen
Warum erst jetzt über Technik gesprochen wird: Eine Architekturentscheidung, die vor dem fachlichen Modell fällt, optimiert für ein Problem, das man noch gar nicht vollständig verstanden hat.
Leitfragen:
- Welche Architektur passt zur erwarteten Lebensdauer und Komplexität – und warum genau diese?
- Wie sehen die Schnittstellen zwischen den Teilen des Systems aus, insbesondere wenn mehrere Komponenten oder Erweiterungen zusammenspielen?
- Wie sind Rollen, Rechte und Zugriffsgrenzen geregelt?
Ergebnis: Eine kurze, begründete Architekturentscheidung – nicht “wir nutzen Hexagonal Architecture”, sondern der Satz danach: weil. Eine solche Begründung, einmal explizit gemacht, beantwortet im Nachhinein zahlreiche Detailfragen beim Prompten automatisch mit, ohne dass sie einzeln gestellt werden müssten.
Etappe 5: Umsetzungsplanung
Warum diese Etappe den Unterschied macht, ob ein Agent autonom arbeiten kann: Ein Arbeitspaket, das mehrere unausgesprochene Teilentscheidungen enthält, zwingt den Agenten dazu, sie selbst zu treffen. Ein Arbeitspaket, das auf eine einzige, klar umrissene Änderung reduziert ist, kann er zuverlässig umsetzen und du kannst das Ergebnis in wenigen Minuten prüfen.
Leitfragen:
- Lässt sich das Arbeitspaket in einem Satz beschreiben, ohne “und” zu benötigen?
- Welche Dateien, Klassen oder Tabellen sind konkret betroffen?
- Woran erkennt man, dass die Aufgabe fertig ist – welcher Test, welches sichtbare Verhalten?
Ergebnis: Eine Liste kleiner, unabhängig umsetzbarer Arbeitspakete statt einer großen Aufgabe wie “die Registrierung bauen”. Für jedes Paket reicht ein kurzer Prompt, der Ziel, betroffene Stellen und ein Abnahmekriterium benennt.
Etappe 6: Qualitätssicherung und Roadmap
Warum das nicht erst am Ende kommt: Eine Teststrategie, die erst nach der Implementierung entsteht, testet, was gebaut wurde – nicht, was gebaut werden sollte. Beides kann auseinanderfallen, ohne dass es auffällt.
Leitfragen:
- Wie wird geprüft, dass ein Arbeitspaket tatsächlich das tut, was die Etappen davor festgelegt haben?
- Was gehört in die erste Version, was kann bewusst später kommen?
Ergebnis: Eine grobe Testabdeckung pro Arbeitspaket, bereits mitgedacht beim Zuschnitt der Aufgaben, und eine Einteilung in MVP und spätere Ausbaustufen.
Wo die Etappen landen: Artefakte für Claude Code
Die sechs Etappen sind ein Denkprozess. Ein Coding Agent wie Claude Code braucht daraus aber keine sechs Dokumente, sondern vier konkrete Artefakte, in denen sich die Ergebnisse der Etappen wiederfinden.
CLAUDE.md ist die Datei, die Claude Code zu Beginn jeder Session automatisch liest – das Projektgedächtnis. Hier landet die Essenz aus Etappe 4 (die begründete Architekturentscheidung) und Teile aus Etappe 1, aber bewusst nur das, was dauerhaft und projektweit gilt: Bash-Befehle, Code-Stil-Regeln, Teststrategie, wiederkehrende Stolperfallen. Alles, was Claude auch durch Lesen des Codes selbst herausfinden könnte, gehört nicht hinein – jede zusätzliche Zeile kostet Kontext, und eine überladene CLAUDE.md wird schlechter befolgt als eine kurze.
SPEC.md entsteht pro Feature und deckt Etappe 2 und 3 ab – fachliches Modell und Anforderungen. Der praktische Weg dahin: Claude Code selbst danach fragen lassen, was noch unklar ist, statt die Spezifikation allein am Schreibtisch zu verfassen. Eine bewährte Methode ist, Claude zu bitten, einen im Dialog zu interviewen und erst am Ende alles in einer SPEC.md festzuhalten – das deckt genau die Fragen auf, die man selbst übersehen hätte.
PLAN.md entspricht Etappe 5, nur dass der Plan nicht mehr von Hand geschrieben wird. Claude Code erkundet zunächst den betroffenen Code, ohne etwas zu verändern, schlägt dann einen Umsetzungsplan vor, den man vor der Implementierung noch anpassen kann, und setzt ihn erst danach um. Für kleine, eindeutige Änderungen lohnt sich dieser Zwischenschritt nicht – lässt sich die Änderung in einem Satz beschreiben, kann man ihn überspringen.
Verifikationskriterien sind die technische Übersetzung von Etappe 6. Eine Beschreibung wie “die Funktion soll E-Mail-Adressen validieren” lässt offen, wann die Aufgabe erledigt ist. Ein Kriterium wie ein konkreter Testfall, den Claude nach der Umsetzung selbst ausführen kann, schließt diese Lücke – der Agent arbeitet dann so lange weiter, bis der Test besteht, statt aufzuhören, sobald das Ergebnis plausibel aussieht.
Wiederkehrendes Domänenwissen – etwa feste Konventionen für ein bestimmtes Framework oder Regeln, die nur in einem Teil des Projekts gelten – gehört nicht in die CLAUDE.md, sondern in eigene Skills, die Claude Code nur bei Bedarf lädt. Das hält das Projektgedächtnis schlank, ohne das Wissen zu verlieren.
Wann weniger reicht
Dieser Leitfaden ist kein Ritual, das für jedes Projekt in voller Länge durchlaufen werden muss. Der Umfang sollte sich an Lebensdauer und Komplexität orientieren, nicht an der Anzahl der Etappen.
Für ein Wochenend-Skript oder einen Wegwerf-Prototyp reichen oft Etappe 1 in zwei Sätzen und eine grobe Skizze aus Etappe 2 – alles Weitere kostet mehr Zeit, als es beim Prompten spart. Für ein internes Tool mit wenigen Bildschirmen genügt meist ein geklärtes Datenmodell und eine kurze Rollenfrage, ohne die volle Architekturdiskussion aus Etappe 4. Erst bei einem Produkt, das über Monate oder Jahre wachsen und von mehreren Personen oder Kunden genutzt werden soll, lohnt sich der volle Durchlauf – weil dort jede unausgesprochene Entscheidung sich vervielfacht, statt einmalig Kosten zu verursachen.
Und selbst der vollständige Leitfaden ersetzt nicht das Nachjustieren während der Umsetzung. Auch die beste Planung übersieht Fälle, die erst beim Bauen sichtbar werden. Der Unterschied ist nur: Dann trifft man eine bewusste, nachvollziehbare Entscheidung – statt eine stillschweigende, die irgendwo tief im Code liegt, ohne dass es jemand bemerkt.
Der eigentliche Zweck dieses Leitfadens
Keine der sechs Etappen existiert, um Papier zu produzieren. Sie existieren, damit ein Coding Agent bei der zehnten Aufgabe noch dieselbe Vorstellung vom Produkt hat wie bei der ersten. Das lässt sich nicht am ersten Prompt erkennen. Es zeigt sich erst daran, ob das Ergebnis nach zwanzig Prompts noch wie aus einem Guss wirkt – oder wie drei verschiedene Meinungen, die zufällig im selben Repository gelandet sind.
KI verändert nicht die Prinzipien guter Softwareentwicklung. Sie macht sie sichtbarer. Je autonomer Coding Agents arbeiten, desto wichtiger werden fachliche Klarheit, Architekturentscheidungen und nachvollziehbare Spezifikationen. Wer diese Grundlagen schafft, erhält nicht nur besseren Code – sondern kann KI als echten Entwicklungspartner einsetzen.
