Es gibt eine wachsende Kluft zwischen Entwicklern, die zuverlaessigen Output von Claude Code bekommen, und Entwicklern, die den halben Tag damit verbringen, rueckgaengig zu machen, was der Agent gerade gebaut hat. Der Unterschied liegt nicht an Talent, Erfahrung oder irgendeinem geheimen Prompt-Engineering-Trick. Es ist eine Frage der Methodik. Die Entwickler, die mit KI-Agents Produktionssoftware ausliefern, sind auf ein Muster konvergiert, ob sie es so nennen oder nicht: definiere, was du willst, bevor der Agent anfaengt, Code zu schreiben.
Dieser Artikel gibt diesem Muster einen Namen. Spec-first-Entwicklung ist eine Methodik fuer KI-gestuetzte Softwareentwicklung. Keine vage "Best Practice." Ein strukturierter, wiederholbarer Lebenszyklus mit definierten Phasen, klaren Checkpoints und konkreten Artefakten bei jedem Schritt. Wenn du nach einem Weg gesucht hast, Claude Code Output vorhersagbar genug zu machen, um deinen Release-Zeitplan darauf zu setzen, dann ist dies das Framework.
Die Grenze des Vibe Coding
"Vibe Coding" tauchte Anfang 2025 im Sprachgebrauch auf. Das Versprechen: beschreibe in natuerlicher Sprache, was du willst, lass die KI es schreiben, iteriere, bis es passt. Fuer Prototypen, Wochenendprojekte und einmalige Skripte funktioniert Vibe Coding. Man bekommt schnell etwas Funktionales, und wenn es spaeter kaputtgeht, sind die Einsaetze gering.
Produktionssoftware unterliegt anderen Einschraenkungen. Der Code muss sich in eine bestehende Codebase integrieren, spezifische Anforderungen erfuellen und den Kontakt mit anderen Menschen ueberstehen, die ihn warten werden. Wenn Vibe Coding auf diese Einschraenkungen trifft, sind die Fehlermodi vorhersehbar.
Das erste Versagen ist Drift. Du beschreibst ein Feature vage, der Agent implementiert seine Interpretation, du korrigierst, der Agent implementiert seine korrigierte Interpretation neu. Drei Iterationen spaeter hast du funktionierenden Code, der keine deiner urspruenglichen Anforderungen erfuellt, weil jede Iteration das Ziel verschoben hat. Du konvergierst auf das, was der Agent glaubt, dass du willst, nicht auf das, was du tatsaechlich brauchst.
Das zweite Versagen sind unsichtbare Entscheidungen. Jede Luecke in deiner Beschreibung ist eine Entscheidung, die der Agent stillschweigend trifft. Datenbankschema, Fehlerbehandlungsstrategie, API-Form, Validierungsregeln, Bibliothekswahl. Du entdeckst diese Entscheidungen beim Code-Review oder, schlimmer noch, in Produktion. Der Agent hat keine schlechten Entscheidungen getroffen. Er hat unbeauftragte Entscheidungen getroffen, und du hattest keinen Mechanismus, sie zu erwischen, bevor sie in die Implementierung eingebacken waren.
Das dritte Versagen ist Review-Lahmung. Ein 600-Zeilen-Diff, bei dem der Agent die Architektur, das Datenmodell, die Fehlercodes und die Edge-Case-Behandlung gewaehlt hat, ist nicht im traditionellen Sinne reviewbar. Du reviewst keinen Code gegen eine Spec. Du rekonstruierst die Spec aus dem Code und entscheidest dann, ob du damit einverstanden bist. Das dauert laenger als das Schreiben der Spec gedauert haette.
Vibe Coding stoesst an eine Grenze, weil es zwei unterschiedliche Aktivitaeten vermischt: entscheiden, was gebaut werden soll, und es bauen. Spec-first-Entwicklung trennt sie.
Spec-First als Methodik
Spec-first-Entwicklung ist ein Vier-Phasen-Lebenszyklus. Jede Phase produziert ein konkretes Artefakt. Jeder Uebergang hat eine klare Gate-Bedingung. Die Methodik funktioniert mit jedem KI-Coding-Agent, aber die Beispiele in diesem Artikel verwenden Claude Code, weil dort die Community am schnellsten iteriert.
Phase 1: Brainstorming
Du und der Agent (oder nur du) erkunden den Problemraum. Was sind die Einschraenkungen? Welche Ansaetze gibt es? Was sind die Kompromisse? Das ist konversationell. Du verpflichtest dich zu nichts. Du kartierst das Terrain.
Die Gate-Bedingung: Du hast einen bevorzugten Ansatz und kannst erklaeren, warum dieser Ansatz und nicht die Alternativen.
Brainstorming mit Claude Code ist wertvoll, weil der Agent breites Wissen ueber Muster und Bibliotheken hat. Der Fehler ist, vom Brainstorming direkt zum Code zu springen. Das Brainstorming zeigt Optionen auf. Es waehlt nicht zwischen ihnen. Das tust du.
Phase 2: Spec
Du schreibst die Entscheidung nieder. Das ist der Vertrag, gegen den der Agent implementieren wird. Eine Spec ist keine User Story, kein Jira-Ticket, kein Prosa-Absatz. Es ist ein strukturiertes Dokument mit:
- Problembeschreibung: was kaputt ist oder fehlt, in konkreten Begriffen
- Vorgeschlagener Ansatz: die gewaehlte Loesung aus der Brainstorming-Phase
- Betroffene Dateien: welche Dateien der Agent anfassen soll (und implizit, welche nicht)
- Akzeptanzkriterien: testbare Bedingungen, die "fertig" definieren
- Ausserhalb des Umfangs: was der Agent explizit vermeiden soll
Die Akzeptanzkriterien sind das wichtigste Element. Jedes muss eine konkrete Aktion mit einem beobachtbaren Ergebnis sein. "Authentifizierung sollte funktionieren" ist kein Kriterium. "Gueltige Anmeldedaten ergeben eine 200 mit Session-Token; ungueltige Anmeldedaten ergeben eine 401 ohne Token" ist eines.
Der Ausserhalb-des-Umfangs-Abschnitt verhindert Gold-Plating. Ohne ihn werden Agents angrenzenden Code "verbessern", Dateien refactoren, die ihnen unordentlich aufgefallen sind, oder Features hinzufuegen, die verwandt scheinen. Jede Minute, die der Agent mit nicht angeforderter Arbeit verbringt, ist eine Minute, die du mit dem Review nicht angeforderter Arbeit verbringst.
Die Gate-Bedingung: Jemand, der nicht beim Brainstorming dabei war, koennte diese Spec lesen und das Richtige bauen.
Phase 3: Implementierung
Der Agent arbeitet gegen die Spec. Nicht gegen ein Gespraech. Nicht gegen eine Erinnerung an das, was ihr besprochen habt. Gegen ein konkretes Dokument mit testbaren Kriterien.
Bevor er Code schreibt, erstellt der Agent einen Plan: eine nummerierte Liste der Aenderungen, die er vornehmen will, welche Dateien er aendern wird und wie er das Ergebnis verifizieren wird. Dieser Plan ist ein Zwei-Minuten-Checkpoint. Du liest ihn, bestaetigst, dass er deiner Absicht entspricht, und gibst gruenes Licht fuer die Implementierung. Oder du erkennst ein Missverstaendnis und korrigierst es. So oder so hast du zwei Minuten statt zwanzig investiert.
Das Plan-vor-Code-Muster ist keine Buerokratie. Es ist die einzelne Intervention mit dem hoechsten Hebel im gesamten Workflow. Die meisten Implementierungsfehler sind keine Coding-Fehler. Es sind Verstaendnisfehler: Der Agent hat die Spec missverstanden. Einen Verstaendnisfehler in einem Plan zu erkennen kostet zwei Minuten. Ihn in einem 400-Zeilen-Diff zu erkennen kostet zwanzig. Ihn in Produktion zu erkennen kostet einen Tag.
Die Gate-Bedingung: Der Agent hat einen Abschlussbericht mit spezifischen Aussagen darueber gepostet, was gebaut wurde und wie es verifiziert wurde.
Phase 4: Verifikation
Du oder ein QA-Prozess bestaetigst die Implementierung gegen die Spec. Nicht "sieht es richtig aus?" sondern "erfuellt es jedes Akzeptanzkriterium?"
Verifikation ist mechanisch. Du nimmst jedes Kriterium aus der Spec, fuehrst den Test aus (Befehl ausfuehren, Browser oeffnen, Event ausloesen) und protokollierst das Ergebnis: bestanden oder durchgefallen. Kriterien, die durchfallen, gehen zurueck zu Phase 3. Die Verifikation wird neben der Implementierung dokumentiert, sodass jeder, der die Aufgabe in sechs Monaten liest, genau sehen kann, was getestet wurde.
Die Gate-Bedingung: Jedes Akzeptanzkriterium hat ein protokolliertes Bestanden/Durchgefallen-Ergebnis.
Das ist der vollstaendige Lebenszyklus. Vier Phasen, vier Artefakte (Ansatz-Begruendung, Spec, Implementierungsplan, Verifikationsprotokoll), vier Gate-Bedingungen. Die Phasen sind sequenziell, aber leichtgewichtig. Fuer ein mittelgrosses Feature brauchen Phase 1 und 2 15-20 Minuten. Phase 3 dauert so lange wie die Implementierung. Phase 4 braucht 5-10 Minuten.
Warum das bei Agents wichtiger ist als bei Menschen
Jedes Argument fuer das Schreiben von Specs gibt es schon vor KI. "Schreib Anforderungen vor Code" ist ein Ratschlag, seit bevor die meisten von uns geboren wurden. Warum also das als etwas spezifisch fuer KI-gestuetzte Entwicklung darstellen?
Weil Agents die Kostenfunktion veraendern.
Ein menschlicher Entwickler, der eine vage Anforderung erhaelt, wird anhalten und Fragen stellen. "Meinst du Passwort-Auth oder SSO?" "Soll das auf Mobilgeraeten funktionieren?" "Was passiert, wenn der Token ablaeuft?" Jede Frage ist ein Mini-Checkpoint, der die Implementierung in Richtung des korrekten Ziels schiebt. Die Kosten einer vagen Spec bei einem menschlichen Entwickler sind ein paar Slack-Threads und vielleicht ein Nachmittag Nacharbeit.
Ein Agent, der eine vage Anforderung erhaelt, wird nicht anhalten. Er wird jede mehrdeutige Entscheidung stillschweigend treffen, sich auf einen Ansatz festlegen und dir eine fertige Implementierung praesentieren. Die Kosten einer vagen Spec bei einem Agent sind eine fertige Implementierung, die moeglicherweise komplett falsch ist, plus die Zeit, die du brauchst, um zu entdecken, dass sie falsch ist, plus die Zeit fuer die Nacharbeit.
Die Asymmetrie ist deutlich. Agents sind schneller in der Ausfuehrung und schlechter im Urteilsvermoegen als menschliche Entwickler. Jede Mehrdeutigkeit in der Spec ist eine Urteilsentscheidung, und jede Urteilsentscheidung, die der Agent ohne Anleitung trifft, ist ein Muenzwurf, ob das Ergebnis deiner Absicht entspricht. Eine Spec eliminiert Muenzwuerfe.
Es gibt einen zweiten, subtileren Grund. Agents widersprechen nicht. Ein Senior-Entwickler, der eine schlechte Spec erhaelt, wird sagen "das ergibt keinen Sinn wegen X." Ein Agent wird eine schlechte Spec treu implementieren und treu falschen Output produzieren. Spec-first-Entwicklung zwingt dich, dein eigenes Denken zu ueberpruefen, bevor du es an eine Entitaet uebergibst, die es ohne Frage ausfuehren wird. Die Spec ist nicht nur fuer den Agent. Sie ist fuer dich.