Spec-Driven Development heißt: Bevor ein KI-Agent Code schreibt, legst du schriftlich fest, was entstehen soll, warum und woran du erkennst, dass es fertig ist. Aus dieser Spezifikation, kurz Spec, leitet der Agent einen technischen Plan und kleine Aufgaben ab, setzt sie nacheinander um, und am Ende wird das Ergebnis gegen die Spec geprüft. Die Methode lohnt sich für Funktionen mit mehreren Schritten, für einen Tippfehler oder einen kleinen Fehler mit klarer Ursache ist sie zu schwer.
Meine KI-Mitarbeiter arbeiten mit Claude Code, und bei ihnen startet jede Arbeit mit einem Auftrag, in dem Ergebnis und Grenzen festgelegt sind. Das ist im Kern dasselbe Prinzip. Weiter unten zeige ich, wie ich es übertrage.
Was Spec-Driven Development ist
Wenn du Software mit KI entwickelst, gibt es zwei Arten zu arbeiten. Die eine: Du schreibst einen Wunsch in den Chat und korrigierst Nachricht für Nachricht. Lässt du den Code dabei ungelesen durch, ist das Vibe Coding: was es ist und für wen es taugt. Die andere: Du klärst vorher schriftlich, was gebaut wird, und misst den Agenten daran. Das ist Spec Driven Development. Wie sich die Arbeit mit Coding-Agenten insgesamt verändert, beschreibe ich in Agentic Coding: mehr als Vibe Coding.
GitHub begründet den Ansatz so: Das Problem sei nicht die Programmierfähigkeit des Agenten, sondern unser Vorgehen. Coding-Agenten seien eher Programmierpartner, die alles wörtlich nehmen, und bräuchten eindeutige Anweisungen.
Eine feste Definition gibt es noch nicht. Die Entwicklerin Birgitta Böckeler von Thoughtworks schreibt, der Begriff sei „noch nicht sehr gut definiert“, manche nutzten „Spec“ schon als anderes Wort für einen ausführlichen Prompt. Sie unterscheidet drei Stufen: Spec-first (die Spec wird für eine Aufgabe geschrieben und dann genutzt), Spec-anchored (die Spec bleibt nach der Aufgabe erhalten und wird mitgepflegt) und Spec-as-source (der Mensch ändert nur noch die Spec, nie den Code).
Werkzeuge und Ansätze, Stand 30.10.2026
GitHub Spec Kit
Spec Kit ist ein Open-Source-Werkzeugkasten von GitHub unter MIT-Lizenz, die aktuelle Version 1.2.5 erschien am 28.10.2026. Laut Readme gibt er KI-Coding-Agenten feste Abläufe, Vorlagen und dokumentierte Ergebnisse. Du installierst die Kommandozeile specify (Python 3.11 oder neuer und uv) und richtest damit ein Projekt für deinen Agenten ein. Claude Code ist eine der unterstützten Integrationen, neben GitHub Copilot, Codex CLI, Gemini CLI, Cursor, Kiro CLI und weiteren.
Den Ablauf steuerst du dann im Chat des Agenten:
Die Schreibweise hängt vom Agenten ab, in GitHub Copilot etwa /speckit-specify. Implement und Converge wiederholst du, bis Converge meldet, dass alles erfüllt ist.
Kiro
Kiro ist eine Entwicklungsumgebung mit Agent, laut Hersteller gebaut und betrieben von AWS. Eine Spec in Kiro besteht aus drei Dateien: requirements.md (bei Fehlern bugfix.md) mit User Stories und Akzeptanzkriterien, design.md mit Architektur und Abläufen, tasks.md mit einzelnen, verfolgbaren Aufgaben. Die Anforderungen schreibt Kiro in der EARS-Notation: „WHEN [Bedingung] THE SYSTEM SHALL [Verhalten]“, also „Wenn …, dann soll das System …“. Für gut verstandene Funktionen gibt es Quick Spec, das alle drei Schritte ohne Freigabe dazwischen erzeugt.
Claude Code: Plan-Modus und SPEC.md
Claude Code hat kein eigenes Spec-Framework, aber zwei Bausteine. Der Plan-Modus lässt Claude Dateien lesen und einen Plan schreiben, ändert aber nichts, bis du den Plan freigibst. Du schaltest ihn mit Shift+Tab, mit /plan vor einer Eingabe oder mit claude --permission-mode plan ein, Ctrl+G öffnet den Plan zum Bearbeiten im Editor. Weitere Befehle stehen in Claude Code Befehle: die wichtigsten 15.
Der Plan-Modus deckt den zweiten Schritt ab, das Wie. Für das Was empfehlen die Best Practices von Anthropic, dich von Claude interviewen zu lassen, bis es die Spec schreiben kann, und sie in eine Datei SPEC.md zu legen. Gebaut wird danach in einer neuen Sitzung, damit die Arbeit mit sauberem Kontext und einer schriftlichen Definition von „fertig“ beginnt. Warum ein frischer Kontext hilft, erkläre ich in Kontext und Kontextfenster bei KI erklärt. Zum Schluss prüft ein Subagent die Änderungen gegen SPEC.md, am besten einer, der nur lesen darf. Wie du so eine Rolle anlegst, steht in Claude Code Subagents: Best Practices.
Wie eine gute Spec aussieht
Ein ausgedachtes Beispiel: Ein Handwerksbetrieb will auf seiner Website ein Formular für Rückrufwünsche.
# Spec: Rückrufwunsch auf der Website
## Ziel und Warum
Interessenten sollen einen Rückruf anfordern können, ohne anzurufen.
Das Büro ruft innerhalb eines Werktags zurück.
## Anforderungen
1. WENN jemand Name, Telefonnummer und Anliegen absendet,
DANN SOLL das System den Wunsch speichern und eine Bestätigung zeigen.
2. WENN die Telefonnummer fehlt oder ungültig ist,
DANN SOLL das System das Feld markieren und nichts speichern.
3. WENN ein neuer Wunsch eingeht,
DANN SOLL das Büro eine Mail bekommen, ohne Telefonnummer im Betreff.
## Nicht im Umfang
- Terminbuchung, Kundenkonto, Zahlung
## Randbedingungen
- Datenschutzhinweis am Formular
- Läuft auf der bestehenden Website (Technik legt der Plan fest)
## Offene Fragen
- Wer löscht erledigte Wünsche, und nach wie vielen Tagen?
## Fertig, wenn
- Jede Anforderung hat einen Test, und alle Tests laufen durch
- Ein Mensch hat das Formular einmal auf dem Handy abgeschickt
Worauf es ankommt:
- Jede Anforderung ist prüfbar. Die Wenn-dann-Form nach EARS zwingt dich, Auslöser und Ergebnis zu nennen. Daraus wird später ein Test.
- Nicht-Ziele stehen drin. Was nicht gebaut wird, baut der Agent dann auch nicht dazu.
- Keine Technik in der Spec. Framework und Datenbank gehören in den Plan.
- Offene Fragen sind sichtbar. Lieber eine Frage in der Spec als eine Annahme im Code.
- „Fertig“ ist definiert. Ohne diesen Abschnitt hat die Prüfung im fünften Schritt keinen Maßstab.
Vorteile und Grenzen
Der Hauptvorteil für die KI-Softwareentwicklung ist Prüfbarkeit. Missverständnisse fallen vor dem Code auf, der Agent liefert kleine, nachvollziehbare Änderungen, und die Spec überlebt die Sitzung, ein zweiter Agent kann mit der Datei weitermachen. Anthropic nennt für Läufe ohne Aufsicht als erste Frage, ob der Agent weiß, wie „fertig“ aussieht, etwa durch eine Spec-Datei oder einen Test, der grün werden muss.
Die Grenzen beschreibt Böckeler aus eigenen Versuchen mit Kiro und Spec Kit im Oktober 2025. Beide Werkzeuge haben sich seitdem weiterentwickelt, die Fragen bleiben:
- Ein Ablauf für jede Größe. Einen kleinen Fehler machte Kiros Ablauf zu vier User Stories mit 16 Akzeptanzkriterien. Sie nennt das „mit dem Vorschlaghammer eine Nuss knacken“.
- Viel Text zum Prüfen. Spec Kit erzeugte bei ihr viele ausführliche Dateien. Sie würde nach eigener Aussage lieber Code prüfen als all diese Markdown-Dateien.
- Scheinbare Kontrolle. Trotz Vorlagen und Checklisten folgte der Agent nach ihrer Beobachtung oft nicht allen Anweisungen. Die Spec ersetzt also nicht die Prüfung, sie macht sie erst möglich.
- Pflege nach Änderungen. Spec Kit schreibt laut Doku nicht vor, wie Spec, Plan und Aufgaben gepflegt werden, wenn sich Anforderungen ändern. Das musst du selbst regeln.
Ein Hinweis aus der Anthropic-Doku: Ein Prüfer, der Probleme finden soll, findet immer etwas. Begrenze ihn deshalb auf Lücken gegenüber der Spec und lass Stilfragen weg.
Wann es sich nicht lohnt
- Kleine Fehler mit klarer Ursache. Hier ist die Spec länger als die Änderung. Spec Kit hat für Fehler einen eigenen, kürzeren Ablauf, Kiro eigene Bugfix-Specs.
- Wegwerf-Prototypen. Ob eine Idee trägt, zeigt ein schneller Versuch besser als eine Spec, die niemand pflegt.
- Du weißt noch nicht, was du willst. Dann hilft das Interview mit Claude oder ein kurzer Prototyp, und die Spec folgt danach.
- Niemand prüft am Ende. Ohne den fünften Schritt bleibt von Spec-Driven Development nur ein langer Prompt.
Wie ich das auf KI-Mitarbeiter übertrage
Meine KI-Mitarbeiter arbeiten mit Claude Code, jeder in einem eigenen Ordner mit Personalakte, Arbeitsanweisungen, Skills, Wissen und Auftragsordnern. Jede Arbeit startet mit einem Auftrag in einer Datei auftrag.md, in dem Ergebnis und Grenzen festgelegt sind. Bevor etwas live geht, prüft ein getrennter Prüfer, und wer etwas erstellt hat, prüft es nie selbst.
Übertragen auf die fünf Schritte: Der Auftrag ist die Spec, die Prüfung gegen den Auftrag ist der fünfte Schritt. Wie so ein Ordner aufgebaut ist, steht in KI-Mitarbeiter erstellen: so startest du, wie die Belegschaft auf einem Server läuft, in Claude Code auf dem Server betreiben. Eine Rolle, die Ergebnisse gegen einen Auftrag prüft, ist Kai.
Häufige Fragen
Was gehört in eine Spec?
Ziel und Warum, prüfbare Anforderungen, was nicht gebaut wird, Randbedingungen ohne Technikwahl, offene Fragen und eine Definition von „fertig“. Das Gerüst oben zeigt alle sechs Teile an einem Beispiel.
Brauche ich Spec Kit oder Kiro dafür?
Nein. Eine Markdown-Datei mit Ziel, Anforderungen, Nicht-Zielen und einer Definition von „fertig“ reicht für den Anfang. Wer den Entwurf schreibt, du oder der Agent, ist zweitrangig, solange du ihn vor dem Bauen liest und freigibst. Spec Kit und Kiro geben dir feste Abläufe und Vorlagen, das hilft im Team.
Ist der Plan-Modus in Claude Code schon Spec-Driven Development?
Nur zum Teil. Der Plan-Modus erzeugt das Wie und hält Claude vom Ändern ab, bis du freigibst. Das Was und der Prüfmaßstab fehlen darin. Zusammen mit einer SPEC.md und einer Prüfung durch einen Subagenten wird daraus der ganze Ablauf.
Was passiert, wenn sich die Anforderungen ändern?
Dann änderst du zuerst die Spec, danach Plan und Code. Ob du die Spec nach der Aufgabe weiter pflegst, entscheidest du; genau das unterscheidet Spec-first von Spec-anchored.
Wie du weitermachst
Wenn du Claude Code noch nicht eingerichtet hast, starte mit Claude Code: Anleitung für Einsteiger. Schreib dann für deine nächste größere Änderung eine Spec nach dem Gerüst oben und lass am Ende einen Prüfer dagegen laufen. Wie so eine Prüfung mit den Werkzeugen von Anthropic aussieht, steht in Claude Code Review: Kosten, Ablauf, Grenzen. Den größeren Rahmen beschreibt Agentic Coding: mehr als Vibe Coding. Wie andere Selbstständige ihren KI-Mitarbeitern Aufträge schreiben und Ergebnisse prüfen lassen, besprechen wir in meiner Community Claude Practitioners.
