Spec-Driven Development mit Coding-Agenten

Was Spec-Driven Development ist und was nicht

Spec-Driven Development, auf Deutsch spezifikationsgetriebene Entwicklung, ist eine Arbeitsweise mit Coding-Agenten, bei der jede relevante Änderung mit einer kurzen schriftlichen Spezifikation beginnt. Sie beschreibt das Problem, Umfang und Nicht-Ziele, die Akzeptanzkriterien, die Rahmenbedingungen und den Testplan. Der Agent plant und implementiert auf dieser Grundlage, das Review misst das Ergebnis daran, und die Spec liegt im Repository neben dem Code.

Es geht um einzelne Änderungen. Im Wasserfallmodell wurden die Anforderungen eines ganzen Projekts festgeschrieben, bevor jemand Code schrieb. Hier deckt eine Spec eine einzige Änderung ab und wird korrigiert, sobald die Umsetzung zeigt, dass sie falsch war.

Ein Designdokument für jede Änderung gehört ebenfalls nicht dazu. Eine Spec ist so groß wie ihre Änderung: ein paar Zeilen für einen abgegrenzten Fix, eine Seite für ein Feature über mehrere Services, nichts für einen Tippfehler.

Birgitta Böckeler von Thoughtworks unterscheidet drei Stufen: spec-first, bei der die Spec eine Aufgabe leitet und danach verworfen werden darf, spec-anchored, bei der sie für spätere Änderungen am Feature erhalten bleibt, und spec-as-source, bei der Menschen nur noch die Spec bearbeiten. Wir empfehlen, mit spec-first zu beginnen und Specs dauerhaft für die Teile Ihres Systems zu pflegen, die sich häufig ändern.

Warum das zählt, wenn Agenten den Code schreiben

Ein Agent arbeitet mit dem, was er bekommt. Wo eine Anfrage etwas offenlässt, füllt er die Lücke mit einer plausiblen Annahme, und plausible Annahmen fallen im Review kaum auf, weil der Code vernünftig aussieht. Eine Spec legt diese Entscheidungen vor Beginn der Arbeit in die Hand eines Menschen: welche Endpunkte betroffen sind, welches Verhalten sich nicht ändern darf, was der Client im Fehlerfall sieht.

Mit einer Spec lässt sich im Review außerdem prüfen, ob eine Änderung tut, was sie tun sollte. Ohne Spec rekonstruiert der Reviewer den Zweck einer Änderung aus dem Diff und einer Chat-Session, die er nie gesehen hat. Mit Spec prüft er, ob jedes Akzeptanzkriterium einen Test hat, und richtet die übrige Aufmerksamkeit auf das, was Tests nicht zeigen können.

Die Spec macht auch Delegation praktikabel. Eine Aufgabe, die sich schriftlich übergeben lässt, mit Abschlusskriterien, die ein Reviewer ohne Nachvollziehen der Session prüfen kann, kann an einen Agenten gehen, der im Hintergrund läuft. Was sich nicht so klar aufschreiben lässt, bleibt besser interaktiv.

• Der Agent bekommt Umfang, Nicht-Ziele und Rahmenbedingungen, die er sonst raten würde
• Der Reviewer bekommt Kriterien, an denen sich der Diff prüfen lässt
• Das Team behält einen Nachweis, warum sich der Code so verhält
• Die nächste Session übernimmt Kontext, der den Chat überdauert hat

Eine Änderung von der Spezifikation bis zum geprüften Merge

Nehmen wir eine gewöhnliche Änderung: Ihre öffentliche API hat einen Endpunkt zum Zurücksetzen von Passwörtern ohne jedes Limit, und Skripte nutzen ihn, um massenhaft Reset-E-Mails zu verschicken. Die Lösung ist ein Rate Limit, und eine Spec in etwa dieser Größe genügt.

# Rate limit for POST /v1/password-reset

## Problem
No limit today. Scripts use the endpoint to send reset emails in bulk.

## Scope
- Limit requests per email address and per client IP
- Return 429 with a Retry-After header when a limit is hit

## Non-goals
- Limits on other endpoints, CAPTCHA, changes to the email itself

## Acceptance criteria
1. 4th request for one email within 15 minutes returns 429
2. 21st request from one IP within 15 minutes returns 429
3. Responses do not reveal whether an account exists
4. Every 429 is logged with a hashed email and the client IP

## Constraints
- Counters in the existing Redis cluster, limits configurable without a deploy

## Test plan
- Integration tests for criteria 1 to 4 against a local Redis
- Load test in staging: added p95 latency below 5 ms

1. 1

   Spec schreiben und abstimmen

   Ein Engineer entwirft die Spec aus dem Ticket, mit oder ohne Agent, und jemand, der das System kennt, liest sie, bevor etwas geplant wird. Nicht-Ziele und Akzeptanzkriterien verdienen die meiste Aufmerksamkeit, denn genau dort würde der Agent sonst raten.

2. 2

   Den Agenten planen lassen und den Plan prüfen

   Der Agent liest die Spec und den relevanten Code und schlägt einen Plan vor: an welcher Stelle der Request-Pipeline der Limiter sitzt, wie die Zählerschlüssel gebildet werden, was sich an der Konfiguration ändert. Ein Mensch gibt ihn frei oder schickt ihn zurück. Einen Plan zu korrigieren kostet Minuten, fertigen Code zu korrigieren einen Review-Zyklus.

3. 3

   Den Plan in Aufgaben zerlegen

   Jede Aufgabe endet in einem Zustand, in dem der Build durchläuft und die Tests grün sind, damit sich die Arbeit jederzeit prüfen oder anhalten lässt. Hier wären das der Limiter mit Konfiguration, die 429-Antwort mit Logging und der Lasttest.

4. 4

   Mit Tests aus den Kriterien implementieren

   Der Agent schreibt zu jedem Akzeptanzkriterium einen Test, parallel zum Code und idealerweise zuerst. Ein Kriterium, aus dem sich kein Test machen lässt, wird umformuliert oder als manuelle Prüfung mit einer verantwortlichen Person markiert.

5. 5

   Gegen die Akzeptanzkriterien verifizieren

   Lassen Sie die gesamte Testsuite laufen und prüfen Sie jedes Kriterium gegen den Test, der es abdeckt. Wenn Ihr Framework den Agenten seine Arbeit mit der Spec abgleichen lässt, ist das ein erster Durchgang, denn der Agent bewertet dabei seine eigene Arbeit.

6. 6

   Review und Merge

   Der Pull Request enthält die Spec oder verlinkt sie. Der Reviewer prüft Umfang und Nicht-Ziele am Diff, bestätigt, dass jedes Kriterium einen grünen Test hat, und liest den Code auf das hin, was Tests nicht zeigen, etwa wie die Zählerschlüssel gebildet werden. Branch Protection und Pflicht-Checks gelten wie immer.

7. 7

   Die Spec aktuell halten

   Nach dem Merge wird die Spec Teil der Systembeschreibung oder bleibt als datierter Nachweis der Änderung, je nachdem, was im Repository festgelegt ist. Ändert sich das Verhalten später, aktualisieren Sie die Spec im selben Pull Request, denn eine Spec, die dem Code widerspricht, führt jeden Agenten in die Irre, der sie liest.

Wie sich Spec Kit, OpenSpec, BMad, GSD und Kiro unterscheiden

Diese Werkzeuge legen Markdown-Artefakte in Ihrem Repository ab und steuern den Agenten über Slash-Commands oder Skills. Sie unterscheiden sich im Prozess, im Umgang mit Specs nach dem Merge und in den unterstützten Agenten. Wir haben jedes im Oktober 2026 anhand des eigenen Repositorys oder der eigenen Dokumentation geprüft. Neue Releases erscheinen häufig, prüfen Sie also erneut, bevor Sie sich festlegen.

GitHub Spec Kit

Spec Kit ist das Open-Source-Toolkit von GitHub und wird als Python-Kommandozeilenwerkzeug installiert. Nach einer einmaligen Constitution mit den Grundsätzen des Projekts durchläuft jedes Feature specify, plan, tasks, implement und converge, wobei die letzten beiden Schritte wiederholt werden, bis der Konvergenzschritt das Feature als konvergiert meldet. Klärungsfragen, Checklisten und Konsistenzanalyse sind optionale Gates. Die Integrationsliste nennt mehr als 40 Agenten, darunter Claude Code, Codex CLI, Cursor, GitHub Copilot und Gemini CLI.

OpenSpec

OpenSpec, ein npm-Paket von Fission AI, beschreibt sich als flexibel, iterativ und für bestehenden Code ebenso gebaut wie für neue Projekte. Das aktuelle Verhalten des Systems liegt in openspec/specs, und jede Änderung bekommt einen Ordner unter openspec/changes mit Proposal, Delta-Specs, Design und Aufgaben. Delta-Specs halten nur fest, welche Anforderungen hinzukommen, sich ändern oder entfallen, und beim Archivieren einer abgeschlossenen Änderung fließen sie in die Haupt-Specs ein. Der Standardablauf ist propose, apply und archive, unterstützt werden mehr als 30 Tools.

BMad Method

BMad Method ist kostenlos, steht unter MIT-Lizenz und wird als Agent-Skills ausgeliefert, aktuell in Version 6, während Version 7 in Entwicklung ist. Die Planungs-Skills erzeugen je nach Bedarf einen Product Brief, ein PRD, ein UX-Design, eine Architektur oder eine Spec, und ein Ticket-Skill zerlegt größere Vorhaben in geordnete Stories. Die Implementierung läuft über einen Build-Skill, eine Session pro Arbeitseinheit. Vorausgesetzt wird ein Tool mit Skill-Unterstützung, installiert wird über die Skills CLI oder die Plugin-Marketplaces von Claude Code und Codex.

GSD Core

GSD Core führt das Projekt fort, das früher als Get Shit Done veröffentlicht wurde, und wird von Open GSD unter MIT-Lizenz gepflegt. Jede Phase eines Meilensteins durchläuft discuss, plan, execute, verify und ship, wobei die aufwendige Arbeit in Subagenten mit frischem Kontext stattfindet und Entscheidungen in Dateien wie CONTEXT.md und STATE.md festgehalten werden. Es gibt getrennte Einstiege für neue Projekte und bestehende Codebasen, leichtere Befehle für kleine Aufgaben und einen Installer für Claude Code, OpenCode, Codex, GitHub Copilot, Cursor und weitere.

Specs in Kiro

Kiro hat Specs in seine IDE, seine CLI und seine Web-Version eingebaut. Eine Feature-Spec besteht aus Anforderungen, Design und Aufgabenliste, wahlweise mit den Anforderungen oder dem Design zuerst, eine Bugfix-Spec beginnt dagegen mit aktuellem, erwartetem und unverändert bleibendem Verhalten. Anforderungen stehen in EARS-Notation (Easy Approach to Requirements Syntax) und nennen eine auslösende Bedingung und die Reaktion, die das System zeigen soll, was sie testbar hält. Aufgaben laufen einzeln oder in Wellen, die nach Abhängigkeiten geordnet sind, und eine Quick Spec schreibt alle drei Dokumente in einem Durchgang ohne Freigabeschritte.

pstack für Cursor

pstack, das Cursor-Plugin von Lauren Tan im Repository cursor/plugins, sieht Planung skeptisch, und die README sagt das offen: Es enthält keine Planungs-Skills, verlässt sich auf den Plan-Modus von Cursor, und die Autorin hält Code für die beste Spec. Das Playbook für mehrphasige Pläne, gedacht für Arbeit über mehrere Pull Requests, listet für jeden Dateien, Build-Schritte, das erwartete Ergebnis sowie Unit-, Live- und Performance-Prüfungen. Ein Skript prüft den Plan, und die Ausführung wartet auf die Freigabe des Operators.

pstack-Workflows für Cursorpstack in unserer Cursor-Beratung

Welches Framework zu Ihrem Team passt

Diese Entscheidung treffen wir mit den Engineering-Leads anhand der Repositories, der eingesetzten Agenten und des bestehenden Prozesses. Meist entscheiden diese Fragen.

• Bestehender Code oder neues Produkt: Die Delta-Specs von OpenSpec und das Onboarding von GSD Core passen zu bestehenden Codebasen, die Planungsdokumente von BMad Method zu einem neuen Produkt, das zuerst ein PRD und eine Architektur braucht.
• Eingesetzte Agenten: Spec Kit, OpenSpec und GSD Core unterstützen viele Agenten, BMad Method jedes Tool mit Skill-Unterstützung, die Specs von Kiro gehören dagegen zu Kiro und pstack zu Cursor.
• Prozessaufwand: Spec Kit hat fünf Schritte pro Feature plus optionale Gates, der Standardablauf von OpenSpec drei, und die übrigen haben leichtere Wege für kleine Änderungen.
• Mehrere Repositories: OpenSpec kann Specs in einem eigenen Planungs-Repository halten, das sich mehrere Code-Repositories teilen, eine Funktion, die noch im Beta-Status ist.
• Datenfluss: OpenSpec erhebt anonyme Nutzungsstatistiken, solange Sie sie nicht abschalten, und Specs gehen genau wie Code an das Modell Ihres Agenten.

Wenn keines passt, kommen Sie mit einer Spec-Vorlage im Repository und einer Review-Regel schon weit. Ein Framework lohnt den Einrichtungsaufwand, sobald die Gewohnheit besteht und Sie in jedem Repository dieselben Befehle und Checks wollen.

Wo Spec-Driven Development schiefgeht

Die Praxis scheitert auf einige vorhersehbare Arten. Für jede gibt es eine einfache Gegenmaßnahme.

Zu lange Specs

Generierte Specs wachsen schnell, und lange Specs werden nur noch überflogen. In ihrer Untersuchung von Kiro und Spec Kit für martinfowler.com vom Oktober 2025 beschreibt Birgitta Böckeler einen kleinen Bug, aus dem der Anforderungsschritt von Kiro vier User Stories mit sechzehn Akzeptanzkriterien machte, und schreibt, dass sie bei Spec Kit lieber Code als all das Markdown reviewt hätte. Die Werkzeuge haben sich seitdem weiterentwickelt, die Lehre bleibt: Die Spec enthält nur, was ein Reviewer tatsächlich prüft.

Specs, die vom Code abweichen

Eine Spec, die bei Verhaltensänderungen nicht nachgezogen wird, beschreibt mit großer Bestimmtheit etwas, das es nicht mehr gibt, und der nächste Agent hält sie für die Wahrheit. Ändern Sie die Spec im selben Pull Request wie den Code, und machen Sie das zum Teil Ihrer Definition of Done.

Akzeptanzkriterien ohne Tests

Ein Kriterium wie „schnell genug“ kann nicht scheitern, deshalb braucht jedes ein beobachtbares Ergebnis und einen Test oder eine benannte manuelle Prüfung. Böckeler beobachtete außerdem, wie der Agent bei Spec Kit Hinweise auf bestehende Klassen als neue Spezifikation behandelte und die Klassen als Duplikate neu erzeugte. Specs verringern das Raten, garantieren aber nicht, dass der Agent ihnen folgt, deshalb kommt die Verifikation aus Tests und menschlichem Review.

Prozessaufwand für kleine Änderungen

Bei einem Einzeiler kostet der volle Ablauf mehr, als er bringt, und die Frameworks sehen das genauso. BMad Method schickt kleine, klare Änderungen direkt in den Build-Schritt, Kiro bietet eine Quick Spec ohne Freigabeschritte, GSD Core hat leichtere Befehle für kleine Aufgaben, und das Planungs-Playbook von pstack verzichtet bei offensichtlichem Lösungsweg auf den Plan. Legen Sie fest, welche Arten von Änderungen eine Spec brauchen, und lassen Sie den Rest durch Ihren normalen Prozess laufen.

Spec-Driven Development im Team einführen

Wir führen die Praxis eine Art von Änderung nach der anderen ein. Sie läuft innerhalb des Prozesses, den Ihr Team schon hat.

1. 1

   Eine Art von Änderung auswählen

   Wählen Sie Änderungen, die häufig vorkommen, klar abgegrenzt und testbar sind, etwa neue API-Endpunkte oder Validierungsregeln. Alles andere bleibt vorerst beim bisherigen Prozess.

2. 2

   Eine Spec-Vorlage ins Repository legen

   Beschränken Sie sie auf die sechs Überschriften aus dem Beispiel und verweisen Sie in Ihren Agenten-Anweisungen darauf, in AGENTS.md oder der Entsprechung Ihres Tools. Die Vorlagen eines Frameworks können sie später ersetzen.

3. 3

   Specs vor dem Code reviewen

   Ein zweiter Engineer liest die Spec, bevor der Agent plant, im Pull Request oder im Ticket. Bei Änderungen an gemeinsam genutztem Code wird auch der Plan geprüft.

4. 4

   Kriterien an Checks binden

   Machen Sie es zur Review-Regel, dass jedes Akzeptanzkriterium einem Test oder einer benannten manuellen Prüfung zugeordnet ist. Wo das mit wenig Aufwand geht, prüft die CI, ob Änderungen dieser Art eine Spec enthalten.

5. 5

   Am eigenen Code messen

   Vergleichen Sie nach einigen Wochen Änderungen mit Spec mit ähnlichen Änderungen ohne: Review-Runden, Nacharbeit nach dem Merge, Zeit vom Ticket bis zum Merge. Gehen Sie nur dann zur nächsten Art von Änderung über, wenn der Vergleich dafür spricht.

Wie Cloudsail unterstützt

Wir führen Spec-Driven-Development-Workshops für Engineering-Teams in deren eigenen Repositories durch, an Änderungen aus dem eigenen Backlog. Die Engineers schreiben Specs für echte Arbeit, prüfen die Pläne des Agenten und gleichen die Ergebnisse mit den Akzeptanzkriterien ab. Die Workshops finden remote oder vor Ort in Deutschland und Polen statt, auf Englisch, Deutsch oder Polnisch. Offene Kurse und Zertifikate bieten wir nicht an.

Rund um die Workshops richten wir ein, wovon die Praxis abhängt: Spec-Vorlage und Agenten-Anweisungen in Ihren Repositories, Build- und Testbefehle, die der Agent ausführen kann, Review-Regeln und, wenn Sie eines wollen, ein Framework, das für Ihre Agenten konfiguriert ist. Anschließend messen wir die Wirkung an Ihren eigenen Änderungen, bevor die Praxis auf weitere Teams übergeht.

Harness EngineeringEinführung von Coding-AgentenClaude Code Training