> Vibe Coding scheitert an echten Codebasen. Schreib eine Spec mit Akzeptanzkriterien, Plan und Tasks, lass den Agenten abhaken und prüfe vor dem ersten Code.
>
> Web page: https://balazscsorba.com/de/blog/spec-driven-development-coding-agents · Language: Deutsch · Also available in: [English](https://balazscsorba.com/blog/spec-driven-development-coding-agents.md) · [Magyar](https://balazscsorba.com/hu/blog/spec-driven-development-coding-agents.md)
> Author: Balázs Csorba · Published: 2026-09-30 · Keywords: spec-driven development, spec driven development coding agents, acceptance criteria for coding agents, AI coding agent plan mode, GitHub Spec Kit, Kiro specs requirements design tasks, vibe coding vs spec-driven development, EARS requirements syntax

[Blog](https://balazscsorba.com/de/blog)/KI-Agenten

# Spec-driven Development für Coding-Agenten: den Plan vor dem Code festlegen

Vibe Coding scheitert an echten Codebasen. Schreib eine Spec mit Akzeptanzkriterien, Plan und Tasks, lass den Agenten abhaken und prüfe vor dem ersten Code.

[Balázs Csorba](https://balazscsorba.com/de/about)·30\. September 2026·11 Min. Lesezeit

-   Spec-driven development
-   Coding agents
-   Acceptance criteria
-   Plan mode
-   AI engineering

![Titelbild zu Spec-driven Development: eine Pipeline von Spec und Plan zu Tasks und Verifikation, mit einem Review-Gate vor jedem Code.](https://balazscsorba.com/images/blog/spec-driven-development-coding-agents/cover.webp?v=8888070013)

## Das Wichtigste in Kürze

-   Vibe Coding scheitert an echten Codebasen, weil die ungeschriebenen Regeln genau die sind, die der Agent falsch macht. Schreib die Absicht auf, bevor der Agent Code schreibt.
-   Eine brauchbare Spec beschreibt das Verhalten als prüfbare Akzeptanzkriterien, nennt, was nicht zum Umfang gehört, und endet mit einem Check, der beweist, dass das Feature funktioniert.
-   Bestätige den Plan, bevor es Änderungen gibt: Dateien, Schnittstellen, Reihenfolge der Arbeit und Risiken. Dort lässt sich ein falscher Entwurf am günstigsten abfangen.
-   Prüfe, was jedes Tool behält. Spec Kit und Kiro speichern Spec-Dateien, während der Plan-Modus in Claude Code und Cline nur einen schreibgeschützten Planungsschritt bietet, keine dauerhafte Spec.
-   Spec-Tokens sind günstig, Prüfzeit und Aufmerksamkeit nicht. Passe den Prozess an die Änderung an und verzichte auf den Plan bei einem Diff, den du in einem Satz beschreiben kannst.
-   Bewerte das Ergebnis an Nacharbeit und Prüfzeit, nicht daran, wie schnell der erste Entwurf da war. Die Messungen von METR zeigen, wie unzuverlässig dieses Gefühl ist.

Auf dieser Seite

1.  [Warum Vibe Coding an echten Codebasen scheitert](https://balazscsorba.com/#why-vibe-coding-breaks)
2.  [Der Ablauf: Spec, Plan, Tasks, Verifikation](https://balazscsorba.com/#the-workflow)
3.  [Eine Spec mit Akzeptanzkriterien](https://balazscsorba.com/#spec-template)
4.  [Die Plan-Datei und die Task-Checkliste](https://balazscsorba.com/#plan-and-tasks)
5.  [Was die Werkzeuge tatsächlich bieten](https://balazscsorba.com/#tooling)
6.  [Wie Specs die Ausgabe des Agenten prüfbar und testbar machen](https://balazscsorba.com/#reviewable-and-testable)
7.  [Kosten und Zeit: wann sich die Spec lohnt](https://balazscsorba.com/#cost-and-time)
8.  [Wo Spec-driven Development an Grenzen stößt](https://balazscsorba.com/#where-it-falls-short)
9.  [Was ich zuerst tun würde](https://balazscsorba.com/#first-steps)
10.  [Quellen](https://balazscsorba.com/#sources)

Diesen Artikel anhören

0:000:00

Vibe Coding funktioniert, bis eine Codebasis eine Geschichte hat. Einen Prototyp kann man daran messen, ob er läuft. Ein Produktionsservice lässt sich so nicht beurteilen, weil der Agent die ungeschriebenen Regeln nicht kennt: die Retry-Regel, auf die sich das Zahlungsteam geeinigt hat, das Flag, das einen alten Import schützt, die Abfrage, die unter einem Timeout bleiben muss. Er füllt diese Lücken mit plausiblen Vermutungen, und du findest sie im Review, wenn der Code schon existiert. Die Abhilfe ist, die Absicht zuerst aufzuschreiben: eine Spec mit prüfbaren Akzeptanzkriterien, einen Plan, den du freigibst, und eine Task-Liste, die der Agent abarbeitet und abhakt, mit einem Nachweis für jedes Häkchen. Das ist Spec-driven Development, und ich würde es für jede Änderung verwenden, die mehr als ein Modul berührt.

Andrej Karpathy hat Vibe Coding im Februar 2025 geprägt: Software entsteht, indem man einem Modell beschreibt, was man will, und das Ergebnis ohne gründliche Prüfung übernimmt. Für ein Wochenendtool ist das in Ordnung. Es wird teuer, wenn diese Gewohnheit auf eine Codebasis mit Konventionen, gemeinsamen Modulen und zahlenden Kunden trifft, denn dann übernimmt das Review die eigentliche Arbeit, und niemand hat festgelegt, was es prüfen soll.

## Warum Vibe Coding an echten Codebasen scheitert

Vier Fehlermuster kehren immer wieder. Sie haben eine gemeinsame Ursache: Der Agent arbeitet aus einem Prompt, das Team aus einem Verständnis, das nie aufgeschrieben wurde.

-   **Erfundene Anforderungen.** Der Agent füllt Lücken mit plausiblem Verhalten, etwa einem neuen Standardwert oder einer Fehlermeldung, auf die sich niemand geeinigt hat. Entschieden hat das trotzdem niemand.
-   **Konventions-Drift.** Jede Änderung ist für sich genommen korrekt und ignoriert die Muster, auf die sich der Rest des Codes stützt.
-   **Undefiniertes Fertig.** Anthropics Hinweise zu Claude Code sagen: Ohne einen Check, den der Agent ausführen kann, ist „sieht fertig aus“ das einzige Signal, das vorliegt.
-   **Teures Review.** Ein großer, in einem Durchgang geschriebener Diff zwingt den Reviewer, die Absicht aus dem Code zu rekonstruieren.

Die gemessenen Kosten sind nicht die, mit denen die meisten rechnen. Im Juli 2025 ließ METR 246 echte Issues aus großen Open-Source-Repositories zufällig mit oder ohne KI-Werkzeuge bearbeiten, meist mit Cursor Pro und Claude 3.5 oder 3.7 Sonnet, bei 16 erfahrenen Entwicklern. Vor der Studie erwarteten sie, dank KI 24 % schneller zu sein. Danach glaubten sie immer noch, 20 % schneller geworden zu sein. Gemessen wurden 19 % längere Bearbeitungszeiten, wenn KI erlaubt war.

**Die Zahl von 2025 neben METRs Update lesen**

METR sagt, dass seine Ergebnisse veraltet sind, und verweist auf eine Nachfolgeuntersuchung vom Februar 2026 mit 57 Entwicklern und mehr als 800 Aufgaben. Die dortigen Schätzungen haben Konfidenzintervalle, die die Null einschließen, und METR nennt die neuen Daten „ein unzuverlässiges Signal“. Für mich geht es dabei um Messung: Das gefühlte Tempo ist ein schlechtes Messinstrument.

## Der Ablauf: Spec, Plan, Tasks, Verifikation

Der Ablauf hat fünf Stufen, und jede erzeugt ein Artefakt, das ein Mensch lesen kann, bevor die nächste Stufe beginnt. Der Papierkram ist nicht der Sinn der Sache. Jede Freigabe ist eine günstige Stelle, den Agenten anzuhalten, und alles zwischen zwei Freigaben ist Arbeit des Agenten.

Die Freigaben liegen unter Spec, Plan und Verifikation. Eine kurze Spec oder ein kurzer Plan lässt sich günstig korrigieren, ein gemergter Change nicht.

-   **Spec.** Das Problem, das gewünschte Verhalten, die Nicht-Ziele und die Akzeptanzkriterien. Ein Mensch gibt sie frei.
-   **Plan.** Die Dateien und Schnittstellen, die sich ändern, die Reihenfolge der Arbeit, die Risiken und was nicht dazugehört. Ein Mensch gibt ihn frei, denn ein falsches Design fällt hier am günstigsten auf.
-   **Tasks.** Eine Checkliste aus kleinen Schritten, jeder mit eigenem Check.
-   **Umsetzung.** Der Agent schreibt Code und Tests für jeweils eine Task und hakt sie erst ab, wenn der Check besteht.
-   **Verifikation.** Jedes Kriterium ist einem Test, einem Befehl oder einer manuellen Prüfung zugeordnet, und der Nachweis hängt an der Änderung. Ein Mensch prüft diesen Nachweis, nicht den Diff allein.

Anthropics Best-Practice-Leitfaden für Claude Code beschreibt dieselbe Reihenfolge: erkunden, planen, umsetzen, committen. Planen ist laut Leitfaden am nützlichsten, wenn du dir beim Ansatz nicht sicher bist, wenn die Änderung mehrere Dateien betrifft oder wenn du den Code nicht kennst. Und wenn du den Diff in einem Satz beschreiben kannst, lass den Plan weg. Beiden Teilen stimme ich zu.

## Eine Spec mit Akzeptanzkriterien

Eine Spec ist kurz. Wenn sie über ein paar hundert Wörter hinausgeht, beschreibt sie wahrscheinlich die Implementierung, und die gehört in den Plan. Am wichtigsten sind die Akzeptanzkriterien, und ich würde mit EARS beginnen, dem Easy Approach to Requirements Syntax. Alistair Mavin und Kollegen bei Rolls-Royce haben ihn entwickelt, als sie Lufttüchtigkeitsregeln für das Steuerungssystem eines Strahltriebwerks analysierten, veröffentlicht wurde er 2009 zum ersten Mal. Jede Anforderung hat eine von wenigen Formen: WHEN für Ereignisse, WHILE für Zustände, IF und THEN für unerwünschte Situationen und WHERE für optionale Funktionen.

```
# Spec: cart login prompt and payment safety (example)

## Problem
Logged-out visitors reach checkout without learning that an account unlocks the B2B price list. A timeout on the payment call sometimes leads to a second order.

## Behaviour
What the shop must do, from the user's point of view.

## Non-goals
- No change to how price lists are modelled
- No redesign of the cart layout

## Acceptance criteria
- AC-1: WHEN a logged-out visitor opens the cart, the system SHALL show a login prompt above the checkout button.
- AC-2: WHILE the price cache is older than 15 minutes, the system SHALL refetch prices before it shows totals.
- AC-3: IF the payment call times out, THEN the system SHALL keep the order pending and SHALL NOT submit a second charge.
- AC-4: WHERE the account has a negotiated price list, the system SHALL show that list instead of the public price.

## Verification
- AC-1 -> tests/cart/login-prompt.spec.ts (e2e)
- AC-2 -> tests/pricing/cache-refetch.test.ts (unit, fake clock)
- AC-3 -> tests/checkout/timeout.spec.ts (e2e) and a payment unit test
- AC-4 -> tests/pricing/negotiated.test.ts (unit)
Done when every line above passes in CI and the evidence is attached to the change.
```

Die Kriterien in diesem Beispiel sind für einen B2B-Shop erfunden. Entscheidend ist die Form: ein Satz mit einem Auslöser oder Zustand, aus dem sich ein Test ableiten lässt, und eine ID, auf die Plan und Nachweis verweisen können. Die IF-THEN-Zeile ist am wichtigsten, weil sie vor einer doppelten Belastung schützt. Genau so einen Fall übersieht ein Agent, wenn du ihn nicht aufschreibst.

## Die Plan-Datei und die Task-Checkliste

Der Plan beantwortet das Wie, und er sollte kurz genug sein, um ihn in wenigen Minuten zu prüfen. Anthropics Leitfaden beschreibt die nützlichsten Specs als solche, die die beteiligten Dateien und Schnittstellen nennen, festhalten, was nicht zum Umfang gehört, und mit einem End-to-End-Check enden, der beweist, dass das Feature funktioniert. Der Plan sollte außerdem die bekannten Risiken und die Reihenfolge der Arbeit nennen. Das riskanteste Stück baust du zuerst, solange sich das Design noch ändern kann.

```
# Plan: cart login prompt and payment safety

## Files that change
- src/cart/CartPage.vue: login prompt for logged-out visitors (AC-1)
- src/pricing/priceCache.ts: refetch after 15 minutes (AC-2)
- src/pricing/negotiated.ts: negotiated list lookup (AC-4)
- src/checkout/payment.ts: idempotency key, timeout keeps the order pending (AC-3)

## Interfaces
- payment.charge() gains an idempotencyKey argument; both callers are updated
- priceCache.get() keeps its signature and also returns fetchedAt

## Order of work
1. Idempotency key and timeout path (riskiest, built first)
2. Negotiated price lookup
3. Price cache refetch
4. Login prompt (UI, last)

## Risks
- A retry after a timeout could charge twice (covered by AC-3)

## Out of scope
- Changing how price lists are stored
```

Die Task-Liste macht die Arbeit des Agenten sichtbar. Jede Task ist klein genug, dass ihr Check aus einem Grund scheitern kann, und sie nennt das Kriterium, dem sie dient. Ein Häkchen ohne Nachweis ist nur eine Behauptung, und Behauptungen sind das, wovon Vibe Coding lebt. Dasselbe Prinzip steckt hinter den Guides und Sensoren in meinem [Harness-Engineering-Artikel](https://balazscsorba.com/de/blog/harness-engineering-coding-agents).

```
# Tasks: cart login prompt and payment safety

- [x] T1 Idempotency key on payment.charge() (AC-3)
      check: unit test 'retry after timeout does not charge twice' passes
- [x] T2 Timeout path keeps the order pending (AC-3)
      check: e2e 'payment timeout' passes
- [ ] T3 Negotiated price lookup (AC-4)
      check: unit test 'account sees negotiated list' passes
- [ ] T4 Price cache refetch after 15 minutes (AC-2)
      check: unit test with fake clock passes
- [ ] T5 Login prompt for logged-out visitors (AC-1)
      check: e2e 'logged-out cart' passes
- [ ] T6 Full suite green; attach output and map AC-1 to AC-4 to tests
```

## Was die Werkzeuge tatsächlich bieten

Die Werkzeuge unterscheiden sich weniger im Ablauf als darin, wo die Spec liegt und was die Freigabe erzwingt. Die Tabelle zeigt, was ich im Oktober 2026 in der offiziellen Dokumentation bestätigen konnte.

Tool

Was es speichert

Wo die menschliche Freigabe liegt

Vorbehalt

GitHub Spec Kit

Chatbefehle für Constitution, Specify, Plan, Tasks, Implement und Converge, dazu ein Spec-Ordner pro Feature

Chatschritte; die Constitution verlangt, dass Tests vor der Implementierung freigegeben werden

Viel Papierkram, wie Böckeler festgestellt hat

Kiro-Specs

requirements.md (oder bugfix.md), design.md und tasks.md je Spec

Quick Spec erzeugt alle drei Dateien in einem Durchgang ohne Freigabeschritte

Aufwand, den ein kleiner Bugfix nicht braucht

Claude Code Plan-Modus

Der Plan in der Sitzung; Strg+G öffnet ihn im Editor

Du gibst den Plan frei oder drückst Umschalt+Tab, um den Modus zu verlassen

Schreibgeschützte Planung, keine dauerhafte Spec

Cline Plan und Act

Der Plan bleibt im Chat, außer du bittest um eine Markdown-Zusammenfassung

Der Plan-Modus kann keine Dateien ändern und keine Befehle ausführen; der Act-Modus kann es

Für den Moduswechsel ist keine Freigabeeinstellung beschrieben

Codex /plan

In OpenAIs Befehlsreferenz als „Toggle plan mode for multi-step planning“ gelistet

In den Seiten, die ich öffnen konnte, nicht beschrieben

Schreibschutz und Speicherung nicht verifiziert, deshalb verlasse ich mich nicht darauf

Zwei Zeilen dieser Tabelle zählen mehr als die anderen. Ein Plan-Modus ist ein Modus, keine Spec: Er verhindert, dass der Agent während des Nachdenkens editiert, was wertvoll ist, aber er gibt dir kein dauerhaftes Artefakt, das du prüfen, vergleichen oder testen kannst. Die dateibasierten Werkzeuge verschieben die Kosten in den Review, darauf komme ich unten zurück.

Kiros Einführung sagt, dass seine User Stories EARS-Akzeptanzkriterien tragen, also die Form, die ich weiter unten empfehle. Entscheidend ist eine feste Satzform, aus der sich ein Test ableiten lässt. Spec Kit führt seine Schritte im Chat des Agenten aus, die Einrichtung läuft im Terminal:

```
uv tool install specify-cli
specify init my-project --integration copilot
cd my-project
```

Danach führst du im Chat /speckit-constitution einmal pro Projekt aus und /speckit-specify, /speckit-plan, /speckit-tasks und /speckit-implement für jedes Feature. Die README nennt Python 3.11 oder neuer, uv und einen unterstützten KI-Coding-Agenten als Voraussetzungen, und ihre Beispiele verwenden GitHub Copilot. Im Methodik-Dokument verlangt der Artikel zu testgetriebener Entwicklung in der Constitution, dass Tests vor der Implementierung freigegeben werden.

## Wie Specs die Ausgabe des Agenten prüfbar und testbar machen

Eine Spec verändert, was der Reviewer tut. Ohne Spec rekonstruiert er die Absicht aus dem Diff. Mit Spec stellt er vier konkrete Fragen: Hat jedes Kriterium einen Check, der scheitern kann? Gibt es einen Nachweis, dass jeder Check besteht? Hat sich etwas außerhalb des Umfangs geändert? Und entspricht der Code noch den Risiken, die der Plan benannt hat? Jedes Kriterium zeigt auf eine Task, jede Task auf einen Test, und jeder Test hinterlässt einen Nachweis.

Ein Kriterium ohne Test oder ein Test ohne Nachweis ist eine Lücke, die der Reviewer melden sollte.

Anthropics Leitfaden sagt dasselbe aus Sicht des Agenten. Gib ihm einen Check, den er ausführen kann, etwa Tests, einen Build oder einen Screenshot zum Vergleich, und verlange Nachweise statt Behauptungen: die Testausgabe, den Befehl, den er ausgeführt hat, und was dieser zurückgab. Der Leitfaden schlägt außerdem eine zweite Meinung vor, einen frischen Subagenten, der den Diff gegen den Plan prüft.

**Einen frischen Reviewer den Diff gegen den Plan prüfen lassen**

Bitte einen Subagenten in einem frischen Kontext zu prüfen, ob jede geplante Anforderung umgesetzt ist, ob die genannten Grenzfälle Tests haben und ob sich nichts außerhalb des Umfangs der Task geändert hat. Sag ihm, dass er nur Lücken melden soll, die die Korrektheit oder die genannten Anforderungen betreffen, denn ein Reviewer, der nach Lücken suchen soll, meldet auch dann welche, wenn die Arbeit in Ordnung ist.

Von Agenten geschriebene Pull Requests machen das dringlicher. Mein Artikel über den [KI-Code-Review-Engpass](https://balazscsorba.com/de/blog/ai-generated-pr-review-bottleneck) behandelt, was passiert, wenn die Review-Warteschlange vollläuft, und ein evidenzbasiertes Review ist eine Möglichkeit, sie in Bewegung zu halten.

Halte Beispiele in Specs synthetisch. Specs und Pläne werden committet, geprüft und oft als Kontext an ein Modell geschickt. Ein echter Kundenname in einem Beispiel wird damit zu personenbezogenen Daten, die ein Dritter verarbeitet. Wenn die DSGVO greift, finde heraus, wo dein Agent-Anbieter diesen Kontext verarbeitet und wie lange er gespeichert wird, und prüfe, ob dein Auftragsverarbeitungsvertrag das abdeckt.

## Kosten und Zeit: wann sich die Spec lohnt

Die erste Kostenposition ist menschliche Zeit, keine Tokens. Eine Spec und einen Plan zu schreiben und zu prüfen kostet echte Zeit, und das ist der Preis des Ansatzes. Ich habe keine gemessene Zahl dafür, was er spart, und Herstellerzahlen verdienen dieselbe Skepsis wie die METR-Zahlen. Die Token-Seite ist klein und leicht nachzurechnen.

Zu Anthropics aktuellen Preisen kostet eine Spec von etwa 6.000 Tokens, die der Agent bei jedem von 40 Aufrufen liest, auf Claude Sonnet 5.5 ohne Cache etwa 48 Cent, bei 2 Dollar pro Million Input-Tokens. Mit dem 5-Minuten-Prompt-Cache kostet der erste Schreibvorgang 2,50 Dollar pro Million und jeder weitere Lesevorgang 0,10 Dollar pro Million. Dieselben 40 Aufrufe kommen so auf etwa 4 Cent, wenn sie innerhalb des Cache-Fensters eintreffen. Das sind meine eigenen Berechnungen auf Basis der offiziellen Preisseite. Sie lassen den Code, den der Agent liest, und alle Output-Tokens weg, zeigen also den Anteil der Spec an der Rechnung, nicht die Rechnung selbst.

Zwei Vorbehalte gelten. Der neuere Tokenizer, den Claude 4.7 und neuer nutzen, erzeugt für denselben Text etwa 30 % mehr Tokens, deshalb zähle die Spec in Tokens, nicht in Wörtern. Wichtiger ist jedoch die Aufmerksamkeit. Anthropics Leitfaden sagt, dass die Leistung nachlässt, wenn sich das Kontextfenster füllt, und dass das Modell frühere Anweisungen vergessen kann. Halte die Spec auf Kriterien, Randbedingungen und Nicht-Ziele, und lass die Tests die Details tragen.

Änderung

Vorgehen

Warum

Ein Tippfehler, eine Logzeile oder ein Umbenennen

Direkt prompten, ohne Plan

Der ganze Diff passt in einen Satz

Ein Bug mit bekannter Ursache

Erst ein fehlschlagender Test, dann der Fix

Der fehlschlagende Test ist die kleinste nützliche Spec

Ein Feature innerhalb eines Moduls

Kurzer Plan im Plan-Modus, am Ende geprüft

Das Review ist günstig, und die Planung fängt trotzdem einen falschen Ansatz ab

Eine Änderung über mehrere Module oder ein riskanter Pfad wie Zahlung oder Auth

Volle Spec, Plan, Tasks und Nachweise

Nacharbeit kostet mehr als der Papierkram

Code, den andere monatelang erweitern

Eine Spec, die als Dokumentation gepflegt wird

Eine veraltete Spec führt mehr in die Irre als gar keine

Böckeler fand, dass Spec Kit bei einem mittelgroßen Feature „für die Größe des Problems wie Overkill“ wirkte, und sie argumentierte, ein brauchbares Werkzeug müsse mehrere Arbeitsgrößen unterstützen. Der Prozess sollte sich nach der Größe der Änderung richten, nicht nach dem Tool, das du schon hast.

## Wo Spec-driven Development an Grenzen stößt

-   **Papierkram ohne Review.** Böckeler stellte fest, dass Spec Kit „eine Menge Markdown-Dateien zum Prüfen“ erzeugt, und sie prüft lieber Code als diese Dateien. Liest niemand die Spec, ist sie Theater.
-   **Specs, die veralten.** Böckeler unterscheidet Spec-first, Spec-anchored (die Spec bleibt bestehen und pflegt das Feature) und Spec-as-source. Zwei der drei Tools, die sie prüfte, sind Spec-first, und viele Ansätze bleiben unklar darin, wie die Spec über die Zeit aktuell gehalten wird.
-   **Überkomplizierung.** Thoughtworks setzte Spec-driven Development im November 2025 in den Ring Assess und hielt fest, die Abläufe blieben „aufwendig und meinungsstark“. Die Firma warnte, dass wir „vielleicht eine bittere Lektion neu lernen“.

Eine Spec macht den Agenten nicht richtig. Sie macht Fehler früher sichtbar und gibt dem Reviewer etwas zum Prüfen. Böckeler sah auch diese Grenze: In Tessl liefert die wiederholte Codeerzeugung aus derselben Spec nicht dasselbe Ergebnis, es gibt also Nicht-Determinismus. Die ehrliche Zusammenfassung lautet: Spec-driven Development ist Disziplin für die Teile einer Änderung, die schiefgehen können, und Overhead für den Rest.

## Was ich zuerst tun würde

Dafür brauchst du kein bestimmtes Tool. Eine Markdown-Datei, eine Checkliste und eine Testsuite reichen für den Anfang. Mein Artikel über [Coding-Agent-Skills](https://balazscsorba.com/de/blog/coding-agent-skills-workflow) zeigt dieselbe Disziplin an einem Bug, vom Report bis zum Pull Request, und meine Notiz zu [Human in the Loop bei Agenten](https://balazscsorba.com/de/blog/human-in-the-loop-ai-agents) beschreibt, wo die Freigabepunkte hingehören.

1.  Wähle diese Woche eine Änderung, die zwei oder mehr Module berührt, und schreibe ihre Spec mit Akzeptanzkriterien, bevor du den Agenten öffnest.
2.  Formuliere jedes Kriterium als einen Satz in fester Form, etwa EARS, und gib ihm eine ID, auf die Plan und Tasks verweisen können.
3.  Bitte um einen Plan, lies ihn zehn Minuten lang und ändere die Dateiliste und die Reihenfolge der Arbeit, bevor Code entsteht.
4.  Mach jeden Task-Haken von einem Nachweis in der Änderung abhängig: einem Testnamen, einem Befehl mit seinem Exit-Code oder einem Screenshot.
5.  Lösche die Teile der Spec, die der Code nicht mehr abbildet, statt sie driften zu lassen.
6.  Bewerte das Ergebnis an Nacharbeit und Prüfzeit, nicht daran, wie schnell der erste Entwurf da war. Die METR-Ergebnisse zeigen, wie unzuverlässig dieses Gefühl ist.

## Quellen

1.  [Birgitta Böckeler: Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl (martinfowler.com, 15 October 2025)](https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html)
2.  [GitHub Spec Kit: README](https://github.com/github/spec-kit)
3.  [GitHub Spec Kit: spec-driven.md methodology](https://github.com/github/spec-kit/blob/main/spec-driven.md)
4.  [Kiro documentation: specs](https://kiro.dev/docs/specs/)
5.  [Kiro: Introducing Kiro](https://kiro.dev/blog/introducing-kiro/)
6.  [Alistair Mavin: EARS, the Easy Approach to Requirements Syntax](https://alistairmavin.com/ears/)
7.  [Anthropic: Best practices for Claude Code](https://code.claude.com/docs/en/best-practices)
8.  [Cline documentation: Plan and Act](https://docs.cline.bot/features/plan-and-act)
9.  [OpenAI: Codex slash command reference](https://learn.chatgpt.com/docs/reference/slash-commands)
10.  [METR: early-2025 AI and experienced open-source developer productivity (July 2025)](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/)
11.  [METR: We are changing our developer productivity experiment design (February 2026)](https://metr.org/blog/2026-02-24-uplift-update/)
12.  [Thoughtworks Technology Radar: Spec-driven development](https://www.thoughtworks.com/radar/techniques/spec-driven-development)
13.  [Wikipedia: Vibe coding](https://en.wikipedia.org/wiki/Vibe_coding)
14.  [Anthropic: Claude API pricing](https://platform.claude.com/docs/en/about-claude/pricing)
15.  [Anthropic: Prompt caching](https://platform.claude.com/docs/en/build-with-claude/prompt-caching)

## Häufige Fragen

Was ist Spec-driven Development?

Du schreibst auf, was ein Feature leisten muss, wie es gebaut wird und wie du es prüfst, und erst dann lässt du einen Coding-Agenten Code gegen diese Dokumente schreiben. Spec, Plan und Task-Liste sind Dateien, die du prüfen, vergleichen und testen kannst, statt eines Chatverlaufs.

Ist Spec-driven Development nur Vibe Coding mit mehr Papierkram?

Mehr Papierkram, ja, aber die Prüfung verlagert sich. Vibe Coding kann Ergebnisse ohne gründliche Prüfung übernehmen. Spec-driven Arbeit legt die Prüfung auf Spec, Plan und Nachweise. Für dasselbe Feature kostet das mehr, deshalb lohnt es sich bei Änderungen über mehrere Dateien oder an riskanten Stellen, nicht bei kleinen Fixes.

Welches Tool soll ich nehmen?

Das, mit dem dein Team dauerhaft arbeitet. Spec Kit führt Spec-, Plan-, Task- und Implementierungsschritte als Chatbefehle aus und legt die Artefakte pro Feature in einem Ordner ab. Kiro hält Anforderungen, Design und Tasks als Dateien je Spec. Der Plan-Modus in Claude Code und Cline gibt dir einen schreibgeschützten Planungsschritt, der hilft, aber er pflegt keine Spec für dich.

Wie helfen Akzeptanzkriterien beim Code-Review?

Jedes Kriterium wird zu einer Prüfung, die der Reviewer ansehen kann. Er fragt, ob jedes Kriterium einen Nachweis hat, ob eine Prüfung überhaupt scheitern kann und ob sich etwas außerhalb des Umfangs geändert hat. Das ist eine kleinere und verlässlichere Aufgabe als ein großer Diff, bei dem die beabsichtigte Änderung unbekannt ist.

Geschrieben von Balázs Csorba

Senior Fullstack & AI Engineer in der Steiermark – über 10 Jahre Vue, Nuxt, Node.js und PHP, heute baue ich Werkzeuge für KI-Agenten.

[KI-Entwicklung & MCP-Server →](https://balazscsorba.com/de/expertise/ai-engineer)[Über mich →](https://balazscsorba.com/de/about)

## Weitere Artikel

-   [Ein Senior mit Coding-Agenten gegen ein Team: was die Belege sagen](https://balazscsorba.com/de/blog/ai-assisted-development-economics)
-   [MCP-Tool-Design: Lehren aus einem Jira-Server mit 20 Tools](https://balazscsorba.com/de/blog/mcp-tool-design-lessons-jira-server)
-   [Memory für KI-Agenten entwerfen: Ebenen, Schreibregeln, Poisoning und DSGVO](https://balazscsorba.com/de/blog/ai-agent-memory-design)
-   [Harness Engineering: Guides und Sensors, die Agent-PRs mergebar machen](https://balazscsorba.com/de/blog/harness-engineering-coding-agents)

## Klingt nach dem, was du suchst?

Erzähl mir von deinem Projekt oder deiner Stelle – ich freue mich, von dir zu hören.

[Gespräch buchen](mailto:contact@balazscsorba.com) [Auf LinkedIn vernetzen](https://www.linkedin.com/in/balazs-csorba)