Erst die Spezifikation · Dann die Umsetzung
Je länger der Chat mit dem Coding-Agenten, desto weiter driftet das Ergebnis vom Ziel, weil das Ziel nie festgeschrieben war. Spec-Driven Development dreht die Reihenfolge: Du beschreibst, was entstehen soll, das Spec-Studio macht daraus Epics und Stories, und jedes Review hat einen Massstab, gegen den es prüfen kann.
Zielgruppe, Ziele, Nicht-Ziele, Verhalten. Das Spec-Studio stellt die Rückfragen, die sonst erst im Sprint auftauchen, und schreibt mit.
Stack, Schnittstellen, Qualitätsregeln, Prüfkommandos. Daraus werden Stack-Profil und Guardrails, die später in jedem Prompt stehen.
Das Studio schlägt Epics und Stories vor; du streichst, ergänzst und entscheidest, welche Story als Erste läuft.
Jeder Draft-PR lässt sich an der Spezifikation messen. Was du dabei lernst, fliesst zurück in die Spec, nicht in einen Chatverlauf.
Beispiel
Montag, 09:00, Produkt-Sync. „Wir brauchen Einladungen“, sagt jemand, und alle nicken. Zehn Minuten im Spec-Studio später stehen die Entscheidungen, die sonst der erste Entwickler alleine getroffen hätte:
Aus der Spec werden zwei Stories. Die erste läuft am selben Nachmittag; der Draft-PR am Abend lässt sich Satz für Satz gegen die vier Kriterien lesen.
Das Spec-Studio führt durch Vision, Ziele und Nicht-Ziele, funktionale Anforderungen, Stack und Einschränkungen, Qualitätsregeln und die Epic-Zerlegung. Jeder Abschnitt hat einen eigenen Rückfrage-Chat, der Lücken benennt, statt sie zu überschreiben.
Am Ende erzeugt das Studio echte Tickets in deinem Tracker, auf Wunsch samt neu angelegtem Repository. Code schreibt es nicht; der erste Lauf startet, wenn du eine Story ziehst.
Eine Spezifikation macht schlechte Anforderungen nicht gut; sie macht sie sichtbar, bevor Code entsteht. Widersprüche und fehlende Entscheidungen fallen im Studio auf, nicht im Review.
Halte die Spec aktuell, wenn du dazulernst. Agenten und Reviewer arbeiten dann gegen dieselbe Referenz.