Spec-Driven Development: Best Practices, Reifegrade und Grenzen (Stand 2026)

Kurzantwort: Spec-Driven Development (SDD) ist die Praxis, vor dem Aufruf eines KI-Coding-Agenten eine strukturierte, versionierte Spezifikation zu schreiben, die Ziele, Constraints und Akzeptanzkriterien explizit macht. SDD existiert in drei Reifegraden: spec-first, spec-anchored und spec-as-source. Für die meisten Teams ist spec-first der belegbar sinnvollste Einstieg.

Dieser Artikel beantwortet sechs Fragen:

1. Was ist Spec-Driven Development genau?
2. Welche drei Reifegrade gibt es und welcher passt wann?
3. Was gehört in eine gute Spec?
4. Welche Antipatterns sind dokumentiert?
5. Wie hängt SDD mit Harness Engineering zusammen?
6. Welche Werkzeuge gibt es und wie unterscheiden sie sich?

Was ist Spec-Driven Development?

Spec-Driven Development ist eine Arbeitsweise, bei der die Spezifikation vor der Implementierung entsteht und als eigenständiges, versioniertes Artefakt behandelt wird. Der Agent implementiert gegen die Spec, nicht gegen einen Prompt aus dem Chatverlauf.

Der Ansatz entstand 2025 als Antwort auf ein konkretes Versagensmuster des sogenannten Vibe Codings: Der erzeugte Code wirkt plausibel, driftet aber von der eigentlichen Absicht ab und zerfällt, sobald das Projekt eine gewisse Größe erreicht.

Abgrenzung zu Test-Driven Development: TDD behandelt einen fehlschlagenden Test als primäres Artefakt. SDD setzt eine Ebene darüber an und liefert die strukturellen und architektonischen Invarianten, die Testszenarien überhaupt erst erfüllen sollen. Beide Ansätze schließen sich nicht aus.

Microsoft benennt den praktischen Nutzen so: weniger Mehrdeutigkeit und weniger Nacharbeit, weil Anforderungen früher geklärt werden, sowie bessere Abstimmung über eine gemeinsame Quelle der Wahrheit (Microsoft for Developers, 2026).

Welche drei Reifegrade gibt es?

Die wichtigste Unterscheidung in der aktuellen Fachdiskussion stammt von Birgitta Böckeler, Distinguished Engineer bei Thoughtworks. Sie trennt drei Ebenen, die in Diskussionen regelmäßig vermischt werden:

Böckeler zieht bei spec-as-source die Parallele zum historisch gescheiterten Model-Driven Development und warnt, dass die Nicht-Determiniertheit von Large Language Models dessen Rigiditätsproblem eher verschärft als löst.

Praktische Konsequenz: Wer heute mit SDD beginnt, sollte spec-first wählen und erst dann auf spec-anchored erweitern, wenn mehrere Personen dieselbe Schnittstelle pflegen.

Was gehört in eine gute Spec?

Vier Eigenschaften unterscheiden eine nützliche Spec von einem Wunschzettel.

1. Selbsttragend

Die Spec benennt die beteiligten Dateien und Interfaces, sagt explizit, was out of scope ist, und endet mit einem End-to-End-Verifikationsschritt, der beweist, dass das Feature funktioniert. Anthropic formuliert das in der offiziellen Dokumentation zu Claude Code als Kernkriterium: Der Aufwand für eine präzise Spec zahlt sich stärker aus als der Aufwand für das Beobachten der Implementierung.

2. Durch Interview entstanden

Statt die Spec allein zu formulieren, startet man den Agenten mit einem Minimal-Prompt und lässt ihn Fragen zu Implementierung, Edge Cases und Trade-offs stellen. Er fragt Dinge, an die man selbst nicht gedacht hat. Erst danach wird die Spec geschrieben und in einer frischen Session ausgeführt, damit der saubere Kontext vollständig der Umsetzung gehört.

3. Wie Code behandelt

Die Spec gehört ins Repository und wird versioniert. Der Agent kann über Git-Historie und Diffs nachvollziehen, wie sie entstanden ist. Sinnvolle automatisierte Checks decken drei Abweichungen auf: implementiertes Verhalten ohne Entsprechung in der Spec, spezifiziertes Verhalten ohne Implementierung, sowie abweichende Schemata.

4. In kleine Schritte zerlegt

Nicht ein ganzes Feature in einem Zug generieren lassen, sondern durch kleine, abgegrenzte Patches führen. Der Mensch behält die Richtung, der Agent das Tempo.

Andreas Kling beschreibt genau diese Arbeitsweise für die Rust-Portierung des Ladybird-Browsers: menschlich gesteuert, keine autonome Code-Generierung, hunderte kleiner Prompts, mit denen die Agenten dorthin gelenkt wurden, wo sie hinsollten.

Bonus: Erzeugung und Prüfung trennen

Das am stärksten unterschätzte Muster in SDD ist, einen separaten Agenten die Arbeit prüfen zu lassen, statt dem implementierenden Agenten die Selbstkontrolle zu überlassen. Der Reviewer sieht nur das Diff und die Kriterien, nicht die Argumentationskette, die die Änderung erzeugt hat.

Wichtige Gegensteuerung: Ein auf Lückensuche geprompteter Reviewer meldet fast immer etwas. Der Auftrag muss deshalb eingegrenzt werden auf Lücken, die Korrektheit oder gestellte Anforderungen betreffen. Sonst produziert SDD Over-Engineering statt Qualität.

Welche Antipatterns sind dokumentiert?

Vier Fehlermuster sind belegt und lassen sich vermeiden.

Schwere Vorab-Spezifikation. Das Thoughtworks Technology Radar (Volume 33, 2025) führt SDD im Assess-Ring und benennt als Antipattern die Neigung zu umfangreicher Vorab-Spezifikation und Big-Bang-Releases. SDD ist kein Wasserfall mit KI-Anstrich.

Review-Überlastung. Böckeler beobachtet bei aktuellen Werkzeugen exzessiven Review-Overhead und ein falsches Gefühl von Kontrolle. In ihrem Test erzeugte GitHub Spec Kit so viele repetitive Markdown-Dateien, dass manuelles Code-Review teilweise vorzuziehen war.

Fehlende Skalierung über Problemgrößen. Die gängigen Tools bieten je einen fest vorgegebenen Workflow. Für kleine Bugfixes ist dieser Overhead nicht gerechtfertigt. Wer den Diff in einem Satz beschreiben kann, braucht keine Spec.

Falscher Einsatzbereich. SDD lohnt sich dort, wo Vertragsstabilität zählt: API-lastige Systeme, Microservices, regulierte Branchen. Bei Prototypen und Wegwerfcode übersteigt der Aufwand den Nutzen.

Wie hängt SDD mit Harness Engineering zusammen?

Diese Einordnung ist der eigentliche Erkenntnisgewinn der Diskussion seit Anfang 2026: Eine Spec ist der Feedforward-Teil eines größeren Systems, nicht das System selbst.

Böckeler unterscheidet in ihrem Artikel zum Harness Engineering zwei Kontrollarten:

• Guides (Feedforward) antizipieren Verhalten und steuern vor dem Handeln. Die Spec ist ein Guide.
• Sensoren (Feedback) beobachten danach und ermöglichen Selbstkorrektur. Linter, Typechecker und Testsuiten sind Sensoren.

Ihre Warnung dazu: Die verbreitete Praxis kombiniert eine Spec als Feedforward mit einer KI-generierten Testsuite als Feedback. Das setzt sehr viel Vertrauen in eben diese Tests, und das reicht bislang nicht aus.

Ergänzend gilt das Lernprinzip, das Mitchell Hashimoto, Mitgründer von HashiCorp, formuliert hat: Wenn ein Agent einen Fehler macht, investiert man die Zeit, eine Lösung zu bauen, sodass genau dieser Fehler nicht wieder auftritt. Auf SDD übertragen heißt das, wiederkehrende Missverständnisse in Spec-Templates zu überführen, statt sie in jedem Ticket erneut zu erklären.

Welche SDD-Werkzeuge gibt es?

Bewertungsgrundlage ist der Vergleich der drei erstgenannten Tools durch Böckeler (2025).

Wie belastbar ist die Evidenz?

Ehrliche Antwort: Es gibt bislang keine randomisierte Studie, die SDD isoliert gegen andere Arbeitsweisen misst. Die verfügbare Evidenz betrifft KI-gestützte Entwicklung allgemein.

Der belastbarste Befund stammt aus dem DORA-Report 2025 von Google Cloud mit rund 5.000 Befragten: KI erzeugt keine organisatorische Exzellenz, sondern verstärkt, was bereits vorhanden ist. Zu den benannten verstärkenden Fähigkeiten zählen kleine Batches und starke Versionskontrolle, also genau die Praktiken, die SDD voraussetzt.

Addy Osmani, Engineering Leader bei Google, fasst den Mechanismus zusammen: LLMs belohnen bestehende Best Practices. Klare Specs, gute Tests und Code Reviews werden mit KI noch wertvoller, nicht weniger.

Entscheidungsheuristik: Wann lohnt sich eine Spec?

• Diff in einem Satz beschreibbar: keine Spec, direkt umsetzen.
• Mehrere Dateien betroffen, Ansatz unklar oder fremder Code: spec-first.
• Stabile Schnittstelle nach außen, mehrere Beteiligte: spec-anchored.
• Wegwerfcode oder Prototyp: bewusst keine Spec.
• In jedem Fall: kein Merge ohne ausführbaren Verifikationsschritt, unabhängig davon, ob eine Spec existiert.

Häufige Fragen

Ist Spec-Driven Development dasselbe wie Wasserfall?

Nein. Wasserfall spezifiziert das gesamte System vor Projektbeginn. SDD spezifiziert eine einzelne Aufgabe oder ein einzelnes Feature unmittelbar vor der Umsetzung. Das Thoughtworks Technology Radar warnt allerdings genau davor, SDD in Richtung Big-Bang-Spezifikation abgleiten zu lassen.

Ersetzt SDD Test-Driven Development?

Nein. TDD arbeitet auf der Ebene einzelner Verhaltensweisen, SDD auf der Ebene struktureller und architektonischer Invarianten. In der Praxis liefert die Spec die Kriterien, gegen die Tests geschrieben werden.

Brauche ich ein Framework wie Spec Kit oder Kiro?

Nein. Eine einzelne SPEC.md im Repository plus ein ausführbares Verify-Skript deckt den Großteil des Nutzens ab. Frameworks lohnen sich, wenn mehrere Personen denselben Ablauf einhalten sollen.

Wie lang sollte eine Spec sein?

So lang, dass sie selbsttragend ist, und so kurz, dass sie tatsächlich gelesen wird. Als Faustregel: Wenn das Review der Spec länger dauert als das Review des resultierenden Diffs, ist sie zu lang.

Funktioniert SDD auch für Bugfixes?

Meist nicht sinnvoll. Der Overhead ist für kleine, klar umrissene Änderungen nicht gerechtfertigt.

Quellen

• Böckeler, B. (2025): Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl. martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html
• Böckeler, B. (2026): Harness engineering for coding agent users. martinfowler.com/articles/harness-engineering.html
• Anthropic (2026): Best practices for Claude Code. code.claude.com/docs/en/best-practices
• Osmani, A. (2026): My LLM coding workflow going into 2026. addyosmani.com/blog/ai-coding-workflow
• Thoughtworks (2025): Technology Radar Volume 33. thoughtworks.com/radar
• Microsoft for Developers (2026): Spec-Driven Development: A Spec-First Approach to AI-Native Engineering. developer.microsoft.com/blog/spec-driven-development-ai-native-engineering
• O'Reilly Radar (2026): How to Write a Good Spec for AI Agents. oreilly.com/radar/how-to-write-a-good-spec-for-ai-agents
• DORA / Google Cloud (2025): State of AI-assisted Software Development. dora.dev/dora-report-2025

Zuletzt aktualisiert: 11. August 2026. Dieser Artikel wird bei relevanten Änderungen der zitierten Quellen überarbeitet.