Spec-driven Development
Aktualisiert:
Wenn Agenten den Code schreiben, verantworten Menschen die Absicht statt des Codes. Beim Spec-driven Development hält eine Spezifikation diese Absicht fest. Das ist eine Markdown-Datei, die neben dem Code committet und wie jede andere Änderung in einem Pull Request reviewt wird. Bevor Code existiert, steht darin:
- der aktuelle Stand
- die Änderung
- die Muster, denen die Umsetzung folgt
- die noch offenen Entscheidungen
- die Abnahmetests
Was ändert eine Spec für einen Agenten?
Ein Agent saß nicht im Übergabemeeting, also muss alles, was er braucht, in einer Datei stehen, die er lesen kann. Verteilen sich Anforderungen auf ein Ticket, eine Designdatei und ein Gespräch, erreichen sie einen Menschen, den Agenten aber nicht. Eine einzige Spec-Datei gibt jedem späteren Schritt denselben Input: Refinement, Planung, Umsetzung, Review und Retrospektive. Wer die Testfälle zuerst in die Spec schreibt, zieht das Testdesign an den Anfang.
Wie bleibt die Spec aktuell und verbindlich?
Leitet Korrekturen über die Spec, statt Code im Chat zu patchen. Weichen Code oder Tests von der Spec ab, entscheidet der Owner der Spec, welche Seite sich ändert, und schreibt diese Entscheidung auf. Die Abnahmetests entstehen aus der Spec, und der Agent, der die Änderung umsetzt, schreibt und ändert sie nie. Schlägt ein Test fehl, klärt der Owner der Spec: Ist der Code falsch oder die Spec? Ein Schema in der Spec legt die Form der Daten fest, das Verhalten steht in Abnahmekriterien und Tests. Bestandene Contract-Tests belegen also die Form, nicht die Logik. Mehr dazu unter Specs, Tests und Kontext.
Verwandte Seiten
- Specs, Tests und Kontext: was eine Spec festlegen kann, was nur Tests belegen und was die Quellen dazu sagen, welche Seite gewinnt.
- Research, Plan, Implement (RPI): wie eine einzelne Aufgabe aus der Spec heraus abläuft.
- Spec-driven Development: Schemas, der Zyklus aus Plan, Build und Verify und die Tools.