Was ist Spec-Driven Development? Die Spec als Single Source of Truth

Die Spezifikation als Single Source of Truth, nicht als Begleitdokument.

Inhaltsverzeichnis

Spec-getriebene Entwicklung ist eine dieser Ideen, nach der Softwareentwickler zuvor gegriffen und die sie dann wieder fallen ließen, als der Aufwand nicht mehr lohnend war.

Was sich 2025 geändert hat, ist das Aufkommen von KI-Coding-Agenten, die das Fehlen expliziter Absichten teuer gemacht haben. Prompts sind vergänglich. Agent-Sitzungen werden zurückgesetzt. Code ändert sich, aber die dahinterliegende Logik verschwindet. Die Spezifikation ist das Artefakt, das dies verhindert.

Was ist Spec-Driven Development – die Spezifikation als Single Source of Truth für KI-Coding

Die Spezifikation wird zur Single Source of Truth

Für den Großteil der Geschichte der Softwareentwicklung war die Spezifikation entweder ein temporäres Planungsartefakt oder ein nachträglicher Gedanke. Anforderungen lebten in Tickets, Designentscheidungen in Chat-Threads und der Code war die einzige Wahrheit. Dokumentation beschrieb, was nachträglich existierte.

Spec-Driven Development (SDD) invertiert diese Beziehung. Die Spezifikation wird zum primären Artefakt. Code wird basierend auf der Spezifikation generiert oder gegen sie verifiziert, nicht umgekehrt.

Dies ist keine neue Idee. Formale Methoden, Design-by-Contract und BDD (Behavior-Driven Development) enthalten alle Versionen davon. Was neu ist, ist die praktische Motivation: KI-Coding-Agenten benötigen expliziten, dauerhaften Kontext, um korrekte und konsistente Ausgaben zu produzieren. Prompts sind zu vergänglich. Die Spezifikation ist das einzige Artefakt, das Absichten über Agent-Sitzungen hinweg, über Teammitglieder hinweg und über die Zeit transportieren kann.

Was Spec-Driven Development tatsächlich bedeutet

Spec-Driven Development, meist abgekürzt als SDD, ist ein Workflow, bei dem eine versionierte Spezifikation die Implementierung steuert oder generiert. Die Spezifikation wird geschrieben und überprüft, bevor der Agent Code schreibt. Sie fasst zusammen:

  • Was gebaut werden soll – Benutzerproblem, Ziele und Nicht-Ziele (Non-Goals)
  • Wie korrektes Verhalten aussieht – Akzeptanzkriterien, Randfälle, Fehlerzustände
  • Wie es gebaut werden soll – Architektur-Entscheidungen, Datenmodell, API-Verträge, Sicherheitsbeschränkungen
  • Wie es verifiziert werden soll – Teststrategie, Validierungsregeln, Rückverfolgbarkeit zu den Anforderungen

Dieser letzte Punkt ist leicht zu schreiben und in der Praxis leicht zu überspringen. Spezifikationen, Tests und Code in der KI-Entwicklung synchron halten beschreibt, wie Rückverfolgbarkeit zu Anforderungen in Daten aussieht: Anforderungs-IDs, Designentscheidungs-IDs und Tests, die mit den Pull-Requests verknüpft sind, die sie implementiert haben.

Die Spezifikation ist kein einmaliges Dokument. Sie wird aktualisiert, wenn die Realität vom Design abweicht. Wenn der Agent während der Implementierung etwas entdeckt, das die Spezifikation falsch dargestellt hat, wird die Spezifikation korrigiert, bevor fortgefahren wird. Die Spezifikation bleibt ehrlich, weil sie wie Code behandelt wird.

Jüngere akademische Arbeiten formalisieren diese Rahmengebung: Forscher beschreiben SDD so, dass Spezifikationen als Single Source of Truth behandelt werden und Code gegen sie generiert oder verifiziert wird. Die praktische Interpretation ist, dass die Spezifikation der überprüfte, dauerhafte Rekord der Absicht ist, den jeder Mensch oder jedes KI-Tool lesen und vertrauen kann.

Drei Begriffe fassen verschiedene Punkte auf dem Spektrum der Spezifikationsnutzung zusammen:

Spec-first bedeutet, die vollständige Spezifikation zu schreiben, bevor jegliche Implementierung beginnt. Dies ist die strengste Interpretation und diejenige, die am nächsten an Wasserfall steht, wenn sie nicht sorgfältig durchgeführt wird.

Spec-anchored bedeutet, eine Spezifikation während des gesamten Feature-Lebenszyklus mit der Implementierung synchron zu halten. Die Spezifikation wird aktualisiert, wenn sich Entscheidungen ändern. Dies ist die praktischste Version für die meisten Teams.

Spec-as-source bedeutet, die Implementierung aus der Spezifikation zu generieren oder zu validieren, entweder durch KI-Agenten oder durch Tools, die Code gegen Spezifikationsbeschränkungen prüfen. In diese Richtung bewegen sich Tools wie GitHub Spec Kit und Kiro, jeweils mit einem anderen Kompromiss zwischen Portabilität und integrierter IDE-Führung.

Warum SDD jetzt wichtig ist

Die ehrliche Antwort ist, dass SDD für einen einzelnen Entwickler, der ein Skript für einen Tag baut, nicht überzeugend ist. Der Aufwand lohnt sich nicht.

SDD wird wertvoll, wenn drei Bedingungen vorhanden sind: Das Feature ist groß genug, um mehrere Sitzungen zu umfassen, der Agent muss Entscheidungen treffen, die die Architektur beeinflussen, und die Arbeit wird von jemand anderem überprüft oder fortgesetzt.

Alle drei Bedingungen sind bei der KI-gestützten Entwicklung zunehmend üblich.

LLMs benötigen Kontext, nicht nur Prompts. Ein Modell, das einen vagen Prompt erhält, trifft vage Entscheidungen. Ein Modell, das eine überprüfte Spezifikation mit expliziten Beschränkungen, Nicht-Zielen und Akzeptanzkriterien erhält, trifft bessere Entscheidungen und ist leichter zu korrigieren, wenn es abweicht. Dies hängt damit zusammen, wie Abruf und Repräsentation funktionieren: Einem Agenten eine versionierte Spezifikation zu geben, ist eine Form des strukturierten Abrufs von Projektabsichten.

Code-Generierung ist billig; das Entscheiden, was gebaut werden soll, ist immer noch schwierig. Der Flaschenhals in der KI-gestützten Entwicklung ist nicht mehr das Tippen – es ist das Wissen, was gebaut werden soll und wie der Agent eingeschränkt werden soll. SDD verschiebt den Aufwand dorthin, wo er wichtig ist: Die klare Spezifikation der Absicht, bevor die Generierung beginnt.

Prompts sind vergänglich. Der Agent erinnert sich nicht daran, was Sie ihm in der letzten Sitzung mitgeteilt haben. Eine versionierte Spezifikation, die im Repository gespeichert ist, schon. Jede neue Sitzung kann dieselbe Spezifikation lesen und gegen dieselbe Absicht implementieren, ohne den Kontext von Grund auf neu aufzubauen.

Vibe Coding ist schneller für Wegwerf-Arbeit; SDD vs. Vibe Coding behandelt, wann Spezifikationen hinzugefügt werden sollen und wann frei promptet werden soll.

Kernartefakte

SDD produziert vier Artefakttypen. Jedes reduziert eine andere Art von Mehrdeutigkeit, bevor der Agent Code berührt:

  • Anforderungsspezifikation – Problem, Benutzer, Ziele, Nicht-Ziele, Akzeptanzkriterien
  • Designspezifikation – Architektur, Datenmodell, API-Verträge, Sicherheitsbeschränkungen für dieses Feature
  • Aufgabenplan – Kleine Implementierungsabschnitte mit Abhängigkeiten und Validierungskriterien
  • Rückverfolgbarkeitsrekord – Zuordnung von Akzeptanzkriterien zu Tests, Designentscheidungen zu Dateien, Aufgaben zu Commits

Wie diese schrittweise erzeugt und überprüft werden – spezifizieren, planen, Aufgaben, implementieren, validieren – wird in Spec-Driven Development Workflow von Anforderungen bis zum Code behandelt. Ein einfaches Feature kann alle vier Bereiche in einer kurzen Markdown-Datei abdecken. Die Gewohnheit ist wichtiger als das Format.

Wie sich SDD von Dokumentation unterscheidet

Die häufigste Verwirrung besteht darin, SDD-Artefakte als Dokumentation zu behandeln. Sie sind keine Dokumentation im konventionellen Sinne.

Dokumentation beschreibt. Sie sagt Ihnen, was das System tut, wie es verwendet wird und was es enthält. Sie wird nachträglich geschrieben und aktualisiert, wenn sich das System ändert.

Spezifikationen begrenzen. Eine Spezifikation sagt dem Agenten, was er bauen darf und was er nicht tun darf. Sie ist autoritativ, bevor die Implementierung beginnt. Sie wird nach Abschluss der Implementierung validiert. Eine Spezifikation, die beschreibt, was tatsächlich gebaut wurde – anstatt zu begrenzen, was gebaut werden soll – hat ihren Zweck bereits verfehlt.

Ausführbare Spezifikationen steuern Generierung und Validierung. Die besten SDD-Spezifikationen sind nah genug an maschinenlesbar, dass ein Agent dagegen implementieren und ein Testsuite sie verifizieren kann. Akzeptanzkriterien, die als „der Endpunkt muss nicht authentifizierte Anfragen mit einer 401-Antwort ablehnen“ geschrieben sind, sind eine ausführbare Spezifikation; „der Endpunkt ist sicher“ ist Dokumentation.

Entscheidungsprotokolle – ADRs, PDRs und DDRs – ergänzen SDD-Artefakte, dienen aber einem anderen Zweck. Entscheidungsprotokolle erfassen, warum eine Entscheidung getroffen wurde und was abgelehnt wurde. SDD-Spezifikationen erfassen, was gebaut werden soll und wie es verifiziert wird. Beide gehören in das Repository. Zusammen geben sie KI-Agenten das vollständige Bild: die aktuelle Absicht und die dahinterliegende Logik.

Wie sich SDD von TDD unterscheidet

Test-Driven Development (TDD) und Spec-Driven Development (SDD) werden oft verwechselt, weil beide explizite Artefakte erzeugen, bevor Code existiert. Der Unterschied liegt im Ausgangspunkt.

TDD beginnt mit Tests. Sie schreiben einen fehlschlagenden Test, der das gewünschte Verhalten beschreibt, und schreiben dann den minimalen Code, um ihn bestehen zu lassen. TDD ist eine Feedback-Schleife auf der Einheits- (Unit-) Ebene. Es produziert gute Tests, beantwortet aber nicht die Frage, ob Sie das Richtige bauen.

SDD beginnt mit der Absicht. Bevor Tests existieren, bevor die Architektur entschieden ist, beantwortet die Spezifikation: Wer hat dieses Problem, wie sieht korrektes Verhalten aus, was ist explizit nicht im Umfang. Die Spezifikation informiert dann darüber, welche Tests geschrieben werden sollen, weshalb gutes SDD und gutes TDD sich ergänzen, anstatt zu konkurrieren.

Eine praktische Art, darüber nachzudenken: SDD treibt TDD an. Die Akzeptanzkriterien in der Spezifikation werden zu Test-Szenarien. Die Designspezifikation identifiziert die Integrationsgrenzen, die Vertragstests benötigen. Der Aufgabenplan identifiziert, welche Einheits-Verhalten Testabdeckung benötigen, bevor der Agent sie implementiert.

Wie sich SDD von BDD unterscheidet

Behavior-Driven Development (BDD) verwendet natürlichsprachige Szenarien – typischerweise im Gherkin-Format –, um erwartetes Verhalten aus der Perspektive des Benutzers zu beschreiben. Diese Szenarien überbrücken die Lücke zwischen geschäftlicher Absicht und technischer Implementierung.

SDD ist breiter angelegt. Es umfasst Verhaltensbeschreibungen (die BDD-ähnliche Sprache oder einfachen Prosa verwenden können), deckt aber auch Architektur-Entscheidungen, Datenmodelle, Sicherheitsbeschränkungen, Aufgabenplanung und Rückverfolgbarkeit ab. BDD kann ein nützliches Format sein, um Akzeptanzkriterien innerhalb einer SDD-Anforderungsspezifikation zu schreiben. Die Spezifikation ist der Container; BDD-Szenarien sind eine Möglichkeit, das, was hineingeht, zu schreiben.

Die Unterscheidung ist in der Praxis wichtig: BDD-Tools konzentrieren sich darauf, Szenarien ausführbar zu machen. SDD-Praxis konzentriert sich darauf, Absichten dauerhaft zu machen – über Tools hinweg, über Sitzungen hinweg und über Teammitglieder hinweg.

Wie sich SDD von formalen Methoden unterscheidet

Formale Methoden verwenden mathematische Notation und automatisierte Verifikation, um Eigenschaften von Softwaresystemen zu beweisen. Sie sind extrem rigoros und extrem teuer für die meisten Produktionsentwicklungs-Kontexte.

SDD erfordert keine formale Notation. Eine Markdown-Datei mit Akzeptanzkriterien und Architektur-Entscheidungen ist eine Spezifikation. Sie begrenzt, ohne mathematisch formal zu sein. Das Maß an Strenge skaliert mit den Risiken: Eine Spezifikation für einen Abrechnungsdienst sollte präziser und sorgfältiger überprüft sein als eine Spezifikation für eine Dokumentationsseite.

Die Beziehung ist ein Spektrum:

  • Informelle Prosaspezifikation (minimal viable SDD)
  • Strukturiertes Markdown mit Akzeptanzkriterien und Nicht-Zielen
  • Maschinenlesbare Spezifikation mit Schema-Validierung
  • Vertragstests, die direkt aus der Spezifikation abgeleitet sind
  • Formale Spezifikation mit automatisiertem Beweis

Die meisten Teams arbeiten in der Mitte dieses Spektrums. Das Ziel ist nicht mathematische Strenge – es ist, die Absicht explizit genug zu machen, damit ein KI-Agent dagegen implementieren und ein menschlicher Prüfer das Ergebnis verifizieren kann.

Vorteile von Spec-Driven Development

Weniger Abweichung der Absicht. Die Spezifikation ist der Referenzpunkt. Wenn der Agent abweicht – und er wird – hat der Prüfer etwas, gegen das er die Implementierung vergleichen kann. Ohne eine Spezifikation ist die Abweichung unsichtbar, bis etwas kaputtgeht.

Bessere KI-Ausgaben. Agenten, die explizite Beschränkungen, Nicht-Ziele und Akzeptanzkriterien erhalten, produzieren Implementierungen, die näher an dem liegen, was beabsichtigt war, und leichter zu korrigieren sind, wenn sie daneben greifen. Die Qualität des Kontexts bestimmt direkt die Qualität der Ausgabe.

Einfachere Überprüfung. Ein Pull-Request, der an eine Spezifikation angehängt ist, ist einfacher zu überprüfen als ein Pull-Request, der den Prüfer zwingt, die Absicht aus dem Code zu rekonstruieren. Die Spezifikation ist die Prüfungscheckliste.

Team-Ausrichtung. Wenn mehrere Personen oder Agenten an denselben Feature arbeiten, ist die Spezifikation der gemeinsame Vertrag. Ohne sie optimiert jeder Beitragende lokal und die Teile passen möglicherweise nicht zusammen.

Bessere Testplanung. Akzeptanzkriterien in der Spezifikation werden direkt auf Testfälle abgebildet. Testabdeckung wird zu einer Frage der Spezifikationsabdeckung: Ist jedes Akzeptanzkriterium durch mindestens einen Test abgedeckt?

Dauerhafter Übergang. Wenn ein Feature die Hände wechselt – zwischen Ingenieuren, zwischen Agent-Sitzungen, zwischen Sprints – ist die Spezifikation das Übergangsartefakt. Es erfasst, was beschlossen wurde, was nicht im Umfang war und was noch zu validieren bleibt.

Kosten von Spec-Driven Development

Aufwand im Voraus. Das Schreiben einer guten Spezifikation, bevor Code geschrieben wird, kostet Zeit. Für kleine Features ist dieser Overhead real und manchmal nicht wert.

Falsches Sicherheitsgefühl. Eine Spezifikation, die existiert, aber nicht gegen die Implementierung validiert wird, gibt ein falsches Gefühl der Richtigkeit. Veraltete Spezifikationen sind manchmal schlimmer als keine Spezifikation: Sie täuschen Prüfer und Agenten, die sie lesen.

Veraltete Spezifikationen. Spezifikationen weichen ab, wenn das Team sie als Planungsartefakte behandelt, anstatt als lebende Dokumente. Das Aktualisieren der Spezifikation, wenn die Implementierung vom Design abweicht, ist keine Option – es ist das, was SDD von Dokumentation unterscheidet, die sich anhäuft und verrottet.

Generierte Bürokratie. KI-Agenten können erschöpfliche Aufgabenlisten und ausführliche Spezifikationen schnell generieren. Eine 200-Aufgaben-Spezifikation, die in dreißig Sekunden generiert wird, ist keine nützliche Spezifikation – sie ist ein Bürokratie-Generator. Gutes SDD erfordert Urteilsvermögen darüber, was spezifiziert und was implizit gelassen werden soll.

Tool-Lock-in. Einige SDD-Tools haben starke Meinungen über Format, Dateistruktur und Workflow. Eine in einem proprietären Format geschriebene Spezifikation ist schwerer über Tools hinweg zu tragen als eine Markdown-Datei mit klaren Überschriften und Akzeptanzkriterien.

Fazit

Spec-Driven Development ist keine neue Methodik. Es ist eine alte Disziplin, die praktisch wird, weil die Kosten impliziter Absicht nun im KI-generierten Code sichtbar sind.

Die Disziplin ist einfach: Schreiben Sie auf, was Sie bauen möchten, überprüft und versioniert, bevor der Agent es baut. Halten Sie diesen Rekord ehrlich, indem Sie ihn aktualisieren, wenn die Realität abweicht. Verwenden Sie ihn als Referenz für Überprüfung, Testen und Übergabe.

Die Spezifikation ist kein Zauberstab. Eine Spezifikation, die nicht validiert wird, wird zur teuersten Art von Dokumentation: Eine, die selbstbewusst irreführt. Gutes SDD ist die Praxis, Spezifikationen ehrlich zu halten – klein genug, um sie zu warten, präzise genug, um sie zu begrenzen, und dauerhaft genug, um jede einzelne Agent-Sitzation zu überdauern.

SDD liegt an der Schnittstelle von Dokumentationspraxis, Testarchitektur und Code-Design – alles in der App Architecture in Production Cluster abgedeckt, neben Entscheidungsprotokollen, API-Design und Datenzugriffsmustern.

Abonnieren

Neue Beiträge zu Systemen, Infrastruktur und KI-Engineering.