Spezifikationsgetriebene Entwicklung (SDD)

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 dokumentiert den Open-Source-Workflow; Support und Popularität sind veränderliche Anbieterfakten, daher bewertet die aktuelle Version direkt.

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.

Anbieter- und Praxisberichte beschreiben Nutzen in ausgewählten Setups, belegen aber kein allgemeines Produktivitätsergebnis. Der sekundäre Leitfaden fasst Beispiele zusammen; Grenzen bei Setup, Zuordnung und Messung verlangen eine eigene datierte Baseline für Dokumentationsaufwand, Nacharbeit, Fehler und Review-Last.

• 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. Reality Graph überführt sie in die Vorgabe, an der ein einzelner Run gemessen wird, und schließt die Schleife, die diese Tools offen lassen.