Spec-Driven Development 2026: Wie Spezifikationen dein KI-Coding aus dem Chaos holen

Kennst du das? Du startest begeistert ein neues Feature mit Claude Code oder Cursor, beschreibst in zwei Sätzen, was du willst — und zwei Stunden später hast du einen funktionierenden Haufen Code, der … irgendwie nicht zusammenpasst. Falsche Bibliotheken, eine Hälfte des Features in der alten Konvention, die andere in einer neuen, die die KI sich spontan ausgedacht hat. Du korrigierst, erklärst, iterierst. Und am Ende fragst du dich, warum du einer Maschine zum dritten Mal erklären musst, wie euer Projekt tickt.

Vibe Coding ist für Prototypen großartig. Für alles, was länger leben soll, ist es ein Rezept für Technical Debt. Die Disziplin, die 2026 dieses Problem löst, heißt Spec-Driven Development (SDD) — und sie verändert nicht, welche Tools wir nutzen, sondern wie wir sie füttern.

Das Problem: Vage Prompts, vergesslicher Kontext

Wer mit KI-Agenten arbeitet, stößt schnell auf eine trügerische Eigenschaft: Sie wirken klüger, als sie sind. Ein Prompt wie „Refaktorier dieses Modul" führt laut Anton Arhipov vom JetBrains-Team zu „unvorhersehbaren Ergebnissen". Die Ursache ist nicht mangelnde Intelligenz des Modells, sondern ein strukturelles Problem:

• Prompts sind flüchtig — sie verschwinden aus dem Kontext-Fenster, sobald der Chat lang wird.
• Architekturentscheidungen gehen verloren — die KI hat vergessen, was sie vor zwanzig Turns beschlossen hat.
• Änderungen werden inkonsistent — dieselbe Logik taucht plötzlich in zwei Varianten auf.
• Der Agent rät — und wenn er rät, rät er oft plausibel, aber falsch.

Genau hier setzt Spec-Driven Development an. Die zentrale Idee, bringt es Vishal Mysore in seinem vielgelesenen Überblick auf den Punkt: „Don't prompt AI to write code. Give it a specification and let agents implement it." — Statt die KI direkt nach Code zu fragen, gibst du ihr eine Spezifikation und lässt Agenten sie umsetzen.

Was ist Spec-Driven Development eigentlich?

Spec-Driven Development ist keine einzelne App, sondern eine Arbeitsweise. Anstatt den Weg von der Idee zum Code in einem einzigen, offenen Prompt zu erzwingen, zerlegst du ihn in überprüfbare, persistente Artefakte. Aus dem klassischen

Prompt  →  Code

wird eine Pipeline:

Idee  →  Spezifikation  →  Plan  →  Tasks  →  Code

Jede Stufe erzeugt ein Dokument, das im Repository lebt — Markdown-Dateien, die du lesen, reviewen und versionieren kannst. Das klingt erst einmal nach mehr Bürokratie. Tatsächlich ist es das Gegenteil: Du tauschst chaotische, wiederkehrende Chat-Erklärungen gegen eine einmalige, saubere Struktur, die der Agent dann autonom abarbeitet.

Der Vorteil ist fundamental. Paul Everitt, Developer Advocate bei JetBrains und Instructor des DeepLearning.AI-Kurses zu dem Thema, formuliert es so: „Spec-driven development is the disciplined alternative: write a clear markdown spec defining what to build, and let your coding agent implement it." Die Disziplin zahlt sich in drei Währungen aus:

1. Kontext bleibt erhalten — Spezifikationen überdauern Sessions. Du musst nichts zweimal erklären.
2. Intentionstreue — der Agent baut das, was du willst, statt das, was er errät.
3. Weniger kognitive Schuld — du denkst über das Was nach, nicht ständig über das Wie.

Die drei Reifegrade: Von Spec-First bis Spec-as-Source

Spec-Driven Development ist kein Schalter, den man umlegt, sondern eine Reiseskala. Auf Basis der Arbeit von Birgitta Böckeler (Thoughtworks) lassen sich drei Reifegrade unterscheiden:

| Grad | Was passiert | Aufwand |

|------|-------------|---------|

| 1. Spec-First | Eine durchdachte Spezifikation wird zuerst geschrieben und leitet die KI-gestützte Umsetzung. | gering |

| 2. Spec-Anchored | Die Spezifikation wird nach der Implementierung gepflegt und bleibt die Referenz für jede Weiterentwicklung. | mittel |

| 3. Spec-as-Source | Die Spezifikation ist die Quelle. Menschen editieren nur noch die Spec, Code wird daraus erzeugt — wie bei Terraform oder SQL. | hoch |

Die meisten Teams landen realistisch bei Grad 1 oder 2. Grad 3 ist eine radikale Vision, die vor allem von Plattformen wie Tessl oder Intent-Driven vorangetrieben wird: Spec = Quellcode, Code = Kompilat.

Die Falle: „Spec-Once"

Heeki Park, Principal Solutions Architect bei AWS und bekennender „I no longer write code by hand"-Entwickler, warnt vor einem verbreiteten Anti-Pattern: Spec-Once. Man schreibt eine Spec, um ein Projekt zu starten — und vergisst sie danach. „We need to pump the brakes on vibe coding before we add more tech debt to our backlog." Echtes SDD lebt vom kontinuierlichen Feedback: Die Spezifikation wird bei jeder Änderung aktualisiert und bleibt die Wahrheit über das System.

Der Kern-Workflow: Constitution, Requirements, Plan, Tasks

Die konkrete Umsetzung ist erstaunlich simpel und werkzeugunabhängig. Der bewährte Zyklus folgt einem Plan → Implement → Verify-Rhythmus, bei dem du als Human in the Loop die Regie führst.

Schritt 1: Die Projekt-Verfassung (Constitution)

Bevor das erste Feature entsteht, definierst du gemeinsam mit dem Agenten eine Art Grundgesetz: Mission, Tech-Stack, Architekturprinzipien und Roadmap. Diese CONSTITUTION.md (oder AGENTS.md) wird automatisch in jeden neuen Kontext geladen und schafft die gemeinsame Basis, auf der alle weiteren Spezifikationen aufsetzen.

Schritt 2: Requirements — das Was, nicht das Wie

Du beschreibst das gewünschte Ergebnis, ohne die Lösung vorzuschreiben. Eine gute Requirements-Datei ist kurz, nummeriert und formuliert als User Storys. Der Trick: Sie dient als Nordstern, ohne den Agenten in eine Corner-Case-Wüste zu schicken.

# Requirements: Zwei-Faktor-Authentifizierung

1. Als Nutzer möchte ich mich mit einem zweiten Faktor anmelden,
   damit mein Konto auch bei geleaktem Passwort sicher bleibt.
2. Als Admin möchte ich 2FA für bestimmte Rollen erzwingen können.
3. Als Nutzer möchte ich bei Verlust des Geräts Backup-Codes nutzen.

Schritt 3: Plan — die Strategie, bevor Code entsteht

Jetzt lässt du den Agenten eine Strategie entwickeln — noch ohne eine Zeile Code zu schreiben. Das erzeugt einen Review-Checkpoint: Du siehst den Ansatz, bevor er in Produktion geht. Ein bewährter Prompt, angelehnt an den JetBrains-Workflow:

Lies requirements.md und erstelle einen detaillierten Umsetzungsplan.
Der Plan soll enthalten:
– Eine kurze Übersicht des Ziels.
– Die Hauptschritte / Phasen zur Erreichung.
– Abhängigkeiten, Risiken und zu beachtende Punkte.

Schreibe noch keinen Code. Speichere den Plan als plan.md.

Für strategische Tiefe lohnt sich der „Think More"- oder Deep-Reasoning-Modus deines Agenten — er zwingt das Modell zu saubererer Argumentation.

Schritt 4: Tasks — die abhakbare Checkliste

Aus dem Plan wird eine nummerierte Task-Liste mit Checkboxen. Sie ist dein Kontrollzentrum: Sie existiert unabhängig vom Gedächtnis des Agenten und macht den Fortschritt sichtbar.

Lies plan.md und generiere eine detaillierte, nummerierte Task-Liste.
Jeder Task soll klar, umsetzbar und abhakbar sein.
Behalte eine logische Reihenfolge bei und gruppiere in Phasen.
Speichere das Ergebnis als tasks.md (z. B. „- [ ] Repository für Auth-Daten anlegen").
Implementiere noch nichts — erstelle nur die Liste.

Schritt 5: Phasenweise Implementierung

Jetzt erst kommt Code ins Spiel — und zwar in abgegrenzten Portionen, nicht auf einmal. Der Agent arbeitet Aufgabenpakete ab und hakt sie selbstständig ab:

Setze die Aufgaben für Phase 1 laut tasks.md um.
Markiere erledigte Tasks als [x].

Das klingt banal, ist aber der wichtigste Hebel: KI-Agenten glänzen bei begrenzten Aufgabeneinheiten, nicht bei „mach alles". Nach jeder Phase reviewst du, testest und gibst erst dann die nächste frei.

Die Werkzeug-Landschaft 2026: Welches Framework für wen?

Spec-Driven Development braucht kein bestimmtes Tool — die Methode funktioniert mit Claude Code, Cursor, GitHub Copilot, Cline oder Codex gleichermaßen. Was 2026 hinzugekommen ist, sind Frameworks, die den Workflow standardisieren und den Boilerplate-Overhead nehmen. Mysore kartiert die Landschaft in vier Schichten:

1. Spec-Frameworks (Spec Kit, OpenSpec, BMAD, Intent) — definieren Requirements & Architektur.
2. Planungs- & Task-Systeme (Taskmaster, Kiro) — wandeln Specs in Task-Graphen.
3. Ausführungs-Agenten (Claude Code, Codex, OpenHands) — schreiben und testen den Code.
4. KI-IDEs (Cursor, Windsurf, Junie) — integrieren alles in die Entwicklungsoberfläche.

Die drei wichtigsten Spec-Frameworks im direkten Vergleich:

| Framework | Stärken | Passt zu |

|-----------|---------|----------|

| GitHub Spec Kit | Umfangreich dokumentiert, Enterprise-freundlich, enge Copilot-Integration; funktioniert mit 30+ Agenten. | GitHub-zentrierte Teams, die Struktur wünschen. |

| OpenSpec | Leichtgewichtig, tool-agnostisch, minimaler Overhead, Brownfield-first (für bestehende Codebases), MIT-lizenziert. | Flexibilität suchende Entwickler & Legacy-Projekte. |

| AWS Kiro | Mächtige Planungsfunktionen, enge Cloud-Integration. | Wer ohnehin im AWS-Ökosystem arbeitet. |

Sonderling OpenSpec: Brownfield-First und Delta-Specs

Besonders für bestehende Projekte interessant ist OpenSpec. Die meisten SDD-Frameworks sind auf Greenfield (0 → 1) getrimmt. OpenSpec ist primär für Brownfield (1 → n) gedacht — du kannst den Ist-Zustand schrittweise spezifizieren, ohne die gesamte Codebase neu zu dokumentieren. Roland Golla von Never Code Alone bringt es auf den Punkt: „KI-Coding ohne Spezifikation ist wie Bauen ohne Plan — es funktioniert für kleine Aufgaben, aber skaliert nicht."

Sein zweiter Clou sind Delta-Specs: Änderungen werden nicht als neue, vollständige Spec geschrieben, sondern als Differenz markiert — ADDED, MODIFIED, REMOVED. Das macht Code-Reviews leichter und verhindert versehentliche Regressionen, weil der Agent genau weiß, was sich ändern darf und was unverändert bleiben muss:

# Delta: Authentifizierung

## ADDED
### Requirement: Zwei-Faktor-Authentifizierung
Das System MUSS beim Login einen zweiten Faktor verlangen.

## MODIFIED
### Requirement: Session-Timeout
Sessions laufen nach 30 Minuten ab.
(zuvor: 60 Minuten)

Der OpenSpec-Workflow folgt dabei einem klaren Zyklus: Proposal → Apply → Archive. Ein strukturierter Vorschlag wird umgesetzt, nach Erfolg in die Hauptspezifikation übernommen und archiviert — ein sauberer Audit-Trail entsteht fast von selbst.

Best Practices — und die Anti-Patterns, die du meiden musst

Wie bei jeder Methode trennt die Praxis die Spreu vom Weizen. Wer Spec-Driven Development ernsthaft betreiben will, sollte diese Prinzipien verinnerlichen — und die typischen Fallstricke kennen.

Was funktioniert

• Menschenlesbarkeit ist der Maßstab. Der entscheidende Test lautet: „Sind diese Artefakte überprüfbar?" Wer Spec-Änderungen nur noch überfliegt im Glauben, „die KI wird schon recht haben", hat das Feature zu groß gewählt.
• Minimal starten. Spezifiziere knapp, was jetzt nötig ist — ohne vorzeitige Edge-Cases, die den Kontext sprengen. Klassen wie INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable) und MoSCoW helfen bei Zerlegung und Priorisierung.
• Sinnvoll zerlegen. Teile übergroße Features in eigenständig wertvolle Scheiben, nicht in beliebige technische Stücke.
• Spezifikation als Source of Truth. Wenn Spec und Code auseinanderdriften, verliert die Spec ihren Wert. Halte sie synchron — kontinuierlich, nicht als einmaliges Gate.

Anti-Patterns, die jedes Team kennt

• Specification Theater — detaillierte Specs, die niemand wirklich liest oder validiert.
• Premature Comprehensiveness — alles vorab erschöpfend spezifieren wollen statt zu iterieren.
• Spec-Once — die Spec nach dem Start vergessen (siehe oben).
• Spec-Implementation Drift — Code und Spec wachsen auseinander.
• KI-generierter Spec-Bloat — wortreiche, automatisch erzeugte Specs unkritisch akzeptieren statt sie zu kuratieren.
• „Lost in the Middle" — übergroße Specs leiden unter Recency-/Primacy-Bias: Mittendrin vergisst sowohl die KI als auch der Mensch wichtige Klärungen.

Die wichtigste Erkenntnis der Praktiker: Kein Tool repariert eine schlechte Zerlegung. Strukturiertes Nachdenken über die Feature-Größe kommt vor jeder Tool-Optimierung. Subagenten und Parallelisierung vervielfachen deine Fähigkeit — sie heilen aber keine kaputte Architektur.

Fazit: Disziplin statt Vibes

Spec-Driven Development ist kein weiteres Tool, das du deinem Stack hinzufügst. Es ist die Antwort auf eine Frage, die sich 2026 jedes Team stellen muss: Wie halten wir KI-Agenten auf Kurs, ohne sie auszubremsen?

Die Methode ist dabei sympathisch bodenständig: Markdown-Dateien statt komplizierter Konfiguration, ein klarer Rhythmus aus Planen, Umsetzen und Verifizieren, und du als Mensch bewusst in der Kontrollschleife. Wer heute noch jede Architekturentscheidung dem Kurzzeitgedächtnis eines Chats anvertraut, wird morgen die Rechnung in Form von Inkonsistenzen und unerklärlichem Code bezahlen.

Machs dir einfach: Fang mit einer requirements.md für dein nächstes Feature an. Lass den Agenten einen Plan schreiben, bevor auch nur eine Zeile Code entsteht. Arbeite phasenweise ab. Du wirst überrascht sein, wie viel berechenbarer — und ehrlicher — KI-gestütztes Programmieren wird, wenn die Spezifikation das Kommando führt.

Der nächste Schritt liegt bei dir: Öffne dein Repository, lege einen specs/-Ordner an und schreib die erste Spezifikation für ein Feature, das du schon ewig vor dir herschiebst. Dein zukünftiges Ich — und dein Agent — werden es dir danken.