Spec-Driven Development in der Praxis: Drei Tools im Vergleich

Mein Kollege und Namensvetter Daniel Wochnik hat in seinem Beitrag zu Spec-Driven Development den Ansatz und seine Grenzen eingeordnet — dieser Artikel ist die kleine Praxiserfahrung dazu. Drei aktuelle SDD-Tools, dieselbe Aufgabe, drei unterschiedliche Ergebnisse.

KI-Coding-Agenten sind produktiv — bis sie es nicht mehr sind. Ein Agent ohne klaren Kontext rät, interpretiert und baut an der eigentlichen Aufgabe vorbei. Spec-Driven Development (SDD) ist ein Ansatz, der genau das verhindert: Bevor Code entsteht, schreibt man eine strukturierte Spezifikation. Die Spec wird zur einzigen Quelle der Wahrheit. Der Agent implementiert dagegen — nicht gegen einen vagen Prompt.

Eine SDD-Spec besteht typischerweise aus drei Teilen: Requirements beschreiben, was das System tun soll und was Erfolg bedeutet. Das Design legt fest, wie es aufgebaut sein soll — Architektur, Datenmodell, Schnittstellen. Tasks zerlegen das Ganze in atomare, ausführbare Schritte. Dieser Ansatz ist besonders wertvoll bei bestehenden Codebases, wo ein Agent ohne strukturierten Kontext schnell in die falsche Richtung läuft — aber auch bei neuen Projekten erzwingt er ein Nachdenken, das später Kosten spart.

Drei Tools setzen SDD unterschiedlich um. Um sie greifbar zu vergleichen, habe ich jedes dieselbe Aufgabe lösen lassen: eine Todo-CLI in TypeScript mit den Befehlen add, list, complete und delete. Kein synthetischer Benchmark — jede Session wurde tatsächlich durchgespielt, die Artefakte und Outputs sind echt.

Der entscheidende Effekt vorab: Spec-Präzision bestimmt Code-Verhalten

Alle drei Tools haben das complete-Feature implementiert — und doch unterscheidet sich das Ergebnis:

Spec Kit schrieb in seiner Spec:

„Given a pending todo exists with a known ID, When the user runs complete <id>, Then the item’s status changes to done.”

Kiro formulierte es als formalen Kontrakt:

„WHEN der Benutzer complete <todo_id> ausführt, THE CLI SHALL den Status auf completed setzen.”

GSD schrieb eine prüfbare Checkbox:

„CLI-03: User kann todo complete <ID> ausführen um den Erledigungsstatus zu toggeln.”

Spec Kit und Kiro bauten einen nicht-reversiblen Übergang — einmal erledigt, bleibt erledigt. GSD baute einen Toggle, weil das Wort „toggeln” in der Requirements-Checkbox stand. Gleiches Projekt, gleiches Feature, unterschiedliches Verhalten. Das ist kein Zufall und kein Bug. Die Präzision der Spec bestimmt die Präzision des Codes — und das ist der zentrale Gedanke hinter SDD.

Tool 1: Spec Kit

Spec Kit ist ein prozessorientiertes Open-Source-Toolkit von GitHub. Es legt sich als Slash-Command-Layer über den bestehenden Coding Agent und strukturiert die Arbeit in einem wiederholbaren Zyklus: specify → plan → tasks. Das Tool unterstützt über 30 AI Coding Agents und ist vollständig toolagnostisch — das genutzte LLM ergibt sich aus dem gewählten Tool.

Optional kann zu Projektbeginn eine constitution.md angelegt werden, die unveränderliche Projektprinzipien festhält und in jeden Workflow-Schritt einfließt — etwa Teststrategie, Architekturvorgaben oder Non-Negotiables. In diesem Experiment wurde die Constitution als leeres Template angelegt, aber nicht befüllt; der Workflow funktionierte auch ohne sie einwandfrei.

uvx --from git+https://github.com/github/spec-kit.git specify init todo-cli-speckit

Was Spec Kit erzeugt hat

Nach /specify entstand specs/main/spec.md — strukturiert nach User Stories mit Given/When/Then-Szenarien:

### User Story 1 - Add a Todo Item (Priority: P1)

**Acceptance Scenarios**:

1. **Given** no todos exist, **When** the user runs `add "Buy groceries"`,
   **Then** the system creates a new todo with a unique ID, displays a
   confirmation message including the ID, and the item is retrievable
   in subsequent sessions.

2. **Given** the user provides an empty description,
   **When** the `add` command is run,
   **Then** the system displays an error message and no item is created.

Danach folgten plan.md (Stack, Verzeichnisstruktur, Build-Befehle), data-model.md (Entitäten, JSON-Schema, ID-Strategie) und schließlich tasks.md — 23 Tasks in 7 Phasen, mit expliziten Parallelisierungsmarkierungen:

## Phase 3: User Story 1 — Add a Todo Item 🎯 MVP

- [x] T009 [US1] Implement `add` command handler in `src/commands/add.ts`
- [x] T010 [US1] Register `add` command in `src/index.ts`
- [x] T011 [P] [US1] Write unit tests for add command

Der Entwickler gibt diese Tasks dann an den Agenten zur Ausführung weiter — Spec Kit erzeugt die Artefakte und wartet auf den nächsten Schritt. Das Ergebnis im Terminal:

$ todo add "Einkaufen gehen"
✓ Added todo #1: Einkaufen gehen

$ todo add "Artikel fertigschreiben"
✓ Added todo #2: Artikel fertigschreiben

$ todo list
ID   Status  Description
---  ------  ----------------------------------------
1    [ ]     Einkaufen gehen
2    [ ]     Artikel fertigschreiben

$ todo complete 1
✓ Completed todo #1: Einkaufen gehen

$ todo list
ID   Status  Description
---  ------  ----------------------------------------
1    [✓]     Einkaufen gehen
2    [ ]     Artikel fertigschreiben

$ todo delete 2
✓ Deleted todo #2: Artikel fertigschreiben

$ todo add ""
Error: Description must not be empty.

Fazit

Alles verlief reibungslos, die nächsten Schritte waren jederzeit klar. Die Spec denkt konsequent in User Stories — das macht sie auch für Nicht-Entwickler lesbar und ist ein echter Vorteil in Teams.

Tradeoff: An jedem Checkpoint wird aktives Steuern erwartet. Wer nach der Planungsphase eine autonome Ausführung erwartet, wird enttäuscht.

Tool 2: Kiro

Kiro ist primär eine vollständige IDE — aufgebaut auf Code OSS, der Open-Source-Basis von VS Code — mit SDD als First-Class Feature. Entwickelt von AWS, betreibt Kiro eine eigene Plattform mit Credit-System. Zusätzlich zur IDE gibt es ein CLI für bestehende Setups.

Kiro bietet zwei Einstiegspunkte: Requirements-First startet mit EARS-Requirements und leitet daraus das Design ab — der üblichere Weg für Feature-Entwicklung. Design-First dreht das um: erst Architektur definieren, dann daraus machbare Requirements ableiten — nützlich, wenn technische Constraints den Lösungsraum von vornherein einschränken.

Als projektweite Memory Bank kennt Kiro das Steering-Konzept: Dateien wie product.md, structure.md und tech.md halten Kontext über das Gesamtprojekt fest — das funktionale Äquivalent zur Spec-Kit-Constitution.

Was Kiro erzeugt hat

Kiro erzeugt Requirements in EARS-Notation (Easy Approach to Requirements Syntax) — einem formalen Standard aus der Systemtechnik, der auf die Struktur WHEN ... THE SYSTEM SHALL ... setzt:

### Requirement 1: Todo hinzufügen

#### Acceptance Criteria

1. WHEN der Benutzer `add "<titel>"` ausführt,
   THE CLI SHALL ein neues Todo mit dem angegebenen Titel, einer eindeutigen
   Todo_ID, dem Status `pending` und dem aktuellen Datum erstellen.

[...]

4. IF der Benutzer `add` ohne Titel ausführt,
   THEN THE CLI SHALL eine Fehlermeldung ausgeben,
   die auf den fehlenden Titel hinweist.

5. IF der angegebene Titel ausschließlich aus Leerzeichen besteht,
   THEN THE CLI SHALL eine Fehlermeldung ausgeben und kein Todo erstellen.

Das Design-Dokument geht deutlich tiefer als bei den anderen Tools: vollständige TypeScript-Interface-Definitionen, 13 formale Correctness Properties und eine Testing-Strategie mit Property-Based Testing via fast-check. Besonders auffällig ist ein typsicherer ServiceResult<T>-Typ für explizite Fehlerbehandlung, den Kiro als Teil des Designs vorschlägt:

type ServiceResult<T> =
  | { success: true; data: T }
  | { success: false; error: string };

Dieser Typ stammt direkt aus dem generierten design.md — nicht aus dem produzierten Code — und zeigt, wie tief Kiro in die Architekturentscheidungen einsteigt. Das Ergebnis im Terminal:

$ todo add "Einkaufen gehen"
Todo #1 "Einkaufen gehen" wurde hinzugefügt.

$ todo add "Artikel fertigschreiben"
Todo #2 "Artikel fertigschreiben" wurde hinzugefügt.

$ todo list
[ ] #1 Einkaufen gehen (pending) - 2026-04-29
[ ] #2 Artikel fertigschreiben (pending) - 2026-04-29

$ todo complete 1
Todo #1 "Einkaufen gehen" wurde als erledigt markiert.

$ todo list
[✓] #1 Einkaufen gehen (completed) - 2026-04-29
[ ] #2 Artikel fertigschreiben (pending) - 2026-04-29

$ todo delete 2
Todo #2 "Artikel fertigschreiben" wurde gelöscht.

Fazit

Verlief problemlos und erzeugte die tiefsten Artefakte aller drei Tools. Die EARS-Notation erzwingt eine Präzision, die sich auszahlt: Das IF ... THEN-Muster macht fehlende Edge Cases sofort sichtbar. Die 13 Correctness Properties im Design-Dokument sind ein Qualitätsmerkmal, das die anderen Tools nicht mitliefern.

Tradeoff: Kiro benötigt eigene Credits. Die 500 Credits, mit denen neue Nutzer starten, sind ein einmaliger 30-tägiger Trial-Bonus — der permanente Free Tier enthält danach nur 50 Credits pro Monat. Die Session für dieses Projekt verbrauchte 23,57 Credits; für intensivere Nutzung greift man schnell in den bezahlten Bereich (ab 20 USD/Monat). Dazu kommt die Plattformabhängigkeit: Spec Kit und GSD binden sich in das vorhandene Tool ein und bleiben damit vollständig in der eigenen Infrastruktur. Kiro ist eine eigene Plattform mit eigenem Backend — das ist eine andere Art von Commitment.

Tool 3: GSD — Get Shit Done

GSD ist ein SDD-Toolkit, das sich per npx als Slash-Command-Layer in den bestehenden Editor installiert — analog zu Spec Kit, aber mit einem anderen Schwerpunkt. Statt Artefakte zu erzeugen und auf manuelle Ausführung zu warten, orchestriert GSD die Implementierung aktiv: Pläne werden in atomar unabhängige Tasks zerlegt, die von Subagenten mit frischen Kontexten parallel ausgeführt werden. Das Ergebnis ist ein Walk-Away-Modus — Ausführungsphase starten und zu fertigem Code zurückkommen.

GSD unterstützt über 14 Runtimes (u. a. Claude Code, Gemini CLI, OpenCode, Copilot, Cursor, Windsurf, Codex, Augment) und nutzt jeweils das Modell, das im gewählten Tool konfiguriert ist. Die Kernidee dahinter: KI-Agenten produzieren schlechteren Code, je länger ein Kontextfenster wächst. GSD bekämpft das, indem jeder Subagent nur den Kontext bekommt, den er für seinen Task braucht.

# Das "cc" im Paketnamen ist historisch (ursprünglich Claude-Code-only);
# die Runtime wird interaktiv bei der Installation gewählt
npx get-shit-done-cc@latest

Was GSD erzeugt hat

GSD arbeitet mit einer .planning/-Hierarchie mit klar getrennten Verantwortlichkeiten.

REQUIREMENTS.md — Anforderungen als prüfbare Checklisten mit IDs und vollständiger Traceability-Matrix (Requirement → Phase → Status):

### CLI Commands

- [ ] **CLI-01**: User kann `todo add "text"` ausführen
- [ ] **CLI-02**: User kann `todo list` ausführen (Format: `[1] [ ] text`)
- [ ] **CLI-03**: User kann `todo complete <ID>` ausführen (Toggle)
- [ ] **CLI-04**: User kann `todo delete <ID>` ausführen

| Requirement | Phase | Status  |
| ----------- | ----- | ------- |
| CLI-01      | 2     | Pending |
| STOR-01     | 1     | Pending |

ROADMAP.md — Phasen mit messbaren Success Criteria, formuliert als explizit überprüfbare Fakten:

### Phase 1: Scaffold and Storage

**Success Criteria** (what must be TRUE):

1. `npm run build` compiles TypeScript to `dist/` without errors
2. `todos.json` is created automatically on first run
3. Todos saved in one invocation are present in the next invocation
4. Deleted todos never have their ID reassigned

Dazu kommen PROJECT.md (lebende Projekt-Charter mit Key Decisions und Out-of-Scope-Liste) und STATE.md (aktueller Ausführungsstatus). Für jeden Task erzeugt GSD strukturierte Plan-Dateien mit Ausführungsanweisungen, Verifikationsschritten und einer Definition of Done. Das Ergebnis im Terminal, nachdem GSD Phase 1 und 2 autonom ausgeführt hat:

$ todo add "Einkaufen gehen"
Added [1] Einkaufen gehen

$ todo add "Artikel fertigschreiben"
Added [2] Artikel fertigschreiben

$ todo list
[1] [ ] Einkaufen gehen
[2] [ ] Artikel fertigschreiben

$ todo complete 1
Completed [1] Einkaufen gehen

$ todo list
[1] [x] Einkaufen gehen
[2] [ ] Artikel fertigschreiben

$ todo delete 2
Deleted [2] Artikel fertigschreiben

$ todo list
No todos yet. Run: todo add "text"

Fazit

Die Parallelisierung funktioniert — Phase 1 wurde vollständig fertig ausgeliefert, bevor Phase 2 startete. Der Walk-Away-Modus ist real: Ausführungsphase starten, zurückkommen, fertiger Code mit sauberem Git-Log und atomaren Commits pro Task. Das dauert aber spürbar länger als bei den anderen Tools, weil jeder Subagent einen eigenen Kontext aufbaut.

Tradeoff: Die .planning/-Struktur und die Phase-Befehle sind beim ersten Kontakt erschlagend. Hat man den Workflow einmal verinnerlicht, ist GSD das autonomste der drei Tools — der initiale Lernaufwand ist real, aber einmalig.

Vergleichstabelle

Fazit: Welches Tool für welches Szenario?

Neues Projekt im Team, SDD zum ersten Mal einführen: Spec Kit. Die Given/When/Then-Specs sind auch für Nicht-Entwickler lesbar, der Workflow ist leicht erklärbar, und das Tool legt sich auf keinen Agent und keine Plattform fest. Die optionale Constitution ist sinnvoll, sobald ein Team gemeinsame Prinzipien formalisieren will — für den Einstieg ist sie nicht nötig.

Komplexes Projekt, allein oder im kleinen Team, Wert auf Artefaktqualität: Kiro. Die EARS-Notation und die Correctness Properties erzwingen eine Gründlichkeit, die sich bei nicht-trivialen Projekten auszahlt. Der Design-First-Workflow ist besonders interessant, wenn technische Constraints den Lösungsraum von vornherein einschränken. Die Plattformabhängigkeit und die Credit-Kosten sind einzukalkulieren — besonders der Unterschied zwischen Trial-Credits und dem dauerhaften Free Tier.

Größere Features allein, Agent soll nach der Planungsphase autonom durchimplementieren — ob Greenfield oder bestehende Codebase: GSD. Die Parallelisierung, die Phasentrennung und der Walk-Away-Modus liefern genau das. Der strukturierte Kontext durch .planning/ ist besonders in bestehenden Projekten wertvoll, wo ein Agent ohne Orientierung schnell in die falsche Richtung läuft.

Der gemeinsame Nenner: Die Präzision der Spec bestimmt die Präzision des Codes — das hat das Toggle-Beispiel am Anfang gezeigt. Welches Tool man wählt, entscheidet darüber, wie viel Struktur man beim Schreiben dieser Spec bekommt und wie autonom der Agent danach arbeiten kann. Wer nach dieser kleinen Praxisrunde noch einmal die größere Frage stellen will — ob SDD wirklich das Vibecoding ablöst oder nur Kontrolle besser verpackt — findet die ausführliche Einordnung im Beitrag meines Kollegen Daniel Wochnik.

Wie Ihr Team SDD und KI-Coding-Agenten methodisch in den Alltag integriert? Genau darum geht es in unserem Training zu agentenbasiertem Coding.