Spec-Driven Development vollständig erklärt: AI Coding Agent mit Software-Spezifikationen entwickeln

Der Gewinner ist Spec-Driven Development, wenn ein AI Coding Agent wiederholt Anforderungen verliert, unkontrolliert Dateien verändert oder erzeugten Code nicht nachvollziehbar abgenommen werden kann. Die Methode ist dann sinnvoll, wenn eine Software-Spezifikation als versioniertes Arbeitsartefakt geführt wird und jede Änderung über Projektregeln, Design, einzeln ausführbare Aufgaben und prüfbare Ergebnisse bis in den Code verfolgt werden kann.

Diese Anleitung richtet sich an:

• Einzelentwickler, die ihren AI Coding Agent nicht nach jeder Änderung neu korrigieren möchten.
• Technische Verantwortliche, die AI-gestützte Entwicklung in einen nachvollziehbaren Teamprozess überführen wollen.
• Entwicklungsteams, die für erzeugten Code eine belastbare Prüf- und Abnahmekette benötigen.

1. Vor dem ersten Prompt: Projektgrenzen dauerhaft festhalten

Spec-Driven Development beginnt nicht mit einer möglichst ausführlichen Eingabe, sondern mit Regeln, die nicht bei jedem Arbeitsschritt erneut erklärt werden müssen. Der AI Coding Agent benötigt zunächst einen stabilen Rahmen für Entscheidungen.

Dazu gehören mindestens:

• verwendeter Technologiestack und zugelassene Bibliotheken,
• Verzeichnis- und Dateiregeln,
• Namenskonventionen,
• Anforderungen an Tests und statische Prüfungen,
• Datenschutz- und Sicherheitsgrenzen,
• Bereiche, die nicht verändert werden dürfen,
• Umgang mit geheimen Zugangsdaten,
• Definition of Done,
• Verfahren für Migrationen, Rückgaben und fehlerhafte Änderungen.

Diese Regeln sollten in einer eigenen Datei oder einem vergleichbaren versionierten Projektartefakt liegen. Bei Spec Kit ist dafür beispielsweise eine Projektverfassung vorgesehen, die von späteren Arbeitsphasen berücksichtigt wird. Die offizielle Dokumentation beschreibt dafür den Befehl constitution und die Datei .specify/memory/constitution.md. Offizielle Beschreibung der Projektverfassung

Der wichtigste Unterschied zu einem gewöhnlichen Prompt lautet: Eine Projektregel beschreibt nicht nur eine einzelne Aufgabe, sondern eine Grenze für alle folgenden Aufgaben. „Verwenden Sie TypeScript“ ist eine technische Vorgabe. „Ändern Sie keine Dateien außerhalb von src/ und tests/, außer wenn die Aufgabe ausdrücklich eine Migration verlangt“ ist dagegen eine kontrollierbare Änderungsgrenze.

Für Datenschutz und Stabilität sollte die Verfassung außerdem festlegen, welche Daten ein Agent lesen darf, ob produktive Zugangsdaten ausgeschlossen sind und welche Tests in einer isolierten Umgebung ausgeführt werden. Gerade bei externen Entwicklungsumgebungen dürfen Quellcode, Protokolle und Testdaten nicht stillschweigend in nicht freigegebene Dienste kopiert werden.

Austrittsbedingung dieser Phase

Die Vorbereitungsphase ist abgeschlossen, wenn ein neuer Agent-Auftrag ohne zusätzliche Erklärung erkennen kann:

1. welche Dateien er grundsätzlich verändern darf,
2. welche Werkzeuge und Bibliotheken erlaubt sind,
3. welche Prüfungen vor einer Abnahme erforderlich sind,
4. welche Sicherheits- und Datenschutzgrenzen unveränderlich bleiben.

Fehlt einer dieser Punkte, sollte noch keine Implementierung angefordert werden.

2. Aus dem Wunsch eine prüfbare Specification machen

Eine Specification beschreibt, was das System leisten soll und woran die Erfüllung erkannt wird. Sie ist keine Sammlung von Marketingformulierungen und auch kein Ersatz für den technischen Entwurf.

Ein geeigneter Aufbau enthält:

• Ziel und betroffene Nutzergruppe,
• Ausgangssituation und Auslöser,
• erwartetes Verhalten,
• Eingaben und Ausgaben,
• Fehler- und Ausnahmefälle,
• Rollen und Berechtigungen,
• Daten- oder Schnittstellenanforderungen,
• nichtfunktionale Anforderungen,
• messbare oder manuell prüfbare Akzeptanzkriterien.

Ein schwaches Beispiel wäre: „Die Anwendung soll schnell und benutzerfreundlich sein.“ Ein besseres Beispiel lautet: „Wenn eine nicht angemeldete Person den geschützten Bereich öffnet, wird keine Inhaltsseite ausgeliefert. Stattdessen erscheint eine Anmeldemöglichkeit. Nach einer erfolgreichen Anmeldung wird die ursprünglich angeforderte Adresse erneut geöffnet.“

Die zweite Formulierung ist wertvoller, weil daraus Testfälle, Sicherheitsprüfungen und eine manuelle Abnahme entstehen können. Sie schreibt dem Agent jedoch nicht vor, ob eine bestimmte Middleware, ein bestimmtes Datenbankmodell oder eine bestimmte Komponente verwendet werden muss. Diese Entscheidungen gehören in den Plan, solange sie nicht durch bestehende Projektregeln festgelegt sind.

Eine vollständige Specification muss außerdem negative Fälle enthalten. Für jedes zentrale Verhalten sollte gefragt werden:

• Was geschieht bei fehlenden Eingaben?
• Was geschieht bei ungültigen Eingaben?
• Was geschieht bei fehlenden Berechtigungen?
• Was geschieht bei einem externen Fehler?
• Was geschieht, wenn derselbe Vorgang zweimal ausgeführt wird?
• Welche Daten dürfen in Protokollen erscheinen?
• Wie lässt sich der Zustand nach einem Fehler wiederherstellen?

Damit wird verhindert, dass der AI Coding Agent nur den idealen Ablauf implementiert und die später teuersten Randfälle offenlässt.

Die richtige Granularität einer Software-Spezifikation

Eine Specification ist zu grob, wenn zwei Entwickler daraus widersprüchliche Implementierungen ableiten könnten. Sie ist zu eng, wenn sie bereits jede interne Funktion, jede Variable und jede Zeile vorgibt. Die brauchbare Mitte liegt bei beobachtbarem Verhalten, Grenzen und Abnahmekriterien.

Als Faustregel kann eine Anforderung in die Specification aufgenommen werden, wenn sie mindestens eine der folgenden Fragen beantwortet:

• Welches Verhalten muss ein Nutzer beobachten?
• Welche Eingabe wird akzeptiert oder abgewiesen?
• Welche Ausgabe oder Zustandsänderung ist erforderlich?
• Welche Sicherheits- oder Datenschutzgrenze darf nicht verletzt werden?
• Mit welchem Test, Prüfskript oder manuellen Schritt wird die Erfüllung nachgewiesen?

3. Vom Anforderungsdokument zum technischen Plan

Erst nach der fachlichen Specification sollte der AI Coding Agent einen technischen Plan erzeugen. Der Plan verbindet die Anforderungen mit Architektur, Datenmodell, Schnittstellen, Abhängigkeiten und Teststrategie.

Ein guter Plan enthält:

• betroffene Module und Dateien,
• Datenstrukturen und Zustandsübergänge,
• externe Schnittstellen,
• technische Entscheidungen mit Begründung,
• Risiken und offene Fragen,
• notwendige Migrationen,
• Testebenen,
• Rückfall- oder Wiederherstellungsstrategie.

Der Agent sollte vor der Planerstellung nicht nur um „eine Lösung“, sondern ausdrücklich um eine Auswirkungsanalyse gebeten werden. Dadurch muss er offenlegen, welche bestehenden Komponenten betroffen sind und welche Annahmen noch unbestätigt bleiben.

Bei größeren Vorhaben ist ein „Spec of Specs“-Ansatz sinnvoll: Ein übergeordnetes Vorhaben wird in mehrere kleinere, unabhängig spezifizierbare Teilfunktionen zerlegt. Die offizielle Dokumentation beschreibt diesen Ansatz für Funktionen, die sonst den Kontext eines einzelnen Durchlaufs überlasten könnten. Jede Teilspezifikation erhält eigene Dokumente für Anforderungen, Plan und Aufgaben. Konzept der aufgeteilten Spezifikationen

Das ist nicht nur eine Organisationsfrage. Kleinere Spezifikationen begrenzen auch die Zahl gleichzeitig veränderter Module. Dadurch lässt sich ein Fehler eher einer Anforderung oder einer Aufgabe zuordnen, statt die gesamte Änderung zurücksetzen zu müssen.

4. Aufgaben so schneiden, dass jede Änderung überprüfbar bleibt

Aus dem technischen Plan entsteht eine Aufgabenliste. Dabei sollte nicht nach der Reihenfolge des Schreibens, sondern nach Abhängigkeiten und unabhängigem Nutzerwert aufgeteilt werden.

Eine gute Aufgabe enthält:

• eine unveränderliche Kennung,
• eine kurze Zielbeschreibung,
• betroffene Dateipfade,
• notwendige Voraussetzungen,
• erwartete Tests oder Prüfungen,
• ein klares Ende.

Die offizielle Aufgabenstruktur sieht unter anderem eine Kennzeichnung für parallel ausführbare Aufgaben vor. Außerdem werden Aufgaben nach Nutzerwert beziehungsweise User Story gruppiert und mit konkreten Pfaden verbunden. Vorlage für ausführbare Aufgaben

Eine Aufgabe wie „Benutzerverwaltung fertigstellen“ ist zu groß. Besser wären beispielsweise:

1. Datenmodell für Konten und Rollen anlegen.
2. Validierung für die Registrierung ergänzen.
3. Anmeldeablauf mit Fehlerfällen implementieren.
4. Zugriffsschutz für einen einzelnen Endpunkt ergänzen.
5. Tests für erlaubte und abgewiesene Rollen ausführen.
6. Manuelle Prüfung der Fehlermeldungen durchführen.

Diese Aufteilung verhindert, dass eine einzelne Agent-Runde gleichzeitig Datenbank, Geschäftslogik, Benutzeroberfläche und Berechtigungssystem verändert.

Aufgaben- und Planvergleich

Artefakt	Beantwortet vor allem	Typischer Inhalt	Abnahme
Projektregeln	Was bleibt immer gültig?	Stack, Grenzen, Sicherheit, Qualitätsregeln	Regeln sind eindeutig und widerspruchsfrei
Specification	Was muss das Produkt leisten?	Verhalten, Eingaben, Ausgaben, Ausnahmen	Anforderungen sind test- oder prüfbar
Technischer Plan	Wie wird es im System umgesetzt?	Module, Daten, Schnittstellen, Risiken	Auswirkungen und Entscheidungen sind nachvollziehbar
Aufgabenliste	Was wird als Nächstes geändert?	Pfade, Reihenfolge, Abhängigkeiten, Tests	Jede Aufgabe besitzt ein klares Ende

Die Aufgabe ist klein genug, wenn der Agent vor der Änderung nur einen begrenzten Teil des Repositorys laden muss und nach der Änderung ein nachvollziehbares Prüfergebnis liefern kann. Muss er dagegen mehrere unabhängige Geschäftsbereiche gleichzeitig verstehen, sollte die Aufgabe weiter geteilt werden.

5. Code nur innerhalb eines kontrollierten Aufgabenfensters ändern

Während der Umsetzung sollte jede Agent-Runde nur drei Informationsgruppen erhalten:

1. die aktuell relevante Anforderung,
2. den technischen Ausschnitt und die betroffenen Dateien,
3. die konkreten Prüf- und Ausführungsbefehle.

Das gesamte Repository ungefiltert in jede Runde zu geben, wirkt zunächst bequem, erhöht aber das Risiko, dass der Agent veraltete Annahmen aus fremden Modulen übernimmt oder Änderungen außerhalb des vereinbarten Umfangs vornimmt.

Vor der Änderung sollte der Agent einen kurzen Plan ausgeben:

• Welche Dateien werden geändert?
• Welche bestehende Logik wird wiederverwendet?
• Welche Annahmen werden getroffen?
• Welche Risiken bestehen?
• Welche Prüfung folgt unmittelbar danach?

Nach der Änderung gehören mindestens diese Informationen zum Ergebnis:

• geänderte Dateien,
• fachliche Auswirkung,
• ausgeführte Prüfungen,
• fehlgeschlagene Prüfungen,
• offene Annahmen,
• nicht bearbeitete Punkte.

Ein Agent darf ein fehlerhaftes Testergebnis nicht durch eine neue, unpräzise Anweisung „wegoptimieren“. Wenn ein Test scheitert, wird zuerst entschieden, ob die Specification, der technische Plan oder die Implementierung falsch ist. Erst danach wird eine gezielte Folgeaufgabe erzeugt.

6. Mit einer Rückverfolgbarkeitsmatrix abnehmen

Die Abnahme sollte nicht bei „Tests sind grün“ enden. Ein Test kann erfolgreich sein, obwohl eine wichtige Anforderung gar nicht abgedeckt wurde. Deshalb wird jede zentrale Specification mit mindestens einem Nachweis verbunden.

Spezifikationspunkt	Nachweis	Verantwortlich	Ergebnis
Gültige Eingabe wird verarbeitet	Automatischer Funktionstest	Entwicklung	bestanden / offen
Ungültige Eingabe wird abgewiesen	Negativtest mit Fehlermeldung	Entwicklung	bestanden / offen
Zugriff bleibt geschützt	Berechtigungs- und Schnittstellentest	Entwicklung	bestanden / offen
Daten erscheinen korrekt	Manuelle Prüfung mit Beispieldaten	Fachseite	bestanden / offen
Fehlerzustand ist wiederherstellbar	Wiederholungs- oder Rollback-Test	Betrieb	bestanden / offen

Damit werden mindestens vier typische Fehlerquellen sichtbar: nicht getestete Anforderungen, Tests ohne fachliche Bedeutung, manuelle Abnahmen ohne Protokoll und Änderungen, die zwar technisch funktionieren, aber Sicherheitsgrenzen verletzen.

Die Abnahme sollte außerdem zwischen drei Ergebnissen unterscheiden:

• erfüllt: Nachweis liegt vor;
• nicht erfüllt: konkrete Abweichung ist dokumentiert;
• nicht geprüft: es fehlt noch ein Test oder eine fachliche Entscheidung.

„Nicht geprüft“ darf nicht als „wahrscheinlich erfüllt“ behandelt werden.

Für Konsistenzprüfungen kann ein Agent zusätzlich die Specification, den Plan und die Aufgabenliste gegeneinander analysieren. Die aktuelle Referenz dokumentiert dafür eigene Analyse- und Konvergenzschritte, die nach der Aufgabenplanung beziehungsweise nach der Implementierung eingesetzt werden können. Referenz zu Analyse und Konvergenz

7. Änderungen versionieren, bevor der Agent weiterarbeitet

Eine häufige Ursache für außer Kontrolle geratene Änderungen ist, dass nur der Quellcode versioniert wird. Wenn die Specification außerhalb der Versionsverwaltung liegt, verliert das Team den eigentlichen Entscheidungsgrund für eine Änderung.

Specification, Plan, Aufgaben, Tests und Implementierung sollten deshalb im selben Versionskontrollprozess weiterentwickelt werden. Für jede Anforderungsänderung gilt:

1. Änderung fachlich formulieren.
2. Betroffene Anforderungen und Abnahmekriterien markieren.
3. Auswirkungen auf Architektur, Schnittstellen und Daten prüfen.
4. Veraltete Aufgaben schließen oder ersetzen.
5. Tests und Beispiele aktualisieren.
6. Erst danach den Agent mit der Implementierung beauftragen.
7. Abnahme erneut gegen die geänderte Specification durchführen.

Die Aufgabenkennung sollte stabil bleiben, sobald andere Artefakte auf sie verweisen. Das unterstützt die Rückverfolgbarkeit, weil Kommentare, Testfälle und Review-Entscheidungen nicht durch eine nachträgliche Umbenennung ihren Bezug verlieren.

Bei langfristigen Projekten sollte zusätzlich festgehalten werden, welche Specification-Version mit welcher Implementierung ausgeliefert wurde. Das erleichtert Fehlersuche, Rückgaben und Datenschutzprüfungen, insbesondere wenn mehrere Entwicklungsumgebungen oder externe Testsysteme beteiligt sind.

8. Die wichtigsten Grenzen der Methode realistisch bewerten

Spec-Driven Development beseitigt keine unklaren Geschäftsentscheidungen. Wenn die verantwortliche Fachseite nicht festlegt, ob ein Vorgang wiederholbar sein muss oder welche Rolle Zugriff erhalten darf, kann auch eine sauber strukturierte Specification diese Lücke nicht selbstständig schließen.

Weitere Grenzen sind:

• Zu viele Regeln können den Agent mit widersprüchlichen Vorgaben blockieren.
• Zu große Specifications führen erneut zu Kontextverlust.
• Automatische Tests prüfen nur das, was tatsächlich beschrieben wurde.
• Ein sauberer Plan schützt nicht vor falschen Annahmen über bestehende Systeme.
• Sicherheits- und Datenschutzanforderungen benötigen häufig menschliche Freigaben.
• Ein externer Agent-Arbeitsplatz kann bei fehlenden Zurücksetzungs- und Protokollierungsfunktionen schwer auditierbar sein.

Die Methode lohnt sich daher besonders bei Funktionen mit mehreren Abhängigkeiten, wiederkehrenden Änderungswünschen, hohen Abnahmekosten oder mehreren beteiligten Rollen. Für einen sehr kleinen Prototyp kann eine vollständige Dokumentenkette mehr Aufwand verursachen als Nutzen bringen. In diesem Fall sollte der Umfang reduziert werden, nicht aber die Grundregel: Auch ein Prototyp benötigt eine klare Grenze und eine überprüfbare Definition des Ergebnisses.

9. Umsetzung mit einer kontrollierten Arbeitsumgebung vorbereiten

Bevor ein AI Coding Agent produktiv in den Entwicklungsprozess aufgenommen wird, sollte die technische Umgebung selbst geprüft werden. Erforderlich sind ein reproduzierbarer Projektstand, ein sauberer Versionswechsel, isolierte Testdaten, definierte Prüfskripte und eine Möglichkeit, fehlerhafte Änderungen ohne manuellen Dateivergleich zurückzusetzen.

Für Teams, die einen entfernten Mac als Entwicklungs- oder Testumgebung einsetzen, gehören außerdem Zugriffsschutz, getrennte Benutzerkonten, sichere Schlüsselverwaltung, Protokollierung und eine klare Löschroutine zur Spezifikation der Umgebung. Zutcloud beschreibt im Help Center für Entwicklungs- und Zugriffsfragen die verfügbaren Hilfswege; bei organisationsspezifischen Anforderungen kann zusätzlich der Kontakt zum technischen Ansprechpartner genutzt werden.

Umgebung	Geeignet, wenn	Kritische Prüfung	Weniger geeignet, wenn
Lokaler Rechner	Quellcode, Testdaten und Gerätezugriff lokal bleiben müssen	Wiederherstellung nach Agent-Änderungen	mehrere Personen denselben reproduzierbaren Zustand benötigen
Temporäre entfernte Mac-Umgebung	ein sauberer Teststand, Apple-spezifische Prüfungen oder isolierte Experimente benötigt werden	Zugriff, Zurücksetzung, Datenlöschung und Netzwerkregeln	dauerhaft hohe Last oder physische Zusatzgeräte erforderlich sind
Dauerhafte eigene Hardware	lange stabile Nutzung und lokale Peripherie im Vordergrund stehen	Wartung, Ersatz, Sicherheitsupdates und Auslastung	nur kurze Tests oder wechselnde Projekte geplant sind

Vor der ersten echten Aufgabe sollte der Ablauf mit einem kleinen, nicht vertraulichen Beispiel durchgespielt werden. Dabei wird geprüft, ob der Agent die Projektregeln liest, die Specification korrekt abgrenzt, Aufgaben mit Pfaden erzeugt, nur den erlaubten Umfang ändert und nach der Prüfung ein nachvollziehbares Ergebnis liefert.

10. Abnahme-Checkliste für den ersten vollständigen Durchlauf

• [ ] Projektregeln mit Technologie-, Sicherheits- und Änderungsgrenzen versioniert.
• [ ] Ziel und Nutzerverhalten in einer Specification beschrieben.
• [ ] Eingaben, Ausgaben und Fehlerfälle ergänzt.
• [ ] Nichtfunktionale Anforderungen auf konkrete Prüfungen abgebildet.
• [ ] Offene Fragen vor der technischen Planung geklärt.
• [ ] Betroffene Module und Abhängigkeiten im Plan dokumentiert.
• [ ] Aufgaben nach Nutzerwert und Abhängigkeiten getrennt.
• [ ] Jede Aufgabe mit Dateipfaden und Austrittsbedingung versehen.
• [ ] Parallel ausführbare Aufgaben ausdrücklich gekennzeichnet.
• [ ] Agent vor der Änderung einen begrenzten Plan ausgeben lassen.
• [ ] Diff, Testbefehle und Fehlermeldungen nach jeder Aufgabe archiviert.
• [ ] Jede zentrale Specification mit mindestens einem Nachweis verbunden.
• [ ] Nicht erfüllte Anforderungen an die richtige Ebene zurückgegeben.
• [ ] Änderungen an der Specification vor Änderungen am Code versioniert.
• [ ] Testumgebung zurücksetzbar und frei von produktiven Zugangsdaten.

Für den dokumentierten Referenzablauf stehen in der offiziellen Beschreibung die Phasen specify, plan, tasks und implement; zusätzliche Prüfungen wie clarify, analyze und converge können je nach Unsicherheit und Projektgröße dazukommen. Die genauen Befehle und Integrationen sollten vor der Einführung anhand der aktuellen offiziellen Referenz geprüft werden. Aktuelle Workflow-Referenz und Integrationsübersicht

Der praktische Vorteil gegenüber einem gewöhnlichen Prompt-Ablauf liegt damit nicht in längeren Eingaben, sondern in der kontrollierten Kette: Eine Anforderung erzeugt ein prüfbares Verhalten, daraus entsteht ein technischer Plan, der Plan wird in begrenzte Aufgaben zerlegt, und jede Änderung liefert einen Nachweis. Wenn eine Prüfung scheitert, bleibt erkennbar, ob die Specification unvollständig, der Plan falsch oder die Implementierung fehlerhaft ist.

Wer dafür nur gelegentliche Tests benötigt, kann lokal arbeiten. Bei wechselnden Projekten, getrennten Teamzugängen oder Apple-spezifischen Prüfungen entstehen mit einer eigenen Hardware dagegen laufende Wartungs-, Sicherheits- und Zurücksetzungskosten. Eine gemietete Mac-Umgebung von Zutcloud für isolierte Entwicklungs- und Testläufe kann in solchen Fällen die passendere Zwischenlösung sein, sofern keine dauerhafte Hochlast und kein direkter Zugriff auf spezielle physische Geräte erforderlich sind. Entscheidend bleibt, dass die Umgebung zum versionierten Prozess passt: reproduzierbarer Ausgangszustand, geschützte Zugangsdaten und ein sauberer Rückweg nach einer fehlerhaften Agent-Änderung.