Was ist Spec Driven Development?

Spec Driven Development (SDD) ist ein Ansatz, bei dem eine strukturierte Spezifikation vor dem Code entsteht und die Entwicklung steuert. Die Spec beschreibt, was ein System tun soll, mit Anforderungen, Randfällen und Akzeptanzkriterien, bevor ein KI Agent eine Zeile schreibt.

Aus der Spec entstehen ein technischer Plan und kleine, prüfbare Aufgaben. Erst dann setzt der Agent um. Ändern sich Anforderungen, ändert man zuerst die Spec. Der Code folgt.

Die Idee ist alt. Tests als lebende Spezifikation, BDD und Contract First kennen das Prinzip seit Jahren. Neu ist der Druck durch KI Coding Agents. Ohne Spec raten sie, was gemeint ist. Mit Spec bauen sie gegen einen klaren Auftrag, und ein Mensch kann den Plan prüfen, bevor Code entsteht.

Wir arbeiten jeden Tag mit KI Agents im Terminal. Dabei nutzen wir OpenSpec zusammen mit OpenCode. Jede Spec bekommt prüfbare Kriterien, die in unseren Pipelines mit PHPUnit, PHPStan und Cypress laufen. Roland Golla bringt dazu über 20 Jahre Erfahrung mit Testing und Refactoring mit.

Im Vibe Coding Consulting richten wir den Spec Workflow im Team ein. Die NCA Agentic AI Coding Guardrails sichern bestehende Projekte ab. Quality Gates für KI Code prüfen, ob der Agent die Spec erfüllt. Im NCA KI Workshop für Developer lernt das Team den Ablauf hands on, und ein Codebase Audit für KI generierten Code zeigt, wo Specs fehlen.

Beim klassischen Vibe Coding lebt der Auftrag im Chat. Ein Prompt, eine Antwort, ein neuer Prompt. Für einen Prototyp reicht das. Im Team und in Production kippt es schnell.

Typische Muster ohne Spec:

• Der Agent rät. Er füllt Lücken mit Annahmen, die niemand geprüft hat.
• Kontext verschwindet. Nach einer langen Session weiß der Agent nicht mehr, was am Anfang galt. Mehr dazu unter Context Window Management.
• Blindes Iterieren. Fehler werden weggepromptet, bis der Code läuft, aber keiner weiß warum. Das beschreiben wir unter Blindes Iterieren und Code Chaos.
• Kein Review vor dem Code. Der Mensch sieht erst das Ergebnis, nie den Plan.

Die Spec holt den Plan nach vorne. Sie bleibt im Repository, sie ist versioniert, und jeder im Team kann sie lesen. Der Agent arbeitet gegen ein Dokument statt gegen einen Chatverlauf.

Die Tools benennen die Schritte unterschiedlich. Der Kern ist fast immer gleich:

1. Spezifizieren. Was soll das Feature tun, für wen, mit welchen Randfällen? Am Ende stehen prüfbare Akzeptanzkriterien.
2. Planen. Der Agent leitet einen technischen Plan ab. Stack, Schnittstellen, betroffene Dateien.
3. Aufgaben schneiden. Der Plan zerfällt in kleine Tasks, die einzeln umsetzbar und testbar sind.
4. Umsetzen. Der Agent arbeitet die Tasks ab. Tests und statische Analyse laufen mit.
5. Abgleichen. Die fertige Änderung fließt zurück in die Spec. So bleibt sie wahr.

Der wichtigste Moment liegt zwischen Schritt zwei und vier. Hier prüft ein Mensch den Plan. Ein Fehler in der Spec kostet Minuten. Derselbe Fehler im fertigen Code kostet Stunden.

Gute Vorarbeit für Schritt eins ist Example Mapping. Regeln, Beispiele und offene Fragen landen auf Karten, bevor sie in die Spec wandern. Dauerhafte Projektregeln gehören dagegen in rules.md und AGENTS.md.

Spec Driven Development ist kein Schalter. Teams bewegen sich auf einer Skala, je nachdem wie ernst sie die Spec nehmen. Die Unterscheidung in Spec First, Spec Anchored und Spec as Source hat sich in der Fachdiskussion durchgesetzt. Davor steht reines Vibe Coding ohne Spec. Die Tabelle ordnet typische Tools den Stufen zu.

OpenSpec ist ein schlanker Open Source Ansatz von Fission AI. Änderungen laufen als Proposal, werden umgesetzt und danach archiviert. Delta Specs zeigen genau, was sich ändert. OpenSpec ist für bestehende Projekte gedacht und passt damit gut zu Brownfield Code. Details stehen in unserem Glossar zu OpenSpec.

GitHub Spec Kit bringt eine CLI, Vorlagen und Slash Commands für viele Agents mit. Eine eigene constitution.md legt Projektprinzipien fest, die immer gelten. Der Ablauf geht von der Spec über den Plan zu Tasks. Spec Kit ist umfangreicher und erzeugt längere Specs. Das Repository auf GitHub ist MIT lizenziert.

Kiro ist eine Entwicklungsumgebung von Amazon. Sie führt durch drei Phasen: Anforderungen, Design und Aufgaben. Kiro ist geeignet für Teams, die den Spec Ablauf direkt in der IDE haben wollen. Tessl geht am weitesten. Dort ist die Spec das gepflegte Artefakt und der Code wird daraus erzeugt.

Dazu kommen Frameworks, die Spec Gedanken mit Agenten Rollen verbinden. Die BMAD Method arbeitet mit spezialisierten Agents von der Analyse bis zur Umsetzung. Sie hat Stärken bei großen Vorhaben, ist aber schwerer als direktes Arbeiten. Das GSD Framework setzt Spec Driven Development mit Sub Agents in Claude Code um.

Eine gute Spec ist kurz. Sie beschreibt Verhalten, nicht Implementierung. Jede Anforderung ist prüfbar. Wer nach dem Lesen keinen Test schreiben kann, hat eine zu vage Spec.

• Ziel: Welches Problem löst das Feature?
• Anforderungen: Klare Sätze mit SHALL oder MUST.
• Szenarien: Given, When, Then für Normalfall und Randfälle.
• Grenzen: Was ausdrücklich nicht dazugehört.

So sieht eine kleine Anforderung im OpenSpec Stil aus. Wir schreiben Specs auf Englisch, weil Schlüsselwörter und Validierung darauf ausgelegt sind:

Aus dem Szenario wird direkt ein Testfall. Genau dieser Weg macht Specs belastbar. Mehr zu prüfbaren Verträgen für Agents steht unter Schema Based AI Coding.

Eine Spec allein garantiert nichts. Der Agent kann sie lesen und trotzdem daneben liegen. Erst automatische Prüfungen machen aus der Spec einen Vertrag.

Deshalb koppeln wir jede Anforderung an einen Check. Unit Tests mit PHPUnit oder pytest, statische Analyse mit PHPStan, End to End Tests mit Cypress. Diese Checks laufen in den Vibe Coding CI/CD Pipelines bei jedem Commit. Agentische Akzeptanztests gehen noch einen Schritt weiter und prüfen das Ergebnis direkt gegen die Anforderungen.

Langfristig werden die Tests selbst zur verlässlichsten Spec. Sie veralten nicht, weil sie sonst rot werden. Diesen Gedanken vertiefen wir bei Tests als lebende Spezifikation.

Spec Driven Development hat Kosten. Manche Tools erzeugen lange Specs, die kaum jemand vollständig prüft. Dann entsteht Papier statt Klarheit. Auch Fachleute wie Thoughtworks sehen die aktuellen Workflows als aufwendig und je nach Aufgabe sehr unterschiedlich.

Faustregeln aus der Praxis:

• Kleiner Bugfix: Keine eigene Spec. Ein klarer Prompt und ein Test reichen.
• Prototyp zum Ausprobieren: Vibe Coding ist hier völlig in Ordnung.
• Neues Feature im Team: Kurze Spec lohnt sich fast immer.
• Größerer Umbau: Spec plus Plan plus Review vor dem ersten Commit.

Wichtiger als das Tool ist die Gewohnheit. Erst denken, dann prompten. Wer das verinnerlicht, ist schon nah an Exact Coding, auch ohne Framework.

Bei uns beginnt jede größere Änderung mit einem OpenSpec Proposal. OpenCode liest die Spec, schlägt Tasks vor, und wir prüfen den Plan, bevor der erste Commit entsteht. Das Review des Plans spart mehr Zeit als jedes schnellere Modell.

Jede Aufgabe bekommt ein Prüfkriterium, das automatisch läuft. Für die Modelle nutzen wir Open Weight Modelle, lokal über Ollama oder aus der Cloud. Was dabei zählt, zeigen unsere Seiten zu Vibe Coding Modellen und Code Qualität mit KI Agenten.

Wir helfen Teams, Spec Driven Development passend einzuordnen. Mal reicht OpenSpec, mal lohnt ein Blick auf Spec Kit oder BMAD, mal genügt eine saubere Agentic Coding Routine mit klaren Regeln. Dazu kommen automatisierte KI Code Reviews und weiteres Praxiswissen in den Vibe Coding Best Practices.

Die wichtigsten Antworten rund um Spec Driven Development, Tools und den Einstieg im Team.