Spec-Driven Development, oder: EARS vs. Vibe Coding

Teil 1 meiner kleinen Serie endete mit einer Frage, die harmlos klingt und es nicht ist: Verifikation gegen was?

Der grüne Haken behauptet „erfüllt die Spezifikation“. Schön. Aber welche Spezifikation? Wenn die nur in deinem Kopf existiert, prüft der grüne Haken gegen nichts.

Und hier wird es unangenehm. Der Agent füllt jede Lücke, die du offen lässt. Nicht aus Bosheit, sondern weil er muss: Wo keine Vorgabe steht, rät er das Wahrscheinlichste. In Teil 1 war das einer der drei Mechanismen hinter dem Slop. Jetzt drehen wir ihn um und machen ihn zur Lösung.

Stille Post mit einem Mitspieler, der alles wörtlich nimmt

Kennst du Stille Post? Eine Anforderung wandert vom Stakeholder über den Product Owner zur Entwicklerin, und am Ende kommt etwas leicht anderes raus als gemeint. Das war schon immer so.

Nur hatte diese Kette bisher viele Ohren. Die Entwicklerin fragt zurück: „Meinst du den Warenkorb oder die Bestellung?“ Der PO stutzt: „Moment, so war das nicht gedacht.“ Die Übertragung war verlustbehaftet, aber sie hatte eine eingebaute Fehlerkorrektur.

Der Agent fragt nicht zurück. Er nimmt deine halbe Anforderung, rät den Rest und liefert. Selbstbewusst. Und der grüne Haken bestätigt brav, dass er genau das gebaut hat, was er sich selbst zusammengereimt hat.

Was wäre, wenn der Code gar nicht das wertvolle Artefakt ist?

Wir behandeln Code instinktiv als das Wertvolle. Den hüten wir, den reviewen wir Zeile für Zeile, den committen wir. Die Anforderung dahinter? Steht in einem Ticket, das nach dem Merge niemand mehr aufmacht.

Spec-Driven Development dreht das um.

Das klingt nach Bürokratie (das Wort, bei dem Entwickler reflexhaft das Weite suchen), ist aber das Gegenteil. Wenn die Spec die Quelle ist, wird der Code zum Kompilat: etwas, das aus der Quelle entsteht und ersetzt werden kann. Du pflegst nicht mehr zwei Wahrheiten (das, was gemeint war, und das, was im Code steht), sondern eine.

Der Ablauf dahinter ist simpel: erst spezifizieren, dann planen, dann in Aufgaben zerlegen, dann umsetzen. Spec-Kit etwa gießt genau diesen Ablauf in fertige Slash-Commands. Vier Artefakte, vier klare Rollen:

Die Spec gehört dem Menschen. Das ist kein Zufall, sondern der ganze Punkt. (Die constitution.md steht dabei über dem Ablauf: projektweite Regeln, die für jede Spec gelten.)

EARS: Intent, der sich testen lässt

„Schreib eine gute Spec“ ist ein nutzloser Rat. Eine Anforderung in Prosa ist genauso mehrdeutig wie das Ticket von vorhin. Was hilft, ist eine Form, die Mehrdeutigkeit schwer macht.

EARS ist so eine Form. Die vier Buchstaben stehen für Easy Approach to Requirements Syntax, eine Notation, die Alistair Mavin und Kollegen ursprünglich bei Rolls-Royce entwickelt haben. Jedes Kriterium folgt einem festen Muster, das zur Art der Anforderung passt: ein Ereignis („When …“), ein Zustand („While …“), eine unerwünschte Bedingung („If … then“), ein optionales Feature („Where …“) oder schlicht der Dauerfall ganz ohne Schlüsselwort. Am Ende steht immer „… shall das System …“. Klingt steif, zwingt dich aber, die Bedingung explizit zu machen, unter der etwas gelten soll.

Sieh dir die dritte Zeile an. Verlängert ein Versuch während der Sperre die Sperre, oder nicht? Das ist genau die Frage, die ein Mensch zurückgefragt hätte und die der Agent sonst still für sich entschieden hätte.

Aber EARS beantwortet diese Frage nicht für dich. Es zwingt dich nur, sie zu stellen, sobald du das Kriterium schreibst. „Während der Sperre“ lässt sich nicht formulieren, ohne zu entscheiden, was dann gilt.

Drücken kannst du dich trotzdem, nur subtiler: indem du die Zeile gar nicht erst schreibst. Lass das dritte Kriterium weg, und die Anforderung bleibt offen. Der Agent füllt die Lücke dann wie jede andere, mit einer Vermutung, oder er behandelt den Fall gar nicht. EARS schärft die Aussagen, die du triffst. Gegen die, die du vergisst, hilft es nicht.

Eine zweite, feinere Falle steckt im Schreiben selbst. Wenn du die Anforderung nur grob hinwirfst und den Agenten die EARS-Kriterien daraus „sauber ausformulieren“ lässt, reißt du die Trennung wieder ein, bevor du sie hattest: Dann hält dieselbe Instanz den Intent und seine Form, und du bist zurück bei einem Autor, der seine eigene Vorgabe schreibt. Die Kriterien sind der Intent, nicht seine Verpackung. Die schreibst du, nicht er.

Die Last verschiebt sich also, sie verschwindet nicht. Die Pflicht, den Intent vollständig zu artikulieren, liegt mehr denn je bei dir. Und ob deine Spec wirklich vollständig ist, ob also keine solche Zeile fehlt, ist selbst eine Prüfung.

Und der Lohn kommt erst danach: Funktionale Kriterien wie diese lassen sich fast eins zu eins in einen Test übersetzen. Wie diese Prüfungen aussehen, ist Teil 3.

Der eigentliche Gewinn: du prüfst den Intent, nicht den Diff

Wenn du jeden Diff des Agenten liest, holst du den Engpass zurück, den du loswerden wolltest. Review skaliert mit der Menge Code, und der Agent produziert mehr Code, als du je gegenlesen kannst.

Mit einer Spec als Quelle verschiebt sich, wo der Mensch arbeitet. Du prüfst nicht mehr tausend Zeilen Output. Du verantwortest die paar Dutzend Zeilen Intent, aus denen dieser Output entsteht. Die Wette dahinter: Intent ist kleiner als Code. Eine Spec treibt viel Output, also gibt es weit weniger zu verantworten als zu generieren.

Das ist die Engpass-Verlagerung, von der die ganze Serie lebt: Review raus aus dem heißen Pfad, ohne die Kontrolle abzugeben. (Wenn du Event Storming machst: das ist die Quelle des Intents. SDD ist die schriftliche Form davon, die der Agent lesen und an die er gebunden werden kann.)

Die fragilste Stelle: die eine Frage ohne Netz

So weit, so gut. Aber jetzt kommt der Haken, und er ist ernst.

In Teil 1 hieß es: Zero-Trust für Korrektheit, der grüne Haken ist eine Behauptung (Faustregel 8). Wir misstrauen dem Code, den Tests, dem Agenten. Alles wird von einer Instanz geprüft, die der Autor nicht beeinflussen kann.

Alles? Bei der Spec lohnt ein genauerer Blick, denn sie hat mehrere Ebenen, und nur eine davon ist wirklich ohne Netz.

Vieles an einer Spec ist sehr wohl prüfbar, und zwar bevor eine Zeile Code entsteht.

Das Erste ist ihre innere Stimmigkeit: Ist sie eindeutig, in sich widerspruchsfrei? Das kann ein Agent abklopfen, der nur prüft und nichts umsetzt (Kiro nennt das „deep spec analysis“). So einer fängt auch strukturelle Lücken, etwa die fehlende Zeile von vorhin: „Du beschreibst eine Sperre, sagst aber nicht, was während der Sperre passiert.“ Zwei Dinge machen ihn wertvoll: Es muss ein anderer Kopf sein als der, der die Spec geschrieben hat, sonst teilt er denselben blinden Fleck. Und er meldet die Lücke, entscheiden musst du sie weiter selbst. (Wer es ganz genau nimmt, modelliert das Verhalten zusätzlich formal nach, etwa in TLA+.)

Das Zweite ist die Korrespondenz zwischen Spec und Code: Tut der Code, was die Spec sagt? Auch das hat ein Netz, den EARS-Trick von vorhin.

Eine Frage aber bleibt, und gegen die hilft kein Werkzeug: Will die Spec überhaupt das Richtige? Keine Prüfung der Welt sagt dir, ob die saubere, getestete Spec das beschreibt, was eigentlich gemeint war. Die Softwaretechnik trennt das seit Jahrzehnten in „das Produkt richtig bauen“ (Verifikation, dafür gibt es Maschinen) und „das richtige Produkt bauen“ (Validierung, die endet bei einem Menschen).

Diese letzte Frage ist die Wurzel, unter die sich keine weitere Prüfung schieben lässt. Und sie hat dieselbe Krankheit wie Tests, die zum Bug passen, nur eine Ebene höher.

Und die Konsequenz ist unbequem:

Woher? Indem du die eine Sicherung wieder einbaust, die du gerade entfernt hast: einen unabhängigen Blick auf die Spec, bevor der Agent loslegt. Im Team ist das der Normalfall und billig: Ein zweiter Mensch liest die Spec gegen. Seine Kraft liegt nicht im Titel, sondern in der Unabhängigkeit. Teilen Autor und Reviewer dieselbe falsche Annahme, überlebt der Fehler trotzdem.

Wie streng das sein muss, hängt vom Risiko ab. Für eine Log-Zeile reicht, dass du selbst nach einer Nacht Abstand und mit frischem Blick noch mal draufschaust. Für die Konto-Sperre von oben oder eine Zahlung will ein zweites Paar Augen drauf, bevor irgendein Agent eine Zeile schreibt.

Wo das kippt

Damit du mir nicht zu viel glaubst: SDD ist kein Zauberstab.

Garbage in, garbage out gilt unverändert. Eine präzise Spec für das falsche Produkt ist präzise falsch.

Specs driften. Wenn der Code sich ändert und niemand die Spec nachzieht, hast du bald zwei Wahrheiten und vertraust der falschen. Die stille Ausführung einer veralteten Spec ist gefährlicher als gar keine.

Manche ziehen daraus einen radikalen Schluss: Dann sei eben nur der Code die Wahrheit, jedes andere Dokument verrottet. Ehrlich gesagt klingt das erst mal überzeugend. Es übersieht aber den Unterschied zwischen einer Spec, die als Prosa danebenliegt, und einer, die als Test läuft.

Genau dafür war EARS da. Ein Kriterium, das in einen Test übersetzt ist, kann nicht still driften. Läuft der Code der Spec davon, wird der Test rot. Die Lücke meldet sich von selbst, statt im Verborgenen zu wachsen. So wird aus der unsichtbaren Fleißarbeit, die sonst liegen bleibt, ein Alarm, den du nicht überhörst.

Das räumt nicht alles ab. Der Teil der Spec, der sich nicht in einen Test gießen lässt (das Warum hinter einer Architekturentscheidung, eine Projektregel in Prosa), driftet weiter im Stillen, und dagegen hilft nur, regelmäßig draufzuschauen. Aber der gefährlichste Fall, die stille Lücke zwischen behauptetem und echtem Verhalten, ist abgefangen.

Und die unangenehmste Falle: Wenn der Agent am Ende auch die Spec schreibt, bist du wieder am Anfang. Dann erfindet dieselbe Instanz Intent und Umsetzung, und die schöne Trennung ist weg. Deshalb verantwortet der Mensch den Intent, und spec.md wie constitution.md gehören in den geschützten Satz, an den der Agent nicht einseitig rankommt.

Was du mitnimmst

Der Hebel aus Teil 1 war „kontrolliere das System, nicht den Output“. Teil 2 sagt, wo dieses System anfängt: beim Intent. Der Mensch reviewt nicht mehr jeden Diff. Er verantwortet die Spec. Erst der Zweck, dann die Hygiene.

Aber eine Spezifikation ist ein Stück Text – sie beschreibt, was gelten soll. Sie erzwingt nichts. Sie ist die Schreibmaschine, nicht das Schloss.

Die Frage ist nun: wer hält das Schloss? Darum geht es in Teil 3.