2026-08-17

Spec-Driven Development: die Spezifikation ist die Quelle, nicht der Chatverlauf

„Vibe Coding” hat einen Namen für ein Problem gegeben, das jeder kennt, der KI-Assistenten für grössere Änderungen genutzt hat: Code, der plausibel aussieht und trotzdem vom eigentlichen Ziel abweicht, je länger ein Gespräch läuft. Als Gegenbewegung hat sich in der Branche der Begriff Spec-Driven Development etabliert — Werkzeuge wie GitHub Spec Kit oder AWS Kiro machen daraus ein Muster mit Namen: nicht der Prompt-Verlauf ist die Quelle der Wahrheit, sondern eine versionierte Spezifikation, aus der Plan und Code erst abgeleitet werden.

Die Umkehrung, um die es geht

Der Kernunterschied ist eine Reihenfolge. Bei einem klassischen Chat-Verlauf entsteht die Spezifikation nachträglich — man kann sie aus dem Verlauf rekonstruieren, aber sie stand nie fest, bevor der erste Code entstand. Spec-Driven Development dreht das um: Erst wird beschrieben, was gebaut werden soll, dann wird das geprüft, dann erst — auf Basis der geprüften Beschreibung — entsteht eine Architektur, und erst danach Code. Jeder Schritt hat eine feste Grundlage, die der vorige Schritt gelegt hat, statt eine bewegliche, die sich mit jeder neuen Prompt-Runde verschiebt.

Wo diese Reihenfolge bei Anvil Coder schon steckt

Anvil Coder folgt genau dieser Reihenfolge, nur unter anderen Namen. In der REQUIREMENTS-Phase entsteht aus der Aufgabenbeschreibung ein geprüftes Anforderungsbild — offene Punkte werden dabei nicht stillschweigend entschieden, sondern als Annahme festgehalten und bleiben im Lauf sichtbar. Das ist die Spezifikation, nicht ein Nebenprodukt des späteren Codes.

Erst danach folgt ARCHITECTURE: Struktur, Schnittstellen und Abhängigkeiten werden festgelegt, bevor die erste Zeile Code entsteht. Diese Reihenfolge ist keine Formsache — sie ist die Voraussetzung dafür, dass die eigentliche Umsetzung überhaupt in kleine, unabhängig prüfbare Schritte zerlegt werden kann: ein TaskSlice lässt sich erst dann sinnvoll gegen eine feste Schnittstelle bauen, wenn diese Schnittstelle schon steht.

Die Spezifikation bleibt nicht folgenlos

Der Unterschied zu einer Spezifikation, die nur als Dokument existiert, liegt am Ende der Kette: jeder TaskSlice hinterlässt seinen eigenen Commit, und ein Ergebnis kommt als Entwurf eines Pull-Requests an — auf den Hauptzweig führt ihn immer ein Mensch zusammen. Wer nachvollziehen will, ob ein Schritt der Spezifikation entsprach, muss dafür keinen Chatverlauf durchsuchen; die Spur liegt im Repository selbst.

Was eine Spezifikation nicht ersetzt

Eine geprüfte Spezifikation verhindert Drift während der Umsetzung — sie verhindert nicht, dass die Spezifikation selbst falsch war. Ob eine Anforderung den eigentlichen Bedarf trifft, bleibt eine Entscheidung, die vor dem ersten Lauf getroffen wird, nicht während oder danach. Spec-Driven Development verschiebt das Risiko nicht weg von diesem Punkt — es macht nur sichtbar, wo genau ein Ergebnis von seiner Grundlage abweicht, statt es in einem langen Gespräch zu verstecken.