Spec-Driven Development & Anforderungsmanagement: der Bauplan vor dem Code

Vibe Coding vs. Spec-Driven Development

Vibe Coding – Software per natürlicher Sprache und iterativem Prompt-Ausprobieren – hat seinen Platz: Prototypen, Demos, Wegwerf-Werkzeuge. In skalierenden Produktionssystemen bricht der Ansatz an zwei Stellen zusammen. Intent Drift: Nach dutzenden Prompts entspricht das Ergebnis nicht mehr der ursprünglichen Absicht, und niemand kann rekonstruieren, wo sie verloren ging. Kontextzerfall: Der Chat-Verlauf, der als einzige «Dokumentation» dient, ist in der nächsten Session wertlos.

Spec-Driven Development stellt dem einen Vertrag entgegen: eine versionierte Spezifikation, die vor der Beauftragung eines Agenten vereinbart wird und über den gesamten Lebenszyklus die geschäftliche Absicht mit Architektur, Implementierung und Tests verbindet. Wie diese Arbeitsteilung in der Praxis aussieht – Discovery menschlich, Execution gegen die Spec – belegt der Deep Dive «Discovery bleibt menschlich, Execution wird zur Spec» mit Evidenz von METR, GitClear und DORA.

Die Gegenüberstellung unten fasst die Unterschiede zusammen – und macht deutlich, warum die Wahl keine Stilfrage ist, sondern eine Frage des Systems, das du baust.

Die drei Reifegrade von Spec-Driven Development

SDD ist kein Alles-oder-nichts. In der ersten Reifestufe entsteht vor jeder Aufgabe eine durchdachte Spezifikation, die für genau diese Aufgabe genutzt wird. In der zweiten Stufe bleibt die Spec nach Abschluss bestehen – als Ankerpunkt für Wartung, Onboarding und die nächste Iteration. In der dritten Stufe ist die Spezifikation die einzige Quelldatei, die Menschen noch bearbeiten: Der Mensch ändert die Spec, die Maschine verwaltet den Quellcode.

Für die meisten Teams im DACH-Mittelstand ist Stufe zwei das realistische Ziel: langlebige, überprüfbare Specs, die neben dem Code versioniert werden. Stufe drei setzt eine Disziplin und Tooling-Reife voraus, die 2026 erst wenige Organisationen erreichen – sie taugt als Richtung, nicht als Startpunkt.

Von der Wunschliste zur qualifizierten Roadmap

Traditionell werden Features nach Bauchgefühl oder politischem Druck priorisiert, ohne Aufwand und Risiko systematisch zu bewerten. Das Ergebnis ist eine Wunschliste, keine Strategie. Die Impact & Feasibility Matrix ersetzt das durch eine einfache Disziplin: Jedes Feature wird nach messbarem Geschäftswert, erwartetem Implementierungsaufwand und technischem wie regulatorischem Risiko eingeordnet – bevor Ressourcen freigegeben werden.

Bei KI-Initiativen kommt eine Besonderheit dazu: Aufwand und Ergebnis korrelieren weniger planbar als bei deterministischen Features. Bewertungsmodelle wie RICE helfen, müssen aber an diese Unsicherheit angepasst werden – etwa durch Confidence-Abschläge für experimentelle Initiativen. Wie deterministische Zusagen und probabilistische Wetten in einer Planung zusammenfinden, zeigt «Die KI-Roadmap: Features und GenAI-Initiativen in einer Planung».

Das PRD als lebendes Artefakt im Repository

Ein PRD, das in einem Folienstapel altert, ist für KI-Agenten unsichtbar. Deshalb wandern Product Requirements Documents ins Repository: versioniert neben dem Code, bei jeder Session für KI-Editoren wie Cursor oder Claude Code zugänglich. Persistente Kontextdateien wie CLAUDE.md ersetzen das manuelle Briefing – sie definieren Produktterminologie, Nutzerreisen und architektonische Leitplanken einmal, statt sie in jedem Prompt zu wiederholen.

Das stärkste PRD ist code-verankert: Es referenziert tatsächliche Komponenten der Codebasis statt abstrakter Beschreibungen. Voraussetzung dafür ist eine gemeinsame Sprache über Epics, Stories, Cycles und Akzeptanzkriterien – das «Product-Management-Glossar: Jira- & Linear-Begriffe erklärt» hält sie fest, für Menschen und für die Answer Engines, die deine Spezifikationen eines Tages zitieren.

Die BMAD-Methode: Struktur von der Idee bis zur Produktion

Die BMAD-Methode strukturiert den Weg von der Idee zur Produktion in klar getrennte Schritte – von der Analyse über Anforderungen und Architektur bis zur Delivery. Jeder Schritt produziert ein versioniertes Artefakt und übergibt an den nächsten: Aus dem Brainstorming wird ein PRD, aus dem PRD eine Architektur, aus der Architektur werden ausführbare Stories. Mit Git-Versionierung entsteht ein Audit-Trail, der zeigt, wer was wann warum entschieden hat.

Für regulierte Umgebungen ist genau dieser Trail der Punkt: Code-Provenienz wird nachweisbar, statt in Chat-Verläufen zu verschwinden. BMAD ersetzt dabei keine Coding-Tools – es orchestriert sie. Die Spec bleibt der Vertrag, an dem jede Übergabe gemessen wird.

Spec-Review statt Code-Review

Wenn Agenten den Code schreiben, verschiebt sich die Überprüfung nach vorne. Statt im generierten Code nach Fehlern zu suchen, prüft das Team die geschäftliche Absicht in der Spezifikation: Sind die Akzeptanzkriterien vollständig? Sind die Randfälle benannt? Widerspricht eine Anforderung einer bestehenden Geschäftsregel? Ein Fehler, der in der Spec gefunden wird, kostet Minuten – derselbe Fehler im ausgelieferten Code kostet einen Rollback.

Weiterentwicklung folgt derselben Logik: Änderungen am Produkt erfolgen durch Aktualisierung der Spezifikation, nicht durch neue Ad-hoc-Prompts. Das macht das System reproduzierbar und iterierbar – und verhindert, dass architektonische Entscheidungen in E-Mail-Verläufen verloren gehen oder unausgesprochene Annahmen der Agenten zu fehlerhaftem Code führen.

Wo Define endet und Build beginnt

Die Define-Phase liefert den Bauplan: langlebige, überprüfbare Objekte wie Spezifikationen, Architekturpläne und die qualifizierte Roadmap. Was sie nicht liefert, ist Software. Die Build-Phase nimmt den Bauplan auf und transformiert ihn über Ticket-Strukturen und Agentic Engineering in geprüften, ausgelieferten Code.

Diese Grenze bewusst zu ziehen ist der wichtigste Handgriff des Kapitels: Die Spec wird vereinbart, bevor der Agent baut – das Gate. Es kostet kein Tempo, es verhindert Nacharbeit. Die METR-, GitClear- und DORA-Daten aus dem Arbeitsteilungs-Deep-Dive zeigen, dass unstrukturierter KI-Einsatz Teams messbar verlangsamt und die Codequalität senkt.

Häufige Fragen