Was ist Spec-Driven Development und wann hilft es?

Was ist Spec-Driven Development?

Wenn Sie einem Coding-Agenten eine Aufgabe geben, erklären Sie meist im Chat, was Sie wollen. Steht das nur im Chat, ist es weg, sobald die Sitzung endet. Spec-Driven Development (SDD) schreibt diese Absicht vor dem Code in eine Datei. Die Spec, kurz für Spezifikation, ist das Dokument, das festhält, was der Agent tun soll und warum. Der Agent schreibt zuerst die Spec, dann einen technischen Plan, der beschreibt, wie es umgesetzt wird, dann eine Aufgabenliste. Den Code erzeugt er zuletzt, anhand dieser Dokumente.

In dem Beitrag vom September 2025, mit dem GitHub Spec Kit vorstellte, fasst GitHub die Idee in einem Satz zusammen: “We’re moving from “code is the source of truth” to “intent is the source of truth.”” Was richtig ist, entscheidet also nicht der Code, sondern die schriftlich festgehaltene Absicht. Derselbe Beitrag sagt auch, was dem Entwickler bleibt: “Crucially, your role isn’t just to steer. It’s to verify.” Um diesen zweiten Satz geht es hier.

Was aus der Spec wird, wenn die Arbeit erledigt ist, hängt vom Ansatz ab. Die drei Stufen aus dem Artikel vom Oktober 2025, in dem Birgitta Böckeler von Thoughtworks drei SDD-Tools ausprobierte, stehen heute auch in der Dokumentation von Spec Kit:

• Spec-first. Die Spec wird vor dem Code geschrieben; ist die Arbeit erledigt, kann sie weg.
• Spec-anchored. Die Spec bleibt nach der Arbeit erhalten und wird bei späteren Änderungen genutzt.
• Spec-as-source. Menschen bearbeiten nur die Spec; der Code wird aus ihr erzeugt und nie von Hand geändert.

Laut Böckeler sind alle Ansätze, die sie gefunden hat, spec-first; wie die Spec über die Zeit gepflegt werden soll, bleibt oft offen. Wie wir unten sehen, ist es genau diese Unklarheit, die das Code-Review am meisten erschwert.

Unsere Hauptquelle zur Praxis ist die Studie Spec-Driven Development as Prescribed and as Practiced von Forschenden der Carnegie Mellon University und von Google. Die neueste Fassung auf arXiv ist vom 15. Oktober 2026. Die Studie stützt sich auf Reddit-Diskussionen, Interviews mit 21 Praktikern (davon 8, die selbst Tools entwickeln) und 266 Repositories auf GitHub. Auch die beiden Prozentzahlen oben stammen aus dieser Studie.

Um die Regeldateien von Coding-Agenten ging es im Beitrag über AGENTS.md und CLAUDE.md, um das Prüfen eines von KI geschriebenen Pull Requests in einem eigenen Beitrag. Dieser Beitrag stellt die Spec zwischen die beiden.

Welche Schritte führen von der Spec zum Code?

Die Tools nennen die Schritte unterschiedlich, die Reihenfolge ist aber dieselbe: erst was gebaut wird, dann wie, dann die Aufgaben, zuletzt der Code. Am Ende jedes Schritts lesen Sie das Dokument und korrigieren es; mit dieser Fassung geht der Agent in den nächsten Schritt.

In Spec Kit führen Sie einmal pro Projekt /speckit.constitution aus, danach für jedes Feature der Reihe nach specify, plan, tasks, implement und converge. In der Constitution stehen die Grundsätze des Projekts, und jeder spätere Schritt wird an ihnen gemessen; sie ähnelt der Regeldatei eines Coding-Agenten. clarify, checklist und analyze sind optionale Qualitätsprüfungen, die Sie bei Aufgaben mit Unklarheiten dazunehmen.

In Kiro besteht jede Spec aus drei Dateien: requirements.md, design.md und tasks.md. Die Anforderungen werden in einem Muster namens EARS geschrieben: “WHEN [Bedingung] THE SYSTEM SHALL [erwartetes Verhalten]”. Die Reihenfolge ist Anforderungen, Design, Aufgaben; haben Sie schon eine Architektur, können Sie auch mit dem Design beginnen. Kiros Regeldateien liegen im Ordner .kiro/steering/, und Kiro liest auch die AGENTS.md im Wurzelverzeichnis des Repositorys.

OpenSpec legt jede Änderung in einem eigenen Ordner ab: Unter openspec/changes/<änderung>/ liegen die Begründung (proposal.md), die Anforderungen (specs/), bei Bedarf ein Design (design.md) und die Aufgaben (tasks.md). Der Zyklus besteht aus Erkunden, Vorschlagen, Prüfen, Umsetzen und Archivieren. Die Spec einer Änderung hält nur den Unterschied fest: welche Anforderung hinzukam, geändert, entfernt oder umbenannt wurde. Beim Archivieren werden diese Unterschiede in die Haupt-Specs unter openspec/specs/ übernommen; die Haupt-Specs beschreiben den heutigen Stand des Systems. Eine Delta-Spec aus der README von OpenSpec sieht so aus:

## ADDED Requirements

### Requirement: Theme selection
The app SHALL let users switch between light and dark themes,
defaulting to the system preference.

#### Scenario: User toggles dark mode
- **WHEN** the user clicks the theme toggle
- **THEN** the app switches to dark mode and persists the choice

Diese Delta-Datei ist im Review der nützlichste Teil: Sie zeigt im Pull Request auf einen Blick, wo sich die Absicht geändert hat. Weiter unten kommen wir darauf zurück.

Was unterscheidet Spec Kit, Kiro und OpenSpec?

Die Dokumentation der drei Tools haben wir am 18. Oktober 2026 gelesen. Die Tabelle zeigt, welche Dateien jedes Tool schreibt, was es am Ende der Arbeit prüft und was es für kleine Aufgaben empfiehlt:

Quelle: die Dokumentation des jeweiligen Tools, 18. Oktober 2026. Wie die Befehle geschrieben werden, hängt vom Coding-Agenten ab, den Sie nutzen (zum Beispiel /speckit.plan oder /speckit-plan). Laut Kiros Dokumentation laufen Property-based Tests nur in der IDE. In Kiro können Sie die Anforderungen vor dem Design zusätzlich auf Widersprüche und Lücken prüfen lassen.

Die drei laufen an verschiedenen Stellen. Spec Kit ist ein Open-Source-Toolkit, das Ihrem Coding-Agenten als Befehle oder Skills hinzugefügt wird. Auch OpenSpec ergänzt die Tools, die Sie schon nutzen; laut README unterstützt es 30+ Tools. Kiro dagegen ist ein Coding-Agent mit eigener IDE, CLI und Weboberfläche. Die README von OpenSpec sagt über Kiro “limited to Claude models”; auf Kiros Modellseite stehen Stand 18. Oktober 2026 aber auch GPT-5.6 und Open-Weight-Modelle. Was ein Tool über einen Konkurrenten sagt, prüft man besser in dessen eigener Dokumentation nach.

2025 stand auf dieser Liste noch ein Name mehr: Tessl. Böckeler hatte es neben Kiro und Spec Kit ausprobiert. Im September 2025 stellte Tessl seine ersten Produkte als auf Spec-Driven Development aufgebaut vor: eine Spec Registry in der offenen Beta und das Tessl Framework in der geschlossenen Beta. Die heutige Dokumentation beschreibt Tessl dagegen als “an open platform for managing agentic development across your organization” und erwähnt Spec-Driven Development nicht. Die Methode gibt es heute als öffentliches Plugin in Tessls Registry. Eine aktuelle Seite, die sagt, wie es heute um das Tessl Framework steht, haben wir nicht gefunden.

Zwei weitere Open-Source-Methoden arbeiten mit Specs. In Superpowers findet der Agent zuerst mit Fragen heraus, was Sie wollen; kleine Änderungen werden im Chat vereinbart, für Projekte entsteht ein schriftliches Designdokument. Bei der Umsetzung, die mit Subagenten läuft, wird jede Aufgabe in zwei Stufen geprüft: erst die Übereinstimmung mit der Spec, dann die Codequalität. Die BMAD Method sagt, dass sich ihr Prozess nach der Größe der Arbeit richtet: Kleine Änderungen gehen direkt in die Umsetzung.

Warum nennen Kritiker es den „neuen Wasserfall“?

Wasserfall ist der Ansatz, der die Arbeit vorab plant und die Phasen streng nacheinander abarbeitet: kein Design, bevor die Anforderungen geschrieben und abgenommen sind, kein Code, bevor das Design fertig ist. Kritiker sagen, Spec-Driven Development bringe diese Reihenfolge mit Markdown-Dateien zurück. Zwei Beiträge sagen es schon im Titel: “The Waterfall Strikes Back” und “Reinvented Waterfall?”. Gemeinsam ist der Kritik aber weniger die Reihenfolge als der Review-Aufwand.

Thoughtworks, Oktober 2025. Böckeler bat Kiro, einen kleinen Fehler zu beheben. Das Anforderungsdokument machte aus diesem kleinen Fehler 4 User Stories mit insgesamt 16 Akzeptanzkriterien. Als sie Spec Kit an einem größeren Feature ausprobierte, fand sie die Markdown-Dateien, die sie lesen musste, ebenfalls zu viel für den Umfang der Arbeit: “To be honest, I’d rather review code than all these markdown files.” Trotz all dieser Dateien, schreibt sie, habe sie oft gesehen, dass der Agent nicht alle Anweisungen befolgte.

Scott Logic, November 2025. Colin Eberhardt löschte ein Feature aus seiner Hobby-App, ließ es mit Spec Kit neu bauen und notierte, wie viel Zeit jeder Schritt kostete. Er baute das Feature in zwei Schritten: erst die Ansichten zur Verwaltung der Rennstrecken, dann GPS. Der erste Schritt ergab 2.577 Zeilen Markdown und 689 Zeilen Code, Lesen und Prüfen dauerte 3,5 Stunden; beim zweiten waren es 2.262 Zeilen Markdown und etwa 300 Zeilen Code, die Prüfung dauerte etwa 2 Stunden. Als er dasselbe Feature ohne Spec baute, so wie er es gewohnt ist, brauchte er insgesamt 24 Minuten: 15 Minuten Code-Review und 9 Minuten Test. Das ist Eberhardts eigene Messung: ein Entwickler, eine Hobby-App, Spec Kit im Stand von November 2025; der Schritt converge kommt in dem Beitrag nicht vor.

Der Unterschied liegt nicht im Code: Ohne Spec kamen die beiden Schritte zusammen auf etwa 1.000 Zeilen Code. Die Zeit ging ins Markdown. Eberhardt schreibt, er sei ohne Spec etwa 10-mal so schnell gewesen, und schließt: “For now, the fastest path is still iterative prompting and review, not industrialised specification pipelines.” Das ist die Erfahrung eines einzelnen Entwicklers mit einer einzigen App, keine allgemeine Messung.

Marmelab, November 2025. Laut François Zaninotto enthält die technische Spec bereits Code. Den liest der Entwickler, bevor er ihn ausführt, und weil trotzdem Fehler auftreten, liest er auch den fertigen Code: “As a result, review time doubles.” In seinem Beispiel hatte der Agent die Aufgabe “verify implementation” als erledigt markiert, ohne einen einzigen Unit-Test zu schreiben.

Thoughtworks Technology Radar, November 2025. Das Radar ordnete die Methode im Ring “Assess” ein und schrieb, manche Tools erzeugten “lengthy spec files that are hard to review”. Der Eintrag endet mit diesem Satz: “We may be relearning a bitter lesson — that handcrafting detailed rules for AI ultimately doesn’t scale.” In der aktuellen Ausgabe des Radars steht der Eintrag nicht.

Alle diese Kritiken handeln vom Review-Aufwand: mehr Markdown zu lesen als Code, dasselbe zweimal lesen, ein Agent, der sich nicht an das Geschriebene hält. Und alle entstanden im Herbst 2025, mit den Tools in ihrem damaligen Stand; Böckeler merkt selbst an, dass sich die Tools sehr schnell ändern.

Was sehen die Befürworter anders?

Meg Kretz von Atomic Object sagt in ihrem Beitrag vom Mai 2026, die Ähnlichkeit liege im Dokument, der Unterschied im Verhalten: “The difference comes down to four behaviors, which are observable, not philosophical.” Ihr zufolge nutzt Wasserfall Dokumente wie ein Tor: geschrieben, abgenommen, eingefroren, übergeben. Bei Spec-Driven Development ist das Dokument dagegen ein Arbeitsmittel, das mit dem Code geschrieben und immer wieder neu geschrieben wird. Die vier Verhaltensweisen, die sie nennt:

• Wann ändert sich die Spec? Am Tag, an dem neue Informationen kommen, oft noch in derselben Stunde.
• Wie entwickeln sich Design und Spec? Keins wartet auf das andere; beide entwickeln sich gemeinsam und verändern sich gegenseitig.
• Wann ist die Arbeit fertig? Die Must/Should/May-Anforderungen der Spec sind die Akzeptanzkriterien; sind sie erfüllt, ist die Arbeit fertig.
• Wer bearbeitet die Spec? Wer als Entwickler auf eine Unklarheit stößt, korrigiert die Spec sofort; die Korrektur wird zusammen mit dem Code committet.

Was Kretz den „operativen Test“ nennt, ist für das Review der Kern dieses Beitrags: Spec und Code werden im selben Pull Request committet. “If specs lag code, the spec is documentation, not source of truth.”

Auch Praktiker berichten von Vorteilen, aber vorsichtig. Die meisten Teilnehmenden der Carnegie-Mellon-Studie sagen, Specs machten die Arbeit des Agenten verlässlicher; diesen Gewinn können sie aber nicht von den Fortschritten der Modelle im selben Zeitraum trennen. Ein Team, das die Methode monatelang nutzte, schrieb, es könne nicht belegen, dass sie den Code verbessert habe. Laut Studie beseitigt SDD die Kosten nicht: Es verlagert Tokens, Zeit und geistige Last von der Umsetzung in die Planung.

Seit diesen Beiträgen haben sich auch die Tools verändert. Spec Kit bekam im Juni 2026 eine optionale Erweiterung für Bugfixes und dokumentierte ebenfalls im Juni 2026, wie Specs nach getaner Arbeit weitergeführt werden. In Kiros Dokumentation gibt es heute Quick Spec ohne Freigabeschritt und den Plan-Modus, der keine Dateien schreibt. Einen der Fälle, für die Kiro Quick Spec empfiehlt, beschreibt es so: “You've been defaulting to Vibe mode because the standard Spec flow felt too heavy”.

Wann hilft es, und wann wird es zur Last?

Das Ergebnis der Carnegie-Mellon-Studie ist eindeutig: Die meisten Praktiker setzen SDD nicht bei jeder Aufgabe ein, sondern je nach deren Größe. Bei kleinen Aufgaben, Bugs und einmaligen Skripten lassen sie es weg. Ein Teilnehmer sagt zu einem dringenden Fix in der Produktion: “there is no time for spec-driven development and the whole flow”. Manche entscheiden nach dem Risiko: Ist ein Fehler teuer und die Absicht klar, schreiben sie eine Spec.

Die Spuren in den Repositories zeigen in dieselbe Richtung. Die Forschenden ließen eine Stichprobe von 1.000 Specs von einem Sprachmodell einordnen; nach ihrer Schätzung beschreiben 82,0 % der Specs ein neues Feature. Auch die Dokumentation der Tools trennt so:

Die mittlere Stufe ist wichtig. Kiro empfiehlt den Plan-Modus für Aufgaben von 15–60 Minuten, für die eine formale Spec zu viel wäre. Der Plan bleibt im Chat, und keine Spec-Datei landet im Repository; es gibt also auch kein Dokument, an dem Sie den Code später prüfen könnten. Bei einer kleinen Aufgabe ist das kein Problem: Diesen Pull Request prüfen Sie wie gewohnt, anhand des Diffs und der Beschreibung.

Für Bugfixes empfiehlt Spec Kit einen eigenen Weg: Diagnose, Korrektur und Prüfung bleiben getrennt, und eine ungeprüfte Korrektur gilt nicht als Erfolg. Kiro hält bei Tippfehlern oder gut verstandenen einzeiligen Änderungen eine schnelle Korrektur im Chat für ausreichend.

Wie laufen Code und Spec mit der Zeit auseinander?

Die meisten Teilnehmenden der Carnegie-Mellon-Studie berichteten, dass Code und Spec auseinanderliefen. Die Forschenden unterscheiden zwei Wege und geben ihnen Namen: implementation drift (der Code weicht von der Spec ab) und spec decay (die Spec veraltet). Ihr Beispiel ist, wie lange eine Sitzung offen bleibt:

In beiden Fällen sagt der Code 60 Minuten und die Spec 30 Minuten; ein Tool, das Code und Spec vergleicht, sieht beide Fälle gleich. Den Unterschied macht, welche Seite falsch ist. Die Studie schreibt es klar: Geplante Reviews durch Agenten oder End-to-End-Tests in der CI können zeigen, dass Code und Spec nicht übereinstimmen, aber nicht, welche Seite falsch ist. Diese Entscheidung trifft, wem die Absicht gehört.

Implementation drift entsteht im Pull Request, in dem der Code geschrieben wird. Die Studie empfiehlt Tool-Herstellern, Akzeptanzkriterien in Tests zu verwandeln, die der Agent bestehen muss; dass Kiro aus seinen EARS-Anforderungen Property-based Tests erzeugt, ist ein Beispiel dafür. Spec decay entsteht später, in einem anderen Pull Request: Eine Änderung, die ein Verhalten ändert, fasst die Spec nicht an, die dieses Verhalten beschreibt. Die Studie sieht das am häufigsten bei lebenden Specs (living specs), wenn eine Änderung auch Verhalten betrifft, das andere Specs beschreiben.

Die eingebauten Prüfungen der Tools laufen am Ende der Arbeit. Der Schritt converge in Spec Kit vergleicht den Code mit Spec, Plan und Aufgaben des Features und fügt nur fehlende Aufgaben hinzu; nach dem Ergebnis “Converged” verweist die Dokumentation auf das Review oder darauf, einen Pull Request zu öffnen. Der Schritt verify in OpenSpec vergleicht den Code vor dem Archivieren mit den Dokumenten der Änderung und berichtet nur. In Kiro können Sie im Chat mit #spec fragen, ob die Arbeit die Akzeptanzkriterien erfüllt, und erledigte Aufgaben mit Sync Files abhaken lassen.

Alle diese Prüfungen führt der Coding-Agent aus, der die Arbeit gemacht hat; die Dokumentation, die wir gelesen haben, sagt nicht, ob die Prüfung mit einem anderen Modell oder in einer eigenen Sitzung erfolgen sollte. Die Studie schreibt zudem, sie habe nicht feststellen können, ob eines dieser Tools nach Abschluss der Arbeit prüft, ob Spec und Code noch übereinstimmen. Die Dokumentation von Spec Kit nennt das Risiko beim Namen: “The main risk is silent divergence.”

Wie prüft man Code anhand seiner Spec?

Die allgemeinen Schritte, mit denen man einen von KI geschriebenen Pull Request prüft, haben wir in einem eigenen Beitrag beschrieben: Tut er, was die Beschreibung sagt? Was hat er geändert, das er nicht ändern sollte? Prüfen die Tests wirklich etwas? In einem Team, das mit Specs arbeitet, kommen einige Fragen zur Spec hinzu:

Spec und Code gehören in denselben Pull Request. Spec Kit sagt, Code und Dokumentänderungen gemeinsam zu prüfen, OpenSpec, den Änderungsordner zusammen mit dem Code zu committen. Kommt die Spec in einem eigenen Pull Request oder gar nicht, sehen Sie nicht, ob sich die Absicht geändert hat.

Lesen Sie zuerst den Diff der Spec. OpenSpec nennt specs/ den wertvollsten Teil, wenn man den Plan liest, und stellt eine einzige Frage: “Would you accept these requirements as done?” Im Pull Request stellen Sie diese Frage dem Diff: Welches Akzeptanzkriterium kam hinzu, welches hat sich geändert, welches wurde gelöscht? Auch die Studie empfiehlt Tools, Änderungen an Akzeptanzkriterien als Diff zu zeigen. Den Code lesen Sie gegen die neue Spec, die der Pull Request mitbringt; die Änderung an der Spec gegen ihren alten Stand im Zielbranch. Ob der Code zur Spec passt, können Tests und Tools prüfen; ob die Änderung an der Spec richtig ist, kann nur beantworten, wem die Absicht gehört.

Akzeptanzkriterien sollte ein Mensch schreiben oder bestätigen. Die Studie empfiehlt das ausdrücklich: “Practitioners should write or approve acceptance criteria even when agents produce the rest.” Sie müssen nicht die ganze Spec mit derselben Sorgfalt lesen; laut Studie geben Problembeschreibung, zentrale Entscheidungen und Akzeptanzkriterien die Absicht wieder, der Rest ist Kontext für den Agenten. Teilnehmende, die Akzeptanzkriterien festlegten oder die Tests des Agenten durchsahen, nannten die Verifikation nicht als Problem; die Forschenden fügen hinzu, dass sie nicht zeigen können, dass dies Fehler verhindert hat.

Jedes Kriterium braucht einen Test. Ein Haken in der Aufgabenliste ist kein Test: In Zaninottos Beispiel hatte der Agent die Prüfaufgabe abgeschlossen, ohne einen Test zu schreiben. Ordnen Sie jedem Akzeptanzkriterium einen Test zu. Ein Kriterium ohne Test ist ein Versprechen, dem im Code nichts entspricht.

Die Prüfung sollte nicht der Agent übernehmen, der die Arbeit gemacht hat. Schreibt ein einziger Agent Spec, Code und Tests, kann laut Studie ein einziges Missverständnis in alle drei gelangen; deshalb sagen manche Teilnehmende “an agent must not review its own implementation”. Spec Kit zieht für seine eigenen Checklisten dieselbe Grenze: Der Umsetzungsschritt darf sie nicht selbst freigeben. Was es kostet, das Review der Spec ganz einem Agenten zu überlassen, sagt die Studie auch: “Delegating spec review to an agent removes the one point where a person decides what the system should do.”

Prüfen Sie, ob eine andere Spec verletzt wurde. Hier beginnt spec decay oft. Laut Studie kann ein Agent, der ein Feature ändert, ein Verhalten einbauen, das die aktuelle Aufgabe erfüllt und ihre Tests besteht, aber eine Vorgabe aus einer älteren Spec verletzt. Beschreiben andere Specs das geänderte Verhalten, sollten auch sie im selben Pull Request aktualisiert werden.

In den Aufzeichnungen der Open-Source-Repositories tauchen Menschen in diesen Schritten kaum auf. In der Stichprobe der Studie aus 266 Repositories haben 98,3 % der 36.888 Spec-Dateien mit erfasster Historie nur einen Autor; von 1.731 Inline-Kommentaren zu Specs schrieben Bots 68,5 %. In den Worten der Forschenden ist der zweite Leser einer Spec, wenn es einen gibt, meist ein Bot. Diese Zahlen zeigen nicht, wie sorgfältig Menschen Specs lesen oder ob das Review anderswo stattfindet; sie zeigen nur, dass wenig menschliche Beteiligung erfasst ist.

Was sieht ein Review-Tool von der Spec?

diffox ist ein Code-Review-Tool aus 17 spezialisierten Agenten. Spec-Ordner (specs/, .kiro/specs/, openspec/) liest es nicht; es bringt zwei Texte ins Review. Der erste ist die Regeldatei im Wurzelverzeichnis des Repositorys: Es sucht zuerst nach AGENTS.md und, wenn es die nicht gibt, nach CLAUDE.md. Die Datei liest es nicht aus dem Branch des Pull Requests, sondern aus dem Branch, in den er gemergt wird, und zwar so, wie sie an der Stelle stand, an der der Branch abzweigt; ein Pull Request, der die Regeldatei ändert, wird deshalb bis zum Merge nach den alten Regeln geprüft.

diffox übernimmt aus der Regeldatei nur Sätze, die eine Pflicht ausdrücken (etwa “must”, “never”, „muss“, „niemals“), und gibt sie den Agenten im Review als die Regeln, die festlegen, was als Fehler gilt. Einer der Agenten, House Rules Agent, sucht unter den geänderten Zeilen nach einer, die gegen eine dieser Regeln verstößt, und erfindet keine Regel, die nicht auf der Liste steht. Der zweite Text ist die Beschreibung des Pull Requests: Auch sie geht in den Kontext ein, den die Agenten lesen.

Für ein Team, das mit Specs arbeitet, heißt das: Pflichten, die bei jedem Pull Request geprüft werden sollen, gehören in die Regeldatei. Ein Satz wie “Every database migration must include a rollback plan.” aus dem Constitution-Beispiel, das Spec Kit für bestehende Projekte gibt, wird im Review als Regel verwendet, wenn er in der Regeldatei steht; die Constitution-Datei von Spec Kit unter .specify/memory/ liest diffox dagegen nicht. Schreiben Sie in die Beschreibung des Pull Requests auch, welche Spec Sie umgesetzt haben und welche Akzeptanzkriterien sich geändert haben; dieselbe Beschreibung liest auch der Mensch, der das Review macht.

Wo fangen Sie im eigenen Projekt an?

Statt die Methode auf einmal im ganzen Repository einzuführen, fangen Sie klein an:

1. Wählen Sie ein einziges großes Feature. Ein neues Feature mit klarer Absicht, bei dem ein Fehler teuer ist. Bugfixes und kleine Aufgaben erledigen Sie weiter wie gewohnt.
2. Schreiben Sie die Akzeptanzkriterien selbst, oder bestätigen Sie sie einzeln. Den Rest kann der Agent schreiben. Ein Muster wie EARS oder WHEN/THEN macht es leichter, aus einem Kriterium einen Test zu machen.
3. Legen Sie vorab fest, wie die Spec weiterlebt. Spec Kit nennt drei Modelle und macht keines zum Standard: flow-back, bei dem jedes Dokument die anderen aktualisieren darf, flow-forward, bei dem jede Änderung einen neuen Ordner bekommt, und living spec, bei dem die Spec die einzige Quelle ist. Halten Sie das gewählte Modell in der Constitution oder in den Einstiegsnotizen des Teams fest.
4. Schicken Sie Spec und Code im selben Pull Request. Beginnen Sie das Review mit dem Diff der Spec.
5. Lassen Sie ein zweites Paar Augen prüfen. Das Ergebnis von converge oder verify des Agenten, der die Arbeit gemacht hat, ist ein Anfang; auf die Akzeptanzkriterien und den Diff der Spec sollte auch ein Mensch schauen.

Achten Sie nach einer Weile auf zwei Dinge: Ändern sich die Specs weiterhin mit dem Code, und wohin geht die Zeit fürs Review? Kretz’ Maßstab ist einfach: Hinkt die Spec dem Code hinterher, ist sie keine Quelle der Wahrheit mehr, sondern Dokumentation.