Was ist spec-gesteuerte Entwicklung? Die Spec als Single Source of Truth

Die Spezifikation als einzige Wahrheit, nicht als Nebendokument.

Inhaltsverzeichnis

Spec-getriebene Entwicklung ist eine dieser Ideen, auf die Softwareingenieure früher bereits zurückgegriffen haben, um sie dann wieder abzulegen, sobald der Aufwand den Nutzen überstieg.

Was sich 2025 geändert hat, ist, dass KI-Coding-Agenten auf den Markt kamen und das Fehlen einer expliziten Absicht teuer machten. Prompts sind vergänglich. Agent-Sitzungen werden zurückgesetzt. Der Code ändert sich, aber die dahinterliegende Begründung verschwindet. Die Spezifikation (Spec) 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 größten 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-Verläufen und der Code war die einzige Wahrheit. Die Dokumentation beschrieb nachträglich, was existierte.

Spec-Driven Development kehrt diese Beziehung um. Die Spezifikation wird zum primären Artefakt. Code wird basierend auf der Spezifikation generiert oder gegen diese 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 einen expliziten, langlebigen Kontext, um korrekte und konsistente Ergebnisse zu liefern. Prompts sind zu vergänglich. Die Spezifikation ist das einzige Artefakt, das die Absicht über Agent-Sitzungen hinweg, über Teammitglieder hinweg und über die Zeit hinweg tragen 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 leitet oder generiert. Die Spezifikation wird geschrieben und überprüft, bevor der Agent Code schreibt. Sie erfasst:

  • 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 – Architekturdecisions, Datenmodell, API-Verträge, Sicherheitsbeschränkungen
  • Wie es verifiziert werden soll – Teststrategie, Validierungsregeln, Rückverfolgbarkeit zu den Anforderungen

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 darstellt, wird die Spezifikation korrigiert, bevor fortgefahren wird. Die Spezifikation bleibt „ehrlich“, weil sie wie Code behandelt wird.

Neuere akademische Arbeiten formalisieren diesen Rahmen: Forscher beschreiben SDD als die Behandlung von Spezifikationen als Single Source of Truth und Code als generiert oder gegen diese verifiziert. Die praktische Interpretation ist, dass die Spezifikation der geprüfte, langlebige Aufzeichnung der Absicht ist, den jeder Mensch oder jedes KI-Tool lesen und vertrauen kann.

Drei Begriffe beschreiben verschiedene Punkte auf dem Spektrum der Spezifikationsnutzung:

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

Spec-anchored bedeutet, eine Spezifikation während des gesamten Lebenszyklus der Funktionalität 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.

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 Overhead ist es nicht wert.

SDD wird wertvoll, wenn drei Bedingungen vorliegen: Die Funktionalität ist groß genug, um mehrere Sitzungen zu spannen, 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 verbreitet.

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

Code-Generierung ist billig; die Entscheidung darüber, was gebaut werden soll, ist nach wie vor schwierig. Der Engpass bei der KI-gestützten Entwicklung ist nicht mehr das Tippen – es ist zu wissen, was gebaut werden soll und wie der Agent eingeschränkt werden kann. SDD verschiebt den Aufwand dorthin, wo es 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, erinnert sich. Jede neue Sitzung kann dieselbe Spezifikation lesen und gegen dieselbe Absicht implementieren, ohne den Kontext von Grund auf neu aufzubauen.

Vibe Coding funktioniert, solange es funktioniert. Für Prototypen und Wegwerf-Arbeit ist ad-hoc Prompting schneller und angemessen. Sobald eine Funktionalität Sicherheitsbeschränkungen, Architekturdecisions über mehrere Dateien oder eine Übergabe im Team erfordert, wird das Fehlen einer Spezifikation zur Hauptquelle für Abweichungen und Defekte. Siehe den Vergleich in SDD vs. Vibe Coding, um zu sehen, wann jeder Ansatz anwendbar ist.

Kernartefakte

Ein praktischer SDD-Workflow erzeugt vier Hauptartefakte. Jedes von ihnen reduziert eine spezifische Art von Mehrdeutigkeit, bevor diese den Agenten erreicht.

Anforderungsspezifikation. Das Problemstatement, die betroffenen Benutzer, die Ziele, die expliziten Nicht-Ziele und die Akzeptanzkriterien. Nicht-Ziele sind genauso wichtig wie Ziele – sie sagen dem Agenten, was nicht gebaut werden soll, und verhindern Scope Creep. Akzeptanzkriterien sind präzise genug, dass jedes von ihnen auf mindestens einen Test abbildbar ist.

Designspezifikation. Die für diese Funktionalität relevanten Architekturdecisions: betroffene Module, Änderungen am Datenmodell, API-Verträge, Migrationen, Sicherheitsbeschränkungen, Anforderungen an die Observability und bekannte Fehlermodi. Dies ist kein vollständiges Systemdesign-Dokument – es ist die Teilmenge der Architekturdecisions, die benötigt wird, um diese Funktionalität korrekt zu implementieren.

Aufgabenplan. Eine Sequenz kleiner Implementierungsaufgaben, jede mit expliziten Abhängigkeiten, erwarteten Dateiänderungen und Validierungskriterien. Aufgaben sind klein genug, um in einer einzigen Agent-Sitzung implementiert und mit einem fokussierten Diff verifiziert zu werden. Jede Aufgabe hat einen menschlichen Review-Checkpoint.

Rückverfolgbarkeitsaufzeichnung. Eine Abbildung von Akzeptanzkriterien zu Tests, von Designentscheidungen zu betroffenen Dateien und von Aufgaben zu Commits. Dies ist das, was SDD von Dokumentation unterscheidet, die veraltet wird: Rückverfolgbarkeit macht es möglich, zu verifizieren, dass die Spezifikation tatsächlich implementiert wurde, nicht nur geschrieben.

Diese Artefakte müssen nicht schwerfällig sein. Eine einfache Funktionalität könnte ein einzelnes zweiseitiges Markdown-Dokument produzieren, das alle vier Bereiche abdeckt. Das Format ist weniger wichtig als die Gewohnheit, die Absicht aufzuschreiben, bevor die Implementierung beginnt.

Wie sich SDD von Dokumentation unterscheidet

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

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

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

Ausführbare Spezifikationen leiten Generierung und Validierung. Die besten SDD-Spezifikationen sind nah genug an maschinenlesbar, dass ein Agent gegen sie 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 werden kann. Beide gehören ins Repository. Zusammen geben sie KI-Agenten das vollständige Bild: die aktuelle Absicht und die Begründung dahinter.

Wie sich SDD von TDD unterscheidet

Test-Driven Development und Spec-Driven Development werden oft verwechselt, weil beide explizite Artefakte produzieren, bevor Code existiert. Der Unterschied liegt im Ausgangspunkt.

TDD beginnt mit Tests. Sie schreiben einen fehlschlagenden Test, der das Verhalten beschreibt, das Sie wollen, und schreiben dann den minimalen Code, um ihn zum Passen zu bringen. TDD ist eine Feedback-Schleife auf der Einheitenebene. Es produziert gute Tests, beantwortet aber nicht die Frage, ob Sie die richtige Sache 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 Scope. Die Spezifikation informiert dann darüber, welche Tests geschrieben werden sollen, weshalb gutes SDD und gutes TDD komplementär und nicht konkurrierend sind.

Ein praktischer Weg, darüber nachzudenken: SDD treibt TDD an. Die Akzeptanzkriterien in der Spezifikation werden zu den Testszenarien. Die Designspezifikation identifiziert die Integrationsgrenzen, die Contract Tests benötigen. Der Aufgabenplan identifiziert, welche Einheitsverhalten Testabdeckung benötigen, bevor der Agent sie implementiert.

Wie sich SDD von BDD unterscheidet

Behavior-Driven Development verwendet Natürlichsprach-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. Es umfasst Verhaltensbeschreibungen (die BDD-ähnliche Sprache oder einfachen Prosa verwenden können), deckt aber auch Architekturdecisions, 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 zu schreiben, was hineingeht.

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

Wie sich SDD von Formal Methods 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 Produktionsentwicklungskontexte.

SDD erfordert keine formale Notation. Eine Markdown-Datei mit Akzeptanzkriterien und Architekturdecisions ist eine Spezifikation. Sie beschränkt, ohne mathematisch formal zu sein. Das Niveau der Rigorosität skaliert mit den Risiken: Eine Spezifikation für einen Abrechnungsdienst sollte präziser und sorgfältiger geprüft sein als eine Spezifikation für eine Dokumentationsseite.

Die Beziehung ist ein Spektrum:

  • Informelle Prosaspezifikation (Minimum Viable SDD)
  • Strukturiertes Markdown mit Akzeptanzkriterien und Nicht-Zielen
  • Maschinenlesbare Spezifikation mit Schema-Validierung
  • Contract Tests, die direkt aus der Spezifikation abgeleitet werden
  • Formale Spezifikation mit automatisiertem Beweis

Die meisten Teams operieren in der Mitte dieses Spektrums. Das Ziel ist nicht mathematische Rigorosität – es ist, die Absicht explizit genug zu machen, dass ein KI-Agent gegen sie implementieren und ein menschlicher Rezensent das Ergebnis verifizieren kann.

Vorteile von Spec-Driven Development

Weniger Abweichung der Absicht. Die Spezifikation ist der Referenzpunkt. Wenn der Agent abbricht – und das wird er tun – hat der Rezensent etwas, gegen das er die Implementierung vergleichen kann. Ohne eine Spezifikation ist 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 liegen. Kontextqualität bestimmt direkt die Ausgabequalität.

Einfacherer Review. Ein Pull Request, der an eine Spezifikation angehängt ist, ist leichter zu überprüfen als ein Pull Request, der den Rezensenten zwingt, die Absicht aus dem Code zu rekonstruieren. Die Spezifikation ist die Review-Checkliste.

Team-Ausrichtung. Wenn mehrere Personen oder Agenten an derselben Funktionalität 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?

Langlebige Übergabe. Wenn eine Funktionalität die Hände wechselt – zwischen Ingenieuren, zwischen Agent-Sitzungen, zwischen Sprints – ist die Spezifikation das Übergabeartefakt. Sie erfasst, was entschieden wurde, was nicht im Scope war und was noch validiert werden muss.

Kosten von Spec-Driven Development

Vorabinvestition. Das Schreiben einer guten Spezifikation, bevor jeglicher Code geschrieben wird, kostet Zeit. Bei kleinen Funktionalitäten ist dieser Overhead real und manchmal nicht wert.

Falsches Vertrauen. Eine Spezifikation, die existiert, aber nicht gegen die Implementierung validiert wird, gibt ein falsches Gefühl der Korrektheit. Veraltete Spezifikationen sind manchmal schlimmer als keine Spezifikation: Sie irreführen Rezensenten 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 ansammelt 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 – es ist ein Bürokratiegenerator. Gutes SDD erfordert Urteilsvermögen darüber, was spezifiziert werden soll und was implizit bleiben soll.

Tool-Abhängigkeit. Einige SDD-Tools haben starke Meinungen zu 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 Headern und Akzeptanzkriterien.

Fazit

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

Die Disziplin ist einfach: Schreiben Sie auf, was Sie beabsichtigen zu bauen, geprüft und versioniert, bevor der Agent es baut. Halten Sie diese Aufzeichnung ehrlich, indem Sie sie aktualisieren, wenn die Realität abweicht. Verwenden Sie sie als Referenz für Review, Testing und Übergabe.

Die Spezifikation ist kein Zauberstab. Eine Spezifikation, die nicht validiert wird, wird zur teuersten Art der Dokumentation: eine, die mit Sicherheit irreführt. Gutes SDD ist die Praxis, Spezifikationen ehrlich zu halten – klein genug, um sie zu pflegen, präzise genug, um zu beschränken, und langlebig genug, um jede einzelne Agent-Sitzation zu überdauern.

SDD befindet sich an der Schnittstelle von Dokumentationspraxis, Testing-Architektur und Code-Design – alles in der App Architecture in Production Cluster zusammen mit Entscheidungsprotokollen, API-Design und Datenzugriffsmustern abgedeckt.

Abonnieren

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