Spec-Driven Development

SDD entstand 2025 als direkte Gegenbewegung zum Prompt-und-Hoffnung-Coding: Agenten erzeugen plausiblen Code, der von der Absicht wegdriftet, APIs erfindet und mit wachsendem Projekt zerfällt. Der vorgeschlagene Fix ist altmodisch und radikal zugleich – vor der Generierung eine schriftliche Spezifikation abstimmen und sie während der Umsetzung verbindlich halten. 2026 liefert jedes große Tool-Ökosystem eine SDD-Variante; GitHubs Spec Kit allein hat die 90.000-Sterne-Marke überschritten und unterstützt 30+ Coding-Agenten.

Die Bewegung bestätigt, was diese Seite von der Verifikationsseite her argumentiert: Das fehlende Artefakt im KI-Coding ist die schriftliche Absicht. SDD baut dieses Artefakt auf Feature-Ebene; prüfbare Vorgaben bauen es auf Run-Ebene. In der Mitte treffen sich die Philosophien.

1. Requirements. Was das Feature leisten muss, als User Stories mit Akzeptanzkriterien – in Kiros Fluss die erste von drei Gate-Phasen, im Spec Kit der /specify-Schritt.
2. Design. Architekturentscheidungen, Datenmodelle, Schnittstellen – abgestimmt, bevor Code existiert, damit der Agent Entscheidungen erbt statt sie still zu treffen.
3. Tasks. Das Design in kleine, geordnete, einzeln reviewbare Arbeitspakete zerlegt – die Einheit, die ein Agent ausführt.
4. Implementierung gegen die Spezifikation. Der Agent codiert Task für Task; Menschen reviewen gegen die abgestimmten Dokumente, statt Absicht aus Diffs zu rekonstruieren.

Wo die Methode passt, ist der berichtete Nutzen erheblich: GitHub beschreibt interne Teams mit rund einer Größenordnung weniger „von vorn generieren“-Zyklen, und AWS dokumentiert Kundenfälle, in denen 40-Stunden-Features mit unter 8 Stunden menschlicher Zeit landeten, wenn sie spec-first entstanden.

• Agenten gehorchen ihren eigenen Spezifikationen nicht zuverlässig. Die Fowler-Team-Analyse hält fest: Trotz aller Templates und Checklisten „hat der Agent am Ende nicht alle Anweisungen befolgt“ – ein geschriebener Plan ist kein erzwungener Plan.
• Dokumenten-Review kann Code-Review übersteigen. Mehrere Praktiker berichten, sie würden lieber den Code reviewen als drei Markdown-Dateien darüber. SDD verlagert Aufwand nach vorn; es beseitigt ihn nicht.
• Spezifikationen altern. Eine ungepflegte Spezifikation wird zu selbstbewusst falscher Dokumentation – schlimmer als keine, weil sie verbindlich aussieht.
• SDD plant vorwärts; es prüft nicht rückwärts. Der Workflow gated, was gebaut wird – aber die Frage „entspricht der gemergte Code wirklich der Spezifikation?“ braucht weiterhin einen unabhängigen Soll-Ist-Abgleich – gerade wegen des ersten Punkts oben.

SDD und Reality Graph greifen dieselbe Lücke von entgegengesetzten Enden an: SDD macht die Absicht vor der Generierung explizit, Reality Graph verifiziert das Ergebnis danach gegen die Absicht – mit Grenzprüfung, Validierung, die das Modell nicht verfasst hat, und einem Prüfbericht pro Run. Teams mit Spec Kit oder Kiro bringen exzellente Solls mit; die Verifikation schließt die Schleife, die diese Tools offen lassen.