Spec-Driven Development mit Claude Code: Workflow gegen Chaos

TL;DR: Spec-Driven Development (SDD) macht die Spezifikation zum primären Artefakt der Softwareentwicklung – der Code wird daraus generiert, die Spec bleibt die Quelle der Wahrheit. Treiber des Trends 2026 sind Tools wie das im September 2025 veröffentlichte GitHub Spec Kit, Amazons Kiro und das noch in der Private Beta befindliche Tessl Framework. Praxis-Erfahrungen zeigen ein gemischtes Bild: Der Schweizer Engineer Simon Martinelli modernisierte mit SDD ein ERP-System mit fast 1.000 Datenbanktabellen, während Thoughtworks-Expertin Birgitta Böckeler die produzierte „Markdown-Hölle" kritisiert. Die ehrliche Antwort auf Vibe Coding 2026 ist damit kein Hype, sondern eine Disziplin mit klaren Stärken und ebenso klaren Bruchstellen.

Was ist Spec-Driven Development?

Spec-Driven Development bedeutet, dass die Spezifikation und nicht der Code zum primären Quelldokument wird. Die KI generiert daraus Tests, Pläne und Implementierung. Du verifizierst an jedem Schritt, bevor weitergegangen wird. GitHubs offizielle Definition aus dem Spec-Kit-Launch-Post vom September 2025: Eine Spec ist „ein Vertrag dafür, wie sich dein Code verhalten soll", und damit die Quelle der Wahrheit, auf die alle KI-Agenten zugreifen. Der Begriff ist nicht neu. Bereits 2004 beschrieben Ostroff, Makalsky und Paige einen Ansatz zur Agile Specification-Driven Development. Was 2026 neu ist: KI-Agenten machen den Ansatz erstmals praktisch nutzbar, weil sie aus einer Spec funktionierenden Code erzeugen können, ohne dass du eigene Code-Generatoren bauen musst. Den philosophischen Anker für die aktuelle Welle lieferte Sean Grove, Alignment-Researcher bei OpenAI, in seinem Vortrag The New Code auf der AI Engineer World's Fair 2025. Seine These: 80 bis 90 Prozent der Arbeit eines Entwicklers sind strukturierte Kommunikation, der Code selbst nur 10 bis 20 Prozent. Wenn KI den Code erzeugt, werde die Spezifikation zum eigentlichen Wertbeitrag. OpenAI praktiziert das mit der eigenen, öffentlich einsehbaren Model Spec, in der jede Regel eine eindeutige ID und Beispiel-Prompts als Akzeptanzkriterien hat.

Drei Reifegrade nach Böckeler

Thoughtworks-Expertin Birgitta Böckeler unterscheidet drei Reifegrade von SDD: - Spec-first: Die Spec wird einmal am Anfang geschrieben und steuert den initialen Build. Danach wird sie oft nicht mehr gepflegt. - Spec-anchored: Die Spec lebt mit dem Feature weiter und wird bei jeder Änderung aktualisiert. - Spec-as-source: Die Spec ist die einzige Quelle. Der generierte Code trägt einen Kommentar wie // GENERATED FROM SPEC - DO NOT EDIT. Aktuell verfolgt nur das Tessl Framework diesen Ansatz konsequent. !Infografik: Vibe Coding vs. Spec-Driven Development mit Vierphasen-Workflow Specify, Plan, Tasks, Implement und den drei Adoptionsstufen spec-first, spec-anchored, spec-as-source Vibe Coding vs. Spec-Driven Development im Überblick: links die Ambiguitätsfalle ohne Spezifikation, rechts der vierphasige SDD-Workflow Specify → Plan → Tasks → Implement und die drei Adoptionsstufen spec-first, spec-anchored, spec-as-source. — Bild: KI-generiert mit NotebookLM Die meisten Tools liefern heute spec-first, behaupten aber spec-anchored zu sein. Das ist eine wichtige Unterscheidung, wenn du Tools evaluierst.

Warum ist Spec-Driven Development 2026 relevant?

SDD ist die strukturelle Antwort auf das Problem, das im Beitrag zu Dark Code beschrieben ist: KI generiert Code schneller, als Menschen ihn verstehen können. Die Folge sind Produktionscode-Bestände, die niemand mehr reviewen kann. Der Amazon-Kiro-Vorfall vom Dezember 2025 – 13 Stunden Downtime des AWS Cost Explorer in einer Mainland-China-Region – war der Weckruf, der die Diskussion in den Mainstream brachte. Hinzu kommt der regulatorische Druck. Ab 2. August 2026 verlangt Artikel 14 des EU AI Act effektive menschliche Aufsicht für Hochrisiko-KI-Systeme, sofern der laufende Digital-Omnibus-Prozess der EU-Kommission das Datum nicht doch noch auf Dezember 2027 verschiebt. Eine dokumentierte Spec liefert den geforderten Nachweis ohnehin früher oder später. „Die KI hat das geschrieben" ist als Antwort dann nicht mehr ausreichend. Wirtschaftlich wirkt der Effekt ebenfalls. Die knowis AG berichtet aus dem Praxiseinsatz ihrer Cloud Solution Workbench rund 30 Prozent Produktivitätsgewinn durch weniger Missverständnisse und automatisierte Code-Generierung. Die Zahl stammt aus Anbieter-Material. Als Größenordnung passt sie aber zu den Erfahrungen, die Praktiker in Konferenzvorträgen berichten.

Wie funktioniert der Workflow mit Claude Code?

Der konkrete Praxis-Workflow lässt sich an einem dokumentierten Fall von Heeki Park, Principal Solutions Architect bei AWS, nachvollziehen. Park baute ein AgentCore-Gateway-Projekt vollständig in Claude Code und protokollierte seine Methode in einem Medium-Artikel.

Plan Mode als integrierter Einstieg

Claude Code bringt den dedizierten Plan Mode seit Mitte 2025 mit. Du aktivierst ihn mit doppeltem Shift+Tab, seit Januar 2026 zusätzlich über den Slash Command /plan. In diesem Modus liest Claude den Code, recherchiert Kontext und schlägt einen Implementierungsplan vor, schreibt aber nichts. Erst nach deiner Freigabe wechselt das Tool in den Edit-Modus. Anthropic empfiehlt dazu offiziell den Vier-Phasen-Workflow Explore → Plan → Implement → Commit. Das ist die leichtgewichtige SDD-Variante direkt im Tool, ohne externes Framework, und ein guter Einstiegspunkt vor dem Sprung zu Spec Kit oder Kiro.

Steering Documents als Anker

Park legt drei zentrale Markdown-Dateien im Repository ab: - CLAUDE.md im Root als laufendes Steering Document. Hier sammelt er Projekt-Lernen, Konventionen und Hinweise, die in jedem Prompt-Kontext geladen werden sollen. - Eine zentrale Spec-Datei (z. B. SPECIFICATIONS.md) im Root. Sie definiert die Anforderungen, bevor irgendein Code entsteht. - SKILL.md am Ende des Projekts, um wiederverwendbare Bausteine für zukünftige Projekte zu sichern. Anschluss an das Thema Claude Skills 2.0.

Phasen statt Big Bang

Park zerlegt jedes Projekt in Sub-Projekte und Phasen. Statt eines „Build me the whole thing"-Prompts definiert er pro Phase einen kleinen, testbaren Baustein. Zwei Praxis-Tipps aus seinem Bericht: - Selectable Inputs: Claude Code wird angewiesen, Klärungsfragen mit auswählbaren Optionen zu stellen. Das verkürzt den Hin-und-Her-Loop deutlich. - Auto-Allow mit Augenmaß: Lese-Operationen werden nach gewisser Vertrauensbildung automatisch freigegeben, das --dangerously-skip-permissions-Flag bleibt aber tabu.

Kontextfenster und Modellwahl

Ein praktisches Limit, das du bei SDD mit Claude Code früh spürst: Das Standard-Kontextfenster beträgt 200.000 Token. Park berichtet, dass Claude Code bei Erreichen automatisch eine Compaction durchführt, die je nach Last 3 bis 12 Minuten dauert. Mit dem Opus 4.6-Modell lief er im Pro-Plan oft schon nach 45 bis 60 Minuten in das Conversation-Budget-Limit. Sein Workaround: Auf Sonnet 4.6 wechseln, das auch mehrstündig durchhält. Das 1-Million-Token-Fenster ist je nach Modell entweder dem Max-Tier vorbehalten oder erfordert ein aktiviertes Extra-Usage-Limit.

Welche Tools für Spec-Driven Development gibt es 2026?

Die Tool-Landschaft ist jung und sehr heterogen. Eine Übersicht der relevanten Vertreter: | Tool | Anbieter | Workflow | Reifegrad | Stand | | --- | --- | --- | --- | --- | | Spec Kit | GitHub | Constitution → Specify → Plan → Tasks → Implement | Spec-first (mit Anspruch auf spec-anchored) | Open Source, Sep 2025 | | Claude Code Plan Mode | Anthropic | Explore → Plan → Implement → Commit | Plan-first, leichtgewichtig | Seit Anfang 2026 | | Kiro | Amazon | Requirements → Design → Tasks | Spec-first | VS-Code-basiert | | Aider Architect Mode | Open Source | Architect-Modell plant, Editor-Modell schreibt | Reasoning/Editing-Split, kein klassisches SDD | Seit September 2024 | | Cursor Project Rules / AGENTS.md | Cursor | Persistente Rule-Files (Project, Team, User) | Spec-anchored via Regeldateien | .cursorrules deprecated, AGENTS.md aktuell | | Tessl Framework | Tessl | CLI + MCP-Server, 1:1-Mapping Spec → Code | Spec-as-source | Private Beta | | BMAD Method | Community | Methodenframework mit Rollen und Artefakten | Spec-first | Sehr populär, restriktiv | | Cloud Solution Workbench | knowis AG | Kollaborative Architekturmodellierung mit KI | Idea-to-Code | Kommerziell |

GitHub Spec Kit im Detail

Spec Kit wird als CLI-Tool specify installiert. Anschließend interagierst du in Claude Code, GitHub Copilot oder Gemini CLI über drei Slash Commands: Zusätzlich legt Spec Kit eine Constitution an: eine übergeordnete Regel-Datei mit immutable Prinzipien für das Projekt. Sie wird in jedem Schritt zwingend mit eingelesen.

Aider Architect Mode als alternative Logik

Das Open-Source-Tool Aider verfolgt seit September 2024 einen verwandten, aber pragmatischeren Ansatz. Im Architect Mode plant ein „Architect-Modell" die Lösung in natürlicher Sprache, während ein zweites „Editor-Modell" sie in konkrete Datei-Edits übersetzt. Die Aider-Maintainer haben mit dieser Architektur SOTA-Werte von 85 Prozent auf dem eigenen Code-Editing-Benchmark erreicht. Das ist kein klassisches SDD mit Markdown-Spec, sondern eine schlanke Variante des Reasoning-vor-Editing-Prinzips, das auch hinter Spec Kit steht.

Cursor Project Rules und AGENTS.md

Cursor setzt nicht auf einen vollständigen SDD-Workflow, sondern auf persistente Regeldateien. Project Rules liegen unter .cursor/rules im Repo, User Rules sind global, Team Rules kommen aus dem Dashboard. Die universellste Variante ist die AGENTS.md im Projekt-Root: ein einfaches Markdown-File, das auch von anderen Tools gelesen wird. Die alte .cursorrules-Datei wird laut Cursor-Doku deprecated. Wer Spec-anchored arbeiten will, ohne ein eigenes Framework zu adoptieren, findet hier den niedrigschwelligen Einstieg.

Amazon Kiro im Detail

Kiro ist die schlankere Variante. Drei Dateien, drei Phasen, eine eigene VS-Code-Distribution. Requirements werden als User Stories im „As a … I want … so that …"-Format erfasst, Akzeptanzkriterien in der EARS-Notation („WHEN [Bedingung] THE SYSTEM SHALL [Verhalten]"). Der Vorteil: Du verstehst das Modell sofort. Der Nachteil: Auch kleinste Bugs werden formal über alle drei Stufen gezogen.

Wann lohnt sich Spec-Driven Development, wann nicht?

SDD lohnt sich, wenn drei Bedingungen erfüllt sind: Der Code geht in Produktion, er muss von mehreren Personen verstanden werden, und die Anforderungen sind hinreichend klar. Klassische Anwendungsfelder sind regulierte Branchen, Legacy-Modernisierung und Team-Setups mit verteilter Verantwortung. Der Schweizer Engineer Simon Martinelli zeigt im konkreten Fall: Er modernisierte mit SDD ein ERP-System mit fast 1.000 Datenbanktabellen von Eclipse RCP auf Spring Boot, Vaadin und jOOQ. Die Specs wurden mit KI aus dem Altcode reverse-engineert, dann wurde die neue Anwendung daraus erzeugt. Sein Effizienzhebel: Self-Contained Systems als vertikale Slices, damit weder die KI noch der Mensch den gesamten Kontext gleichzeitig halten muss. Nicht geeignet ist SDD für: - Prototypen und Wegwerf-Code: Der Spec-Overhead amortisiert sich nicht. - Sehr kleine Bugs: Birgitta Böckeler beschreibt, wie Kiro einen Mini-Bug in vier User Stories mit 16 Akzeptanzkriterien aufblähte. Ihr Bild: „Vorschlaghammer, um eine Nuss zu knacken." - Stark exploratives Arbeiten: Wenn du selbst nicht weißt, was du bauen willst, hilft eine Spec nicht. Sie erzeugt nur den Eindruck von Klarheit.

Welche Risiken bringt Spec-Driven Development?

SDD ist kein Selbstläufer. Die Praxisberichte legen drei Bruchstellen offen. Markdown-Hölle. Spec Kit erzeugt für jede Feature-Spec eine Vielzahl an Markdown-Dateien plus eigenen Git-Branch. Böckelers Befund: „Ehrlich gesagt überprüfe ich lieber Code als all diese Markdown-Dateien." Wenn der Review-Overhead die Code-Ersparnis frisst, ist das Tool kontraproduktiv. Falsches Kontrollgefühl. Auch mit 200.000 Token Kontext und detaillierten Specs hält die KI die Vorgaben nicht zuverlässig ein. Böckeler beobachtete, dass Spec Kit zwar bestehende Klassen recherchierte, sie im nächsten Schritt aber ignorierte und Duplikate erzeugte. Das passt zum Befund aus der Diskussion um das AI Harness: Kontext allein ersetzt keine Verifikation. Parallele zum gescheiterten MDD. In den 2000ern versuchte Model-Driven Development bereits, aus UML-Modellen Code zu erzeugen. Es scheiterte an Unflexibilität und Overhead. LLMs nehmen den Zwang zur formalen Sprache weg – bringen aber Non-Determinismus mit. Böckelers Sorge: Im schlechtesten Fall kombiniert SDD die Unflexibilität von MDD mit der Unberechenbarkeit von LLMs. Das deutsche Wort, das sie dafür wählt: Verschlimmbesserung.

Wie startest du konkret mit Spec-Driven Development?

Drei Schritte für ein realistisches Pilot-Setup: Schritt 1: Pick a battle, not a war. Wähle ein abgegrenztes Feature, kein Komplett-System. Idealerweise etwas, das du sonst in 3 bis 5 Story Points implementieren würdest. Zu klein wird durch Overhead unwirtschaftlich, zu groß lässt die KI driften. Schritt 2: Tooling minimal halten. Installiere Spec Kit oder Kiro, schreibe deine erste CLAUDE.md mit den Konventionen deines Projekts und teste den dreiteiligen Workflow /specify → /plan → /tasks. Komm nicht in Versuchung, gleich BMAD mit allen Rollen und Templates zu adoptieren. Schritt 3: Comprehension Gate einbauen. Vor jedem Merge muss ein Mensch erklären können, warum die KI welche Lösung gewählt hat. Diese Hürde ist nicht Bürokratie, sondern die Versicherung gegen Dark Code. Die EU-AI-Act-Compliance ergibt sich daraus als Nebenprodukt.

FAQ: Häufig gestellte Fragen zu Spec-Driven Development

Was unterscheidet Spec-Driven Development von einem klassischen PRD? Ein PRD beschreibt das Produkt und richtet sich an Menschen. Eine SDD-Spec beschreibt das Verhalten der Software so präzise, dass eine KI daraus Code erzeugen kann. Sie ist zugleich Produktdokumentation und Eingabe für den Agenten. Damit verschwimmt die Grenze zwischen Produkt-Owner und Engineering-Spec. Ist Spec-Driven Development dasselbe wie Test-Driven Development? Nein. TDD startet mit einem fehlschlagenden Test, der dann zum Code führt. SDD startet mit einer Spezifikation, aus der sowohl Tests als auch Implementierung abgeleitet werden. Die Spec liegt eine Ebene über dem Test und enthält Intent, Constraints und Architektur. Welches Tool soll ich als Einzelentwickler nehmen? Für den absoluten Einstieg reicht oft schon Claude Code Plan Mode oder eine AGENTS.md in Cursor – kein eigenes Framework nötig. Für strukturiertere Projekte ist GitHub Spec Kit die pragmatischste Wahl: Open Source, breite Integration mit Claude Code, Gemini CLI und GitHub Copilot, gute Dokumentation. Für regulierte Umgebungen mit klaren User Stories ist Kiro einfacher. Aider lohnt sich, wenn du den Architect/Editor-Split testen willst. Tessl ist spannend, aber Private Beta. BMAD lohnt nur, wenn du im Team mit klaren Rollen arbeitest. Wie hoch ist der Mehraufwand für die Spec? Heeki Park berichtet, dass die Vorarbeit den späteren Implementierungs-Aufwand deutlich verringert. Anekdotisch geht er von Stunden statt Tagen für Folge-Iterationen aus, weil weniger Course-Correction nötig ist. Belastbare Studien zum ROI fehlen aktuell, der Trend in den Praxisberichten ist aber eindeutig: Vorab-Investment zahlt sich aus. Funktioniert Spec-Driven Development auch für Brownfield-Projekte? Ja, ist sogar einer der stärksten Anwendungsfälle. Simon Martinellis ERP-Modernisierung mit knapp 1.000 Tabellen ist das Paradebeispiel. Voraussetzung: Du zerlegst das System in Self-Contained Systems, sonst überforderst du sowohl die KI als auch dich selbst beim Review. Wo liegen die größten Limits bei Claude Code im SDD-Einsatz? Praktisch sind es zwei Punkte: das 200k-Token-Kontextfenster, das bei umfangreichen Specs schnell durch Compaction unterbrochen wird, und das Conversation-Budget der Subscription-Pläne. Wer Opus 4.6 intensiv nutzt, läuft im Pro-Plan oft schon nach einer Stunde ins Limit. Sonnet 4.6 ist für längere SDD-Sessions deutlich tauglicher.

Fazit

Spec-Driven Development ist 2026 keine Modeerscheinung, sondern die professionelle Antwort auf die Skalierungsgrenzen von Vibe Coding. Wer produktiv mit KI baut und ab August 2026 unter den EU AI Act fällt, kommt um einen strukturierten Spec-Prozess nicht herum. Gleichzeitig sind die Tools jung, die Reviews mühsam und die Verschlimmbesserungs-Gefahr real. Pragmatisch heißt das: Pilot mit Spec Kit oder Kiro starten, Comprehension Gates einziehen, Sonnet 4.6 für längere Sessions nutzen, und ehrlich messen, ob die Markdown-Stapel deinen Output wirklich verbessern. Wie die Schattenseite ohne Spec aussieht, zeigt der Beitrag zu Dark Code. Den industriellen Rahmen liefert der Artikel zu Vibe Coding 2026. Wie Claude Code als agentische IDE arbeitet, steht im Beitrag zu Claude Code in Google Anti Gravity. Wer wiederverwendbare Bausteine für seinen SDD-Workflow bauen will, findet die Grundlagen in Claude Skills 2.0, und das übergeordnete Konzept aller agentischen Werkzeuge steht im AI-Harness-Guide. Verifizierte Quellen: GitHub Blog – Spec-driven development with AI (Sep 2025); Sean Grove – The New Code, AI Engineer World's Fair 2025 (YouTube); Birgitta Böckeler / Thoughtworks – Analyse zu Spec-Driven Development; Heeki Park (AWS) – Medium-Artikel zum AgentCore-Gateway-Workflow mit Claude Code; Anthropic – Claude Code Plan Mode Dokumentation; Amazon – Kiro Dokumentation; Aider – Architect Mode Release Notes (Sep 2024); Cursor – Project Rules / AGENTS.md Dokumentation; Tessl – Framework-Ankündigung; knowis AG – Cloud Solution Workbench (Anbieter-Material); Simon Martinelli – Vortrag zur ERP-Modernisierung mit SDD; Ostroff, Makalsky, Paige (2004) – Agile Specification-Driven Development.