Spec Driven Development: Erst klären, dann programmieren

Das Ziel ist nicht mehr Dokumentation, sondern eine kurze, verbindliche Grundlage: Gründer können daran erkennen, ob das beschriebene Verhalten stimmt, Entwickler den technischen Entwurf hinterfragen und Reviewer festlegen, welche Nachweise vor dem Merge nötig sind.

Für den Einstieg eignet sich ein klar abgegrenztes Feature im bereits genutzten Repository. Ein Export, eine Freigaberegel oder eine Einstellung für Benachrichtigungen macht den Nutzen deutlicher als der Auftrag an einen Agenten, gleich eine ganze Anwendung zu spezifizieren.

Was ist Spec Driven Development?

Spec Driven Development mit KI-Agenten bedeutet, Planung, Aufgaben, Umsetzung und Prüfung an einer bereits geprüften Beschreibung des gewünschten Verhaltens auszurichten. Die Spezifikation hält fest, was passieren muss und warum. Der Plan beschreibt, wie die bestehende Anwendung das umsetzt. Die Aufgaben zerlegen diesen Plan in überprüfbare Arbeitsschritte.

Verwandte spezifikationsgetriebene Verfahren gab es schon vor KI: Beim Behavior Driven Development dienen Spezifikationen beispielsweise als ausführbare Tests. Diese Tradition passt zu dem hier beschriebenen Ablauf. Eine Markdown-Spezifikation ist allerdings noch kein ausführbarer Test. Cucumber-Dokumentation zu BDD.

Neu ist in der Praxis, dass Coding-Agenten diese Dokumente während der gesamten Umsetzung nutzen können. GitHub Spec Kit ist ein Open-Source-Toolkit, das die Arbeit eines Agenten strukturiert und den Prozess um ihn herum bereitstellt. Kiro, die Entwicklungsumgebung von AWS, integriert einen Spezifikationsworkflow direkt ins Produkt. Was Kunden tatsächlich erleben sollen, muss bei beiden Ansätzen weiterhin entschieden werden.

Dokumentation geprüft am 13. Oktober 2026: Die folgenden Befehlsnamen, Dateipfade und Funktionsbeschreibungen stammen aus der aktuellen Dokumentation von GitHub, Kiro, Anthropic und OpenAI. Das durchgespielte Feature dient der Veranschaulichung; es beschreibt weder einen behaupteten Produktiveinsatz noch eine gemessene Produktivitätsstudie.

Für Entwickler wird das Umsetzungsziel enger: Der Agent soll die bestehende Anwendung rund um das Feature wiederverwenden, statt sie neu zu entwerfen. Für Betriebsverantwortliche und Gründer rückt die entscheidende Prüfung nach vorn: Wer Daten exportieren darf, wird vor der Begutachtung des Exportbuttons geklärt. Für Einkaufsverantwortliche gilt: Die Methode verlangt keinen neuen Editor für das gesamte Entwicklungsteam. Der vorhandene Agent reicht für den Einstieg. Zusätzliche Struktur lohnt sich, wenn die Pflege der Dokumente zum Problem wird.

Spec Driven Development Schritt für Schritt

Die Dokumente bleiben getrennt, weil jedes eine andere Frage beantwortet. Ein Architekturdiagramm klärt keine fehlende Produktregel, und eine Aufgabenliste beweist nicht, dass das Feature funktioniert.

Die Entscheidung über das Verhalten liegt beim Gründer oder Product Owner. Die technische Leitung verantwortet, ob der Entwurf zum System passt. Der Agent kann beides vorbereiten. Flüssig formulierte Texte belegen aber nicht, dass die Entscheidungen richtig sind.

Tools für Spec Driven Development: Wie viel Struktur ist nötig?

Die Toolwahl hängt davon ab, wo die Abstimmung scheitert. GitHub Spec Kit passt zu einem Repository, in dem ein wiederholbarer Prozess um einen vorhandenen Agenten entstehen soll. Kiro eignet sich für Entwickler, die Anforderungen, Entwurf und Aufgabenausführung in ihrer Entwicklungsumgebung bündeln möchten. Einfache Dateien reichen für ein erstes Feature oder ein Team mit verlässlicher Review-Praxis.

GitHub Spec Kit: Befehle und Dateien im Überblick

GitHub Spec Kit liefert wiederverwendbare Anweisungen, Vorlagen und unterstützende Skripte. Die eigentliche Arbeit übernimmt der gewählte Coding-Agent. Die aktuelle README nennt die Kernabfolge ausdrücklich: Projektgrundsätze festlegen, Feature spezifizieren, Umsetzung planen, Aufgaben erstellen, implementieren und anschließend nach verbliebenen Lücken suchen.

Laut aktueller README sind Python 3.11 oder neuer, uv als Python-Paketinstaller und ein unterstützter Agent erforderlich. Das Einrichtungsbeispiel verwendet GitHub Copilot, den Coding-Assistenten von GitHub. Im Terminal werden diese Befehle ausgeführt:

uv tool install specify-cli
specify init my-project --integration copilot
cd my-project

Anschließend wird der Coding-Agent in diesem Verzeichnis gestartet. Die Anweisungen für den Workflow gehören einzeln in den Chat des Agenten; jedes Ergebnis wird vor dem nächsten Schritt geprüft. Es handelt sich nicht um Shell-Befehle.

Auf die Schreibweise kommt es an. Die README verwendet die standardmäßige Skills-Syntax von Copilot: /speckit-specify. Die ausführliche Befehlsreferenz nutzt die Punktschreibweise /speckit.specify. Bei der Skills-Integration von Codex lautet der Aufruf $speckit-specify. Maßgeblich ist die Syntax der installierten Integration; die Satzzeichen sind nicht austauschbar. Integrationsreferenz.

Diese Namen und Funktionen folgen der Agentic-SDD-Referenz von GitHub. Clarify, Checklist und Analyze bilden zusätzliche Prüfschritte. Die Constitution legt dauerhafte Projektregeln fest; sie sollte nicht für jedes kleine Feature neu geschrieben werden.

Beim Exportbeispiel beschreibt die Specify-Anweisung, wer exportieren darf, welche Datensätze dazugehören, was die Datei enthält und wie Fehler behandelt werden. Der Planungsschritt erhält den vorhandenen Stack und die Rahmenbedingungen des Repositorys. Akzeptanztests sollten ausdrücklich angefordert werden: Der Tasks-Befehl dokumentiert die Testerzeugung auf Anfrage. Eine generierte Aufgabenliste ist daher kein Beleg dafür, dass geeignete Tests enthalten sind.

Zu prüfen sind diese Dateien:

• .specify/memory/constitution.md: die Projektgrundsätze. Constitution-Vorlage.
• specs/<feature-directory>/spec.md: das Verhalten des Features. Feature-Verzeichnisse liegen normalerweise unter specs/; der Verzeichnisname wird erzeugt oder konfiguriert. Specify-Vorlage.
• plan.md und tasks.md im jeweiligen Feature-Verzeichnis: technischer Entwurf und Aufgabenaufteilung. Bei der Planung entstehen außerdem research.md, data-model.md und quickstart.md sowie contracts/ für relevante externe Schnittstellen. Plan-Vorlage, Tasks-Referenz.

Nach der Implementierung gleicht converge die Codebasis mit Spezifikation, Plan und Aufgaben ab. Findet es Lücken, ergänzt es Arbeit in tasks.md; den Code repariert es nicht selbst. Die zusätzlichen Aufgaben werden umgesetzt, anschließend wird erneut geprüft. Das Ergebnis „Converged“ liefert einen hilfreichen Anhaltspunkt für das Review, ersetzt aber weder Tests noch Freigabe.

Für eine bestehende Anwendung beginnt GitHubs Einführungsleitfaden damit, den Ausgangsstand zu sichern und das vorhandene Projekt direkt zu initialisieren. Der Befehl lautet specify init --here --force --integration <key>. Dabei wird <key> durch den dokumentierten Integrationsschlüssel ersetzt, etwa claude oder codex. Der Leitfaden warnt, dass --force bei Konflikten verwaltete Dateien ersetzen kann. Der entstandene Diff gehört deshalb geprüft. Es ist nicht nötig, erst die Spezifikationen der gesamten Anwendung zu rekonstruieren, bevor ihre nächste Änderung spezifiziert wird.

Die Grenze: Spec Kit kann Widersprüche zwischen Dokumenten aufdecken und trotzdem eine durchgängig falsche Geschäftsregel akzeptieren. Der Pflegeaufwand der zusätzlichen Dateien lohnt sich, wenn mehrere Personen oder Sitzungen dieselbe verbindliche Grundlage brauchen.

Spec Driven Development in der Kiro IDE: Specs, Steering und Hooks

Kiro trennt die Absicht eines Features von dauerhaften Projektvorgaben und automatischen Aktionen. Specs beschreiben das jeweilige Feature, Steering hält Konventionen für das gesamte Repository fest, und Hooks übernehmen wiederkehrende Prüfungen.

In der IDE, dem Code-Editor von Kiro, führt ein Klick auf + unter Specs oder die Auswahl Spec im Chat zum Einstieg. Danach folgen Feature und Requirements-First. Die Anforderungen werden geprüft, bevor technischer Entwurf und Aufgabenaufteilung akzeptiert werden. Das entstandene Feature-Verzeichnis enthält .kiro/specs/<feature-name>/requirements.md, design.md und tasks.md. Nach der Prüfung lassen sich die Aufgaben über die Aufgabenoberfläche starten. Kiro-Dokumentation zu Specs.

Kiro nutzt EARS, kurz für Easy Approach to Requirements Syntax, um eine Bedingung und das erwartete Systemverhalten auszudrücken. Für dieses Beispiel: „Wenn ein Mitglied einen Export anfordert, muss das System die Anfrage ablehnen und darf keine Exportdatei zurückgeben.“ Das ist konkret genug, um daraus einen Test abzuleiten. Feature-Specs.

Kiro bietet außerdem Design-First und Quick Spec. Design-First beginnt beim technischen Entwurf; Quick Spec erzeugt die Dokumente ohne die Freigabeschritte dazwischen. Versteht der Agent die Absicht eines Gründers immer wieder falsch, empfiehlt sich Requirements-First mit diesen Prüfungen. Wer die Prüfpunkte entfernt, entfernt genau den Teil des Prozesses, der dieses Problem adressiert.

Steering stellt dauerhaften Markdown-Kontext unter .kiro/steering/ bereit. Die Grundlagendateien product.md, tech.md und structure.md beschreiben Produkt, Stack und Repository-Struktur. In der IDE erzeugt Generate Steering Docs diesen Ausgangskontext. Er muss mit dem Repository abgeglichen werden. „Die bestehende Berechtigungsrichtlinie für Mitgliedschaften wiederverwenden“ gehört hierher, wenn die Vorgabe für mehrere Features gilt. „Nur Inhaber dürfen exportieren“ gehört dagegen in die Exportspezifikation. Steering-Dokumentation.

Hooks führen bei einem Ereignis Shell-Befehle oder Agenten-Prompts aus. Projektbezogene Hook-Dateien liegen aktuell unter .kiro/hooks/<id>.json; PostFileSave ist ein dokumentierter Auslöser. Ein gezielter Hook könnte vorhandene Exporttests starten, sobald sich der relevante Quellcode ändert. Dieselben Prüfungen gehören auch in die Continuous Integration, also die automatischen Prüfungen vorgeschlagener Codeänderungen. Ein lokaler Hook sollte nicht ihr einziger Ausführungsort sein. Laut Kiros aktueller Funktionsübersicht werden Hooks in IDE und CLI unterstützt, nicht aber in Web oder Mobile. Hooks-Dokumentation.

Die Grenze: Eine automatisch erzeugte Anforderung kann eine Annahme festschreiben, der niemand zugestimmt hat. Berechtigungen, leere Ergebnisse und Fehlerverhalten müssen vor dem Entwurf geprüft werden. Der Spec-Modus schafft Struktur, ersetzt aber keine fehlenden Produktentscheidungen.

Spec Driven Development mit Claude Code

Claude Code, der Coding-Agent von Anthropic, kann diesem Ablauf mit einer Featurespezifikation und Plan Mode folgen. Um die Methode auszuprobieren, ist kein zusätzliches Spezifikationsframework nötig.

Die Datei specs/workspace-export/spec.md wird selbst geschrieben oder als Entwurf des Agenten geprüft. Danach startet die Terminalsitzung im Planungsmodus:

claude --permission-mode plan

Claude erhält den Auftrag, diese Datei zu lesen, den bestehenden Code im Umfeld des Exports zu untersuchen und einen Umsetzungsplan mit Bezug zu den Akzeptanzkriterien vorzuschlagen. Vor der Freigabe zur Implementierung sollte er offene Fragen und die konkret vorgesehenen Prüfungen benennen.

Plan Mode ist für Untersuchungen und die Ausarbeitung eines Vorgehens gedacht. Anthropic dokumentiert eine Ausnahme für interaktive Terminalsitzungen, in denen Berechtigungsumgehungen verfügbar sind: Dort werden die Bearbeitungssperren des Planungsmodus nicht durchgesetzt. Soll die Freigabegrenze greifen, muss die Sitzung ohne aktivierte Umgehung starten. Dokumentation der Berechtigungsmodi.

Nach der Prüfung wird das akzeptierte Vorgehen in specs/workspace-export/plan.md gespeichert, die zugehörige Checkliste in tasks.md. Erst danach folgt der Auftrag zur Umsetzung. Diese Pfade sind eine in diesem Artikel vorgeschlagene Konvention; Plan Mode verspricht nicht, die Dateien automatisch anzulegen. Der Leitfaden zu Claude Code Plan Mode erklärt die Steuerung und den Übergang zur Freigabe.

Dauerhafte Repository-Anweisungen gehören in CLAUDE.md, wie im Leitfaden zum Teamgedächtnis beschrieben. Das Verhalten eines einzelnen Features gehört in dessen Spezifikation. Sonst kann aus einer vorübergehenden Exportanforderung eine dauerhafte Anweisung werden, die unbeteiligte Arbeiten beeinflusst.

Die Grenze: Ein Plan, der nur in einem Gespräch steht, geht leicht verloren oder wird später widersprüchlich ausgelegt. Ihn zu speichern hilft nur, wenn sich Umsetzung und Review anschließend ausdrücklich darauf beziehen.

Codex: Plan Mode mit derselben Spezifikationsdatei

Codex, der Coding-Agent von OpenAI, unterstützt dieselbe schlanke Übergabe. In einem CLI-Chat, der gerade keine Aufgabe bearbeitet, startet /plan die Planung; der Auftrag kann direkt im selben Aufruf stehen. Offizielle Befehlsdokumentation.

Ein geeigneter Auftrag lautet: „Lies specs/workspace-export/spec.md. Untersuche die bestehende Mitgliedschaftsrichtlinie, die Aufgabenabfrage und die Tests. Schlage den kleinstmöglichen Umsetzungsplan vor, der alle Anforderungen erfüllt. Benenne fehlende Entscheidungen vor der Implementierung.“

Nach der Prüfung des Plans werden die vereinbarten Dateien gespeichert. Anschließend erhält Codex den Auftrag, die Aufgaben umzusetzen und im Abschlussbericht jede Anforderung den zugehörigen Tests zuzuordnen. Dauerhafte Repository-Anweisungen stehen in AGENTS.md; /init kann dafür ein Grundgerüst anlegen. Der Leitfaden zur Einrichtung der Codex CLI behandelt die Startumgebung.

OpenAI beschreibt ebenfalls, wie sich Spezifikationen, Pläne und Fortschritte bei längeren Arbeiten in Markdown festhalten lassen. Entscheidend ist, dass eine spätere Sitzung die vereinbarte Grundlage wieder öffnen kann. Die Grenze: Plan Mode hält eine separate Featurespezifikation nicht von selbst aktuell. Ihre Pflege muss Teil der Änderungsprüfung sein. Von OpenAI dokumentierter Workflow.

Spec Driven Development am Beispiel: CSV-Export eines Workspace

Ein kleiner CSV-Export, also der Download von Datensätzen als durch Kommas getrennte Werte, zeigt, warum vorab geklärtes Verhalten Nacharbeit in mehreren Dateien verhindern kann. „CSV-Export ergänzen“ überlässt dem Agenten die Entscheidung über Nutzerrolle, Datenumfang, Seitennavigation und Dateiformat. Hinter einem ansprechenden Button kann bei jeder dieser Fragen die falsche Antwort stecken.

Das folgende Beispiel spielt die Umsetzung in einer bestehenden Aufgabenverwaltung durch. Pfade, Anforderungskennungen und vorgeschlagene Tests dienen der Erklärung. Sie sind keine Aussage über ein Repository, das für diesen Artikel getestet wurde oder in dem diese Änderungen gemergt wurden.

Die Spezifikation auf einer Seite

Der folgende Inhalt gehört in die spec.md des Features. Dieselben Verhaltensanforderungen können auch in Kiros requirements.md stehen:

In R2 steckt eine entscheidende Weichenstellung: „Alle passenden Ergebnisse“ bedeutet etwas anderes als „die sichtbare Seite“. Wird das vor der Umsetzung geklärt, wirkt es sich sofort auf Abfrage und Testplan aus. Fällt die Entscheidung erst nach der Demo, müssen möglicherweise beide überarbeitet werden.

R4 benennt bewusst eine Entscheidung, für die konkrete Beispiele nötig sind. Vor der Freigabe der Spezifikation muss feststehen, wie mit Eingaben umgegangen wird, die als Tabellenformeln wirken. Die Beispiele dazu werden dokumentiert. „Exporte sicher machen“ würde dem Agenten überlassen, die Richtlinie selbst zu wählen.

Der Plan: die bestehende Anwendung sinnvoll erweitern

Der Plan sollte die vorhandene Sitzungs- und Mitgliedschaftsrichtlinie wiederverwenden, die Filterlogik der Aufgabenliste herauslösen oder erneut nutzen und eine Exportantwort ergänzen, ohne die Listenantwort zu verändern. Der Export muss die serverseitige Berechtigungsprüfung durchlaufen. Der Zugriff auf den Workspace wird aus der authentifizierten Mitgliedschaft abgeleitet; erst innerhalb dieses zulässigen Datenbereichs werden die angeforderten Filter angewendet.

Gibt es im Repository bereits einen etablierten CSV-Serialisierer, sollte dieser verwendet werden. Festzulegen sind Inhalts- und Download-Header, die Richtlinie für sichere Felder, das Fehlerverhalten und die Tests. Der Button nutzt die vorhandenen Lade- und Fehlerzustände der Anwendung.

Der Plan muss außerdem prüfen, ob die erwartete Ergebnismenge mit den bestehenden Grenzen für Anfragen und Arbeitsspeicher vereinbar ist. Passt ein Export aller Ergebnisse nicht hinein, geht der Konflikt zurück an den Feature-Verantwortlichen. Dann wird entweder ein begrenzter Export vereinbart oder eine Hintergrundverarbeitung separat eingeplant. Der Agent darf weder stillschweigend eine Höchstmenge erfinden noch entgegen R6 ein Jobsystem einführen.

Die Aufgaben: jede Änderung überprüfbar machen

Aus dem Plan werden Arbeitsschritte, die im Review nachvollziehbar sind:

1. Das bestehende Verhalten der Aufgabenliste und die gemeinsamen Filterregeln durch Regressionstests absichern.
2. Tests der Anfrageberechtigung für Inhaber, Mitglieder, ehemalige Inhaber und einen anderen Workspace ergänzen.
3. Die auf den zulässigen Datenbereich begrenzte Abfrage und die CSV-Antwort gemäß der vereinbarten Feldrichtlinie implementieren.
4. Exportbedienelement, Ladezustand und Fehleranzeige ergänzen.
5. Die Akzeptanzprüfungen abschließen und den Diff auf Änderungen außerhalb des Features untersuchen.

Diese Aufteilung gehört zum Beispiel. Ein Toolkit kann eine andere Liste erzeugen; entscheidend ist, ob sie die Vereinbarung vollständig abdeckt.

In einer TypeScript-Anwendung könnte die zu prüfende Codeänderung server/exports/tasks.ts für Berechtigungen, Filterung und Antwort, ui/tasks/ExportButton.tsx für die Bedienung und tests/task-export.test.ts für die Akzeptanzfälle umfassen. Diese Pfade dienen der Veranschaulichung und sind keine vorgeschriebenen Framework-Konventionen. Ein neuer Queue-Worker oder eine Datenbankmigration wäre ein Hinweis auf eine Erweiterung des Umfangs, die vor dem Merge geklärt werden muss.

Von Akzeptanzkriterien zur Merge-Entscheidung

Gefordert sind Nachweise für das Verhalten, nicht bloß eine Liste der vom Agenten bearbeiteten Dateien. Die Pull-Request-Beschreibung sollte Anforderungen mit Prüfungen wie diesen verbinden:

Im Review werden diese Prüfungen mit der Spezifikation verglichen, Berechtigungs- und Abfragecode untersucht und der vereinbarte Nutzerablauf in der üblichen Review-Umgebung des Projekts ausprobiert. Hat der Agent sowohl Implementierung als auch Tests geschrieben, müssen die erwarteten Ergebnisse unabhängig davon geprüft werden. Ein Test kann dieselbe falsche Annahme zuverlässig bestätigen, die bereits im Code steckt.

Angenommen, beim Review fällt auf, dass der Endpunkt nur die aktuelle Seite liest. Will der Inhaber weiterhin alle passenden Ergebnisse, bleibt R2 bestehen: Die Abfrage wird korrigiert und ein Test mit Treffern jenseits dieser Seite ergänzt. Ändert der Inhaber dagegen den Umfang, werden R2, Plan und Tests vor der Freigabe gemeinsam angepasst.

Das Feature wird gemergt, wenn die Nachweise zur Vereinbarung passen: Geprüfte Spezifikation, endgültiger Plan, abgeschlossene Aufgabendokumentation, Implementierung und Tests gehören in denselben Pull Request. Dort werden auch akzeptierte Änderungen am Umfang festgehalten. Nach dem Merge wird die Spezifikation entweder als aktuell gültige Vereinbarung gepflegt oder als historische Feature-Dokumentation gekennzeichnet. Eine veraltete Spezifikation, die weiterhin verbindlich wirkt, bereitet die nächste Verwirrung vor.

Der Nutzen entsteht dadurch, dass Berechtigungen und Seitennavigation geklärt sind, bevor sich Annahmen darüber in der Implementierung verteilen. Spezifikation, Tests und Code halten dann auch nach dem Merge dieselbe Entscheidung fest.

Was kostet die Methode, und wann lohnt sie sich?

Die Kosten bestehen aus Zeit für Prüfung und Pflege sowie der Agentenarbeit für Entwurf und Umsetzung. Spec Kit ist Open Source, doch für den angeschlossenen Coding-Agenten gelten weiterhin dessen eigene Nutzungsbedingungen. Reine Markdown-Dateien erfordern kein zusätzliches Abo für ein Spezifikationstool; die Modellnutzung wird dadurch aber nicht kostenlos.

Kiros reguläre kommerzielle Preise nennen Free für $0 pro Monat mit 50 Credits und Pro für $20 pro Nutzer und Monat mit 1,000 Credits, jeweils vor anfallenden Steuern. Vier Pro-Abos kosten damit 4 × $20 = $80 pro Monat, vor zusätzlichen Credits und Steuern. Das ist eine Rechnung über Nutzerlizenzen, keine Prognose darüber, wie viele Features sich damit ausliefern lassen. Kiros eigene Preisseite.

Zusätzlich gekaufte Credits kosten je $0.04. Laut Kiro verbrauchen das Verfeinern von Spezifikationen, die Aufgabenausführung und die Ausführung von Agenten-Hooks Credits. Eine komplexe Spezifikationsaufgabe kann mehr als einen Credit benötigen. Ohne die tatsächliche Arbeitslast zu beobachten, lässt sich „Credits“ nicht belastbar in „fertige Features“ umrechnen. Kiros Definitionen zum Credit-Verbrauch.

Die wirtschaftliche Prüfung ist einfach: Der zusätzliche Aufwand für Spezifikation, Review und Pflege muss geringer sein als die vermiedene Nacharbeit. Diese Kosten sollten im eigenen Prozess erfasst werden. Wenn eine Methode zusätzliche Dokumente erzeugt, dieselben Entscheidungen aber weiterhin erst im Code-Review fallen, rechtfertigt sie ihren Aufwand nicht.

Was ist überzogen, und wann ist der Aufwand zu groß?

Überzogen ist das Versprechen, ein ausreichend ausführliches Dokument mache den Agenten zuverlässig fehlerfrei. Eine Spezifikation kann falsch sein, die Implementierung kann sie ignorieren, und Tests können ihre falschen Annahmen wiederholen.

Entscheidend ist der Unterschied zwischen formuliertem Sollverhalten und durchgesetztem Verhalten. Eine Anforderung besagt, dass Mitglieder nicht exportieren dürfen; eine serverseitige Prüfung und ihre Tests helfen, diese Regel durchzusetzen. Eine Anforderungscheckliste prüft die Beschreibung. Sie führt die Anwendung nicht aus. Wer beides gleichsetzt, schafft falsche Sicherheit.

Ein weiteres Problem sind auseinanderlaufende Dokumente. Ändert ein Entwickler das Berechtigungsverhalten ausschließlich im Code, kann der nächste Agent die Anwendung auf den veralteten Stand der Spezifikation „zurückkorrigieren“. Verhaltensänderungen müssen daher auch die betreffende Vereinbarung aktualisieren, oder diese wird ausdrücklich archiviert. Mehr dauerhaft verfügbarer Kontext hilft nur, solange er zutrifft.

Jetzt einsetzen, wenn der Agent wiederholt Berechtigungen, Randfälle, Integrationen oder Akzeptanzkriterien übersieht. Geeignet ist ein Feature, dessen Unklarheiten mehrere Komponenten oder Reviewer betreffen.

Mit einer formalen Spezifikation warten, wenn noch offen ist, ob überhaupt jemand das Feature braucht. Zunächst hilft ein Wegwerfprototyp oder die Untersuchung der offenen Frage. Eine ausgefeilte Spezifikation für eine ungeprüfte Idee kann eine falsche Investition wie eine bereits geklärte Sache erscheinen lassen.

Kleine Korrekturen klein halten, wenn die gewünschte Änderung klar und lokal begrenzt ist: ein Tippfehler, eine Anpassung an den etablierten Stil oder ein eng umrissener Fehler mit eindeutigem Regressionstest. Dann reicht es, das gewünschte Verhalten festzuhalten und zu prüfen. Ein vollständiger Durchlauf aus Constitution, Plan und Aufgaben kann mehr Aufmerksamkeit kosten, als die Änderung erfordert.

Maßgeblich ist nicht die Zahl der Codezeilen, sondern die Zahl der folgenreichen Annahmen, die der Agent sonst selbst treffen müsste.

Die erste Woche mit Spec Driven Development

Der Einstieg beginnt mit einem kleinen Feature, das bereits im Backlog steht. Der Verantwortliche gibt eine einseitige Verhaltensspezifikation frei, einschließlich Ausschlüssen und Fehlerfällen. Der vorhandene Agent im Planungsmodus oder der entsprechende Ablauf in Spec Kit beziehungsweise Kiro schlägt daraufhin einen Plan vor, der sich auf das tatsächliche Repository stützt.

Offene Fragen werden vor der Umsetzung geprüft. Die Aufgabenliste muss ihre Verbindung zu den Anforderungen zeigen. Beim Pull Request werden die Nachweise an derselben Vereinbarung gemessen und geänderte Entscheidungen dokumentiert. Der Prozess sollte nur so aufwendig sein, wie es die Unklarheiten rechtfertigen.

Den Newsletter abonnieren: praktische Ansätze, um mit KI Produkte zu entwickeln und zu betreiben.