Spec-Driven Development ausprobiert
- Matt
Wenn der Agent zu schnell ist
Seit ich öfter mit Agenten arbeite (siehe Agent Harness ausprobiert), kenne ich das Muster: Ich beschreibe eine Aufgabe in zwei Sätzen, der Agent legt los, und nach wenigen Minuten liegt ein Pull Request da, der technisch sauber ist, aber am eigentlichen Problem vorbeigeht. Nicht weil das Modell schlecht programmiert, sondern weil die zwei Sätze mehrdeutig waren und die falsche Lesart die war, die sich am schnellsten umsetzen ließ.
Spec-Driven Development soll genau das verhindern: erst die Spezifikation aufschreiben, dann planen, dann Aufgaben ableiten, und erst danach Code schreiben lassen. Ich habe mir dafür Spec Kit von GitHub angesehen, das Werkzeug, das der Idee gerade den meisten Schub gibt.
Der Ablauf in sechs Kommandos
Spec Kit installiert sich als CLI (specify-cli, per uv tool install oder pipx) und legt in einem Projekt einen .specify-Ordner mit Vorlagen an, dazu passende Slash-Commands für den jeweiligen Agenten. Der Kern ist eine Kette aus Markdown-Dateien: /speckit.constitution legt einmalig Grundsätze für das Projekt fest, an die sich jede spätere Phase halten muss. /speckit.specify beschreibt, was eine Funktion tun soll, als Anforderungen und User Storys, ausdrücklich ohne Technologieentscheidungen. /speckit.clarify fragt gezielt die noch offenen Stellen der Spezifikation ab. /speckit.plan übersetzt das Ganze in eine technische Umsetzung mit konkretem Stack, /speckit.tasks bricht den Plan in Arbeitsschritte herunter, und erst /speckit.implement schreibt Code.
Jede Phase liest die Datei der vorherigen Phase und schreibt eine neue. Das wirkt nach viel Aufwand für eine einzelne Funktion, ist aber genau der Punkt: Die Spezifikation lässt sich lesen und korrigieren, bevor überhaupt eine Zeile Code existiert.
Wo es half und wo nicht
Für ein kleineres Feature in einem bestehenden Projekt habe ich den vollen Ablauf durchgespielt. Bei specify init --ai claude blieb ich zunächst hängen: Claude Code gehört zwar zu den unterstützten Integrationen, aber in mehreren offenen Issues im Projekt-Repository wird genau das gemeldet, was ich auch sah – die generierte CLAUDE.md blieb leer, weil das passende Vorlagen-Asset nicht aufgelöst wurde. Ein Lauf mit --ai copilot funktionierte ohne Umwege.
Danach half die Kette tatsächlich: Weil die Spezifikation als Datei im Repository liegt, konnte ich sie vor dem Planen noch einmal umformulieren, ohne dass der Agent das schon in Code gegossen hatte. Für eine Notiz oder einen Bugfix von einer Zeile sind sechs Kommandos und vier Markdown-Dateien dagegen unverhältnismäßig – die Spezifikation wäre aufwendiger als die Änderung selbst.
Was bleibt
Der Ansatz verschiebt das eigentliche Problem eher, als es zu lösen: Man diskutiert nicht mehr mit dem Agenten über falschen Code, sondern über eine falsche Spezifikation. Das ist ein Fortschritt, weil sich Text schneller korrigieren lässt als ein fertiger Pull Request. Das Lesen ersetzt es aber nicht. Wer die generierte spec.md nur überfliegt, bekommt am Ende genauso zuverlässig das Falsche, nur mit mehr Zwischenschritten davor.