Was ist spec-getriebene Entwicklung? Die Spezifikation als Single Source of Truth

Die Spezifikation als alleinige Wahrheit, nicht als Nebendokument.

Inhaltsverzeichnis

Spec-Driven Development ist eine dieser Ideen, auf die Softwareentwickler in der Vergangenheit zurückgegriffen und die sie dann wieder beiseitegelegt haben, als der Aufwand nicht mehr lohnenswert war.

Was sich 2025 geändert hat, ist die Ankunft von KI-Coding-Agenten, die das Fehlen einer expliziten Absicht teuer gemacht haben. Prompts sind flüchtig. Agent-Sessionen werden zurückgesetzt. Der Code ändert sich, aber die dahinterliegende Begründung verschwindet. Die Spezifikation ist das Artefakt, das verhindert, dass dies geschieht.

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 die meiste Zeit der Geschichte der Softwareentwicklung war die Spezifikation entweder ein temporäres Planungsartefakt oder ein nachträgliches Beiwerk. Anforderungen lebten in Tickets, Designentscheidungen in Chat-Threads, und der Code war die Wahrheit. Dokumentation beschrieb, was nachträglich existierte.

Spec-Driven Development dreht dieses Verhältnis um. Die Spezifikation wird zum primären Artefakt. Der Code wird entweder aus der Spezifikation generiert oder gegen sie verifiziert, nicht umgekehrt.

Das ist keine neue Idee. Formale Methoden, Design-by-Contract und BDD enthalten alle Versionen davon. Was neu ist, ist die praktische Motivation: KI-Coding-Agenten benötigen einen expliziten, dauerhaften Kontext, um korrekte und konsistente Ergebnisse zu produzieren. Prompts sind zu flüchtig. Die Spezifikation ist das einzige Artefakt, das die Absicht über Agent-Sessionen hinweg, über Teammitglieder hinweg und über die Zeit hinweg tragen kann.

Was Spec-Driven Development tatsächlich bedeutet

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

  • Was gebaut werden soll – Nutzerproblem, Ziele und Nicht-Ziele
  • Wie sich ein korrektes Verhalten anfühlt – Abnahmekriterien, Grenzfälle, Fehlerzustände
  • Wie es gebaut werden soll – Architekturentscheidungen, Datenmodell, API-Verträge, Sicherheitsanforderungen
  • Wie es verifiziert werden soll – Teststrategie, Validierungsregeln, Rückverfolgbarkeit zu den Anforderungen

Der letzte Punkt ist leicht zu schreiben, aber in der Praxis leicht zu übersehen. Specs, Tests und Code in KI-Entwicklung synchron halten behandelt, wie sich Rückverfolgbarkeit zu den Anforderungen tatsächlich als Daten anfühlt: 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 weitergemacht wird. Die Spezifikation bleibt ehrlich, weil sie wie Code behandelt wird.

Aktuelle akademische Arbeit formalisiert dieses Rahmenwerk: Forscher beschreiben SDD so, dass Spezifikationen als Single Source of Truth behandelt werden und Code als daraus generiert oder dagegen verifiziert. Die praktische Interpretation ist, dass die Spezifikation das geprüfte, dauerhafte Protokoll der Absicht ist, das 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 irgendeine Implementierung beginnt. Dies ist die strengste Interpretation und diejenige, die am ehesten an Wasserfall erinnert, wenn sie nicht sorgfältig durchgeführt wird.

Spec-anchored bedeutet, eine Spezifikation während des gesamten Funktionslebenszyklus mit der Implementierung synchron zu halten. Die Spezifikation wird aktualisiert, wenn sich Entscheidungen ändern. Dies ist die praktikabelste 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 Werkzeuge, die Code gegen Spezifikationsbeschränkungen prüfen. Dies ist die Richtung, in die Werkzeuge wie GitHub Spec Kit und Kiro gehen, jeweils mit einem unterschiedlichen Abwägen zwischen Portabilität und integrierter IDE-Anleitung. Skill-Pakete wie Superpowers liegen näher am spec-anchored-Ende – sie erzwungen die Prüfdisziplin automatisch, anstatt Code direkt aus der Spezifikation zu generieren.

Warum SDD jetzt wichtig ist

Die ehrliche Antwort ist, dass SDD für einen Solo-Entwickler, der ein Skript für einen Tag baut, nicht überzeugend ist. Der Aufwand ist es nicht wert.

SDD wird wertvoll, wenn drei Bedingungen vorliegen: Die Funktion ist groß genug, um mehrere Sessionen zu umfassen, der Agent muss Entscheidungen treffen, die die Architektur betreffen, und die Arbeit wird von jemand anderem geprüft oder fortgesetzt.

Alle drei Bedingungen werden bei KI-gestützter Entwicklung immer häufiger.

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 Abnahmekriterien erhält, trifft bessere Entscheidungen und lässt sich leichter korrigieren, wenn es abweicht. Dies hängt damit zusammen, wie Retrieval und Repräsentation funktionieren: Einem Agenten eine versionierte Spezifikation zu geben, ist eine Form des strukturierten Retrievals der Projektabsicht.

Code-Generierung ist billig; das Entscheiden, was gebaut werden soll, ist immer noch schwer. Die Engstelle in der KI-gestützten Entwicklung ist nicht mehr das Tippen – es ist das Wissen, was gebaut werden soll und wie der Agent beschränkt werden muss. SDD verlagert den Aufwand dorthin, wo er wichtig ist: Die Absicht klar zu spezifizieren, bevor die Generierung beginnt.

Prompts sind flüchtig. Der Agent erinnert sich nicht daran, was Sie ihm in der letzten Session gesagt haben. Eine versionierte Spezifikation, die im Repository gespeichert ist, erinnert sich daran. Jede neue Session kann dieselbe Spezifikation lesen und gegen dieselbe Absicht implementieren, ohne den Kontext von Grund auf neu aufzubauen.

**Vibe Coding ist für Wegwerf-Arbeit schneller; SDD vs Vibe Coding behandelt, wann man Spezifikationen hinzufügen sollte und wann man frei weiter prompten kann.

Kernartefakte

SDD erzeugt vier Arten von Artefakten. Jedes reduziert eine andere Art von Mehrdeutigkeit, bevor der Agent den Code berührt:

  • Anforderungsspezifikation – Problem, Nutzer, Ziele, Nicht-Ziele, Abnahmekriterien
  • Designspezifikation – Architektur, Datenmodell, API-Verträge, Sicherheitsanforderungen für diese Funktion
  • Aufgabenplan – kleine Implementierungsschnitte mit Abhängigkeiten und Validierungskriterien
  • Rückverfolgbarkeitsprotokoll – Zuordnung von Abnahmekriterien zu Tests, Designentscheidungen zu Dateien, Aufgaben zu Commits

Wie man sie Schritt für Schritt erstellt und prüft – spezifizieren, planen, Aufgaben, implementieren, validieren – wird in Spec-Driven Development Workflow Von Anforderungen zu Code behandelt. Eine einfache Funktion 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 Verwechslung ist, SDD-Artefakte als Dokumentation zu betrachten. Sie sind keine Dokumentation im konventionellen Sinne.

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 sollte – hat ihren Zweck bereits verfehlt.

Ausführbare Spezifikationen steuern Generierung und Validierung. Die besten SDD-Spezifikationen sind maschinenlesbar genug, dass ein Agent gegen sie implementieren und eine Test-Suite sie verifizieren kann. Abnahmekriterien, 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 – sind komplementär zu SDD-Artefakten, dienen aber einem anderen Zweck. Entscheidungsprotokolle erfassen, warum eine Wahl getroffen wurde und was abgelehnt wurde. SDD-Spezifikationen erfassen, was gebaut werden soll und wie es verifiziert wird. Beides gehört 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 erzeugen, bevor Code existiert. Der Unterschied ist der Ausgangspunkt.

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

SDD beginnt mit Absicht. Bevor Tests existieren, bevor die Architektur entschieden ist, beantwortet die Spezifikation: Wer hat dieses Problem, wie sieht sich ein korrektes Verhalten an, was ist ausdrücklich außerhalb des Bereichs. Die Spezifikation informiert dann darüber, welche Tests geschrieben werden sollen, weshalb gutes SDD und gutes TDD komplementär und nicht konkurrierend sind.

Eine praktische Art, darüber nachzudenken: SDD steuert TDD. Die Abnahmekriterien in der Spezifikation werden zu den Test-Szenarien. Die Designspezifikation identifiziert die Integrationsgrenzen, die Contract-Tests benötigen. Der Aufgabenplan identifiziert, welche Unit-Verhaltenen Testabdeckung benötigen, bevor der Agent sie implementiert.

Wie sich SDD von BDD unterscheidet

Behavior-Driven Development verwendet natürliche Sprach-Szenarien – typischerweise im Gherkin-Format – um das erwartete Verhalten aus der Perspektive des Nutzers zu beschreiben. Diese Szenarien überbrücken die Lücke zwischen geschäftlicher Absicht und technischer Implementierung.

SDD ist breiter. Es umfasst Verhaltensbeschreibungen (die BDD-Stil-Sprache oder einfache Prosa verwenden können), deckt aber auch Architekturentscheidungen, Datenmodelle, Sicherheitsanforderungen, Aufgabenplanung und Rückverfolgbarkeit ab. BDD kann ein nützliches Format sein, um Abnahmekriterien innerhalb einer SDD-Anforderungsspezifikation zu schreiben. Die Spezifikation ist der Behälter; BDD-Szenarien sind eine Möglichkeit, zu schreiben, was darin enthalten ist.

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

Wie sich SDD von formalen Methoden unterscheidet

Formale Methoden verwenden mathematische Notation und automatische Verifikation, um Eigenschaften von Software-Systemen zu beweisen. Sie sind extrem rigoros und für die meisten Produktiventwicklungskontexte extrem teuer.

SDD erfordert keine formale Notation. Eine Markdown-Datei mit Abnahmekriterien und Architekturentscheidungen ist eine Spezifikation. Sie beschränkt, ohne mathematisch formal zu sein. Das Maß an Strenge skaliert mit den Einsatzrisiken: Eine Spezifikation für einen Abrechnungsdienst sollte präziser und sorgfältiger geprüft sein als eine Spezifikation für eine Dokumentationsseite.

Das Verhältnis ist ein Spektrum:

  • Informelle Prosa-Spezifikation (minimal machbares SDD)
  • Strukturiertes Markdown mit Abnahmekriterien und Nicht-Zielen
  • Maschinenlesbare Spezifikation mit Schema-Validierung
  • Contract-Tests, die direkt aus der Spezifikation abgeleitet werden
  • Formale Spezifikation mit automatischem Beweis

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

Vorteile von Spec-Driven Development

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

Bessere KI-Ausgaben. Agenten, die explizite Beschränkungen, Nicht-Ziele und Abnahmekriterien erhalten, produzieren Implementierungen, die näher an der beabsichtigten sind und leichter korrigierbar sind, wenn sie daneben liegen. Die Qualität des Kontexts bestimmt direkt die Qualität der Ausgabe.

Leichteres Prüfen. Ein Pull Request, der an eine Spezifikation angehängt ist, ist leichter zu prüfen als ein Pull Request, bei dem der Prüfer die Absicht aus dem Code rekonstruieren muss. Die Spezifikation ist die Prüfliste.

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

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

Dauerhafter Übergang. Wenn eine Funktion den Besitzer wechselt – zwischen Ingenieuren, zwischen Agent-Sessionen, zwischen Sprints – ist die Spezifikation das Übergangsartefakt. Sie erfasst, was entschieden wurde, was außerhalb des Bereichs lag und was noch validiert werden muss.

Kosten von Spec-Driven Development

Vorheriger Aufwand. Das Schreiben einer guten Spezifikation, bevor irgendwelcher Code geschrieben wird, kostet Zeit. Für kleine Funktionen 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 von Korrektheit. Veraltete Spezifikationen sind manchmal schlimmer als keine Spezifikation: Sie irreführen Prüfer und Agenten, die sie lesen.

Veraltete Spezifikationen. Spezifikationen driften, wenn das Team sie als Planungsartefakte und nicht als lebende Dokumente behandelt. Die Spezifikation zu aktualisieren, wenn die Implementierung vom Design abweicht, ist nicht optional – es ist das, was SDD von Dokumentation unterscheidet, die sich anhäuft und verrottet.

Generierte Bürokratie. KI-Agenten können ausführliche 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ürokratiegenerator. Gutes SDD erfordert Urteilsvermögen darüber, was spezifiziert und was implizit gelassen werden soll.

Werkzeug-Lock-in. Einige SDD-Werkzeuge haben Meinungen über Format, Dateistruktur und Workflow. Eine Spezifikation, die in einem proprietären Format geschrieben ist, ist schwerer über Werkzeuge hinweg zu tragen als eine Markdown-Datei mit klaren Überschriften und Abnahmekriterien.

Fazit

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

Die Disziplin ist einfach: Schreiben Sie auf, was Sie bauen wollen, 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 Prüfung, Testen und Übergabe.

Die Spezifikation ist keine Magie. Eine Spezifikation, die nicht validiert wird, wird zur teuersten Art der Dokumentation: eine, die selbstbewusst 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 dauerhaft genug, um jede einzelne Agent-Session zu überdauern.

SDD liegt an der Schnittstelle von Dokumentationspraxis, Testarchitektur und Code-Design – alles abgedeckt in der App-Architektur in Produktion-Gruppe neben Entscheidungsprotokollen, API-Design und Datenzugriffsmustern.

Abonnieren

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