Vibe Coding gegen Spec-Driven Development: gleiches Ergebnis, besserer Code

Ich habe dieselbe Anwendung dreimal mit Claude Code bauen lassen: einmal im Dialog und zweimal nach einer Spezifikation, die der Agent aus meinem Briefing entworfen und ich freigegeben habe. Das Ergebnis war praktisch gleich, der Code nicht. Bei dieser Anwendung mittlerer Komplexität kam ich mit Vibe Coding also genauso weit. Aber nur die Spec-Fassungen sind nach fachlichen Grenzen geschnitten, und das entscheidet, wie gut sich eine Anwendung pflegen und weiterentwickeln lässt. Außerdem habe ich beobachtet, dass der Agent beim Schreiben der Spezifikation nachfragte. Beim Vibe Coding tat er das nicht.

Vibe Coding heißt heute etwas anderes

Den Begriff hat Andrej Karpathy im Februar 2025 geprägt: alle Vorschläge der KI annehmen, die Änderungen nicht mehr lesen, nach seinen Worten brauchbar für Wegwerfprojekte am Wochenende. Ein Dreivierteljahr später war es Wort des Jahres bei Collins. Ein Agent wie Claude Code mit Opus 5.5 schreibt inzwischen eigene Tests und hält sich an die Konventionen eines Projekts.

Ich hatte trotzdem die These, dass Vibe Coding ab einer gewissen Komplexität nicht mehr trägt. Wächst eine Anwendung, wird es für Menschen wie für Agenten schwerer, das Ganze zu überblicken. Begriffe bedeuten an verschiedenen Stellen Verschiedenes, ein „Besuch“ ist für den Empfang etwas anderes als für die Person, die einlädt. Und eine Änderung an einer Stelle bricht etwas an einer anderen. Dafür gibt es Domain-Driven Design. Man zerlegt die Domäne, also das Fachgebiet, um das es geht, in Subdomänen. Mit Bounded Contexts legt man Grenzen fest, innerhalb derer ein Modell und seine Begriffe eindeutig gelten. So lässt sich jeder Teil für sich verstehen und ändern. Meine Vermutung war, dass man einem Agenten diese Zerlegung vorgeben und das Datenmodell formal beschreiben muss. In diese Richtung gehen Werkzeuge für Spec-Driven Development wie GitHubs Spec Kit oder Amazons Kiro: erst die Spezifikation, dann der Code. Ich selbst arbeite seit einigen Wochen nach Anthropics Playbook für einen KI-gestützten Entwicklungszyklus.

Dazu kam ein Beitrag von Karpathy auf X vom 2. Oktober 2026. Er empfahl, sich Antworten von Sprachmodellen in ASD-STE100 geben zu lassen, kurz STE für Simplified Technical English, einer kontrollierten Sprache aus der Wartung von Flugzeugen. Mich interessierte die umgekehrte Richtung: Hilft es, wenn die Anforderungen an den Agenten so geschrieben sind, oder in EARS, der Satzschablone, die Kiro verwendet?

Der Versuch

Gebaut wurde eine Besucheranmeldung, für die eigentlich eine Standardsoftware gekauft werden sollte, als Modul einer internen Plattform: Beschäftigte melden Besucher und Gruppen an, der Empfang sieht, wer erwartet wird. Mittlere Komplexität, kein unternehmenskritisches System.

Die Vibe-Fassung begann mit meinem Briefing, rund eine Seite aus dem Kopf, danach habe ich im Dialog nachgesteuert. Für die anderen beiden entwarf der Agent aus demselben Briefing eine Spezifikation, einmal mit Anforderungen in EARS, einmal in STE. Seine offenen Fragen habe ich beantwortet, Spezifikation und Plan freigegeben und das Ergebnis zwischendurch selbst ausprobiert. Gemessen habe ich mit 24 Abnahmeszenarien, die ein Agent vor dem ersten Bau aus meinem Briefing und meinen Vorüberlegungen geschrieben hatte. Gelesen habe ich sie erst, als die Vibe-Fassung fertig war. 17 ergeben sich aus dem Briefing, 7 nur aus Vorüberlegungen, die keine Fassung zu sehen bekam, etwa eine Notfall-Liste für den Empfang. Ein Agent spielte sie im Browser durch, von den durchgefallenen habe ich Stichproben nachgeprüft. Danach bekamen Vibe und EARS einmal den Prüfbericht zum Nachbessern und zum Schluss eine größere Änderung mit 13 neuen Szenarien. STE habe ich nur bei der ersten Abnahme gemessen.

Die Ergebnisse

	erste Abnahme	nach dem Prüfbericht	Änderung
Vibe	20 von 24	24 von 24	13 von 13, die alten 24 weiter bestanden
Spec mit EARS	19 von 24	24 von 24	13 von 13, die alten 24 weiter bestanden
Spec mit STE	19 von 24	nicht gemessen	nicht gemessen

Abnahmeszenarien je Fassung: aus dem Briefing alle bestanden, aus den Vorüberlegungen nur zwei bis drei von sieben

Den einen Punkt Vorsprung verdankt Vibe einem Grenzfall, den der Messagent als durchgefallen und ich als bestanden gewertet habe. Praktisch ist das ein Unentschieden. Vibe Coding hat bei dieser Anwendung also funktioniert. Der Agent schrieb für das Modul rund 300 Tests und folgte den Konventionen der Plattform.

Am meisten überrascht hat mich das Tempo. Neun meiner Prompts steuerten das Produkt nach, etwa die Löschfrist oder dass die Wache direkt am Empfang startet. Auch in der Spec-Fassung brachte ein Probelauf zwei solche Punkte. Früher habe ich so etwas oft erst im nächsten Sprint-Review gesehen. Hier lagen zwischen zwei Prompts im Schnitt rund elf Minuten, meine Lese- und Denkzeit eingerechnet. Vieles, was in keinem Briefing steht, fällt einem erst auf, wenn man die Anwendung vor sich hat.

Im Code zeigt sich trotzdem ein Unterschied. Die Vibe-Fassung hat rund 6.300 Zeilen und folgt technisch der Vorlage der Plattform. Fachlich ist sie nicht aufgeteilt: Der größte Teil der Fachlogik für acht Funktionsbereiche steckt in einer Datei mit 1.687 Zeilen. Die nächstgrößere Datei dieser Art in der Plattform hat 350. Die EARS-Fassung kommt mit rund 4.300 Zeilen aus, bei etwas weniger Funktionen. Ihre Spezifikation zerlegt die Domäne in Subdomänen, Besuchsanmeldung und Empfang als Kern, Veranstaltungen als unterstützend, Zugang und Personenverzeichnis als generisch, jede mit eigenem Bounded Context. Die neuen Kontexte finden sich im Code als eigene Pakete wieder, auch wenn ihre Grenzen an zwei Stellen umgangen werden. Ein Datenmodell gibt es in der Vibe-Fassung nur als Datenbankschema und als Eingabeformate der Oberfläche; die EARS-Fassung beschreibt Entitäten, Attribute und Regeln ausdrücklich.

Oben die Vibe-Fassung mit ihrer Fachlogik in einer Datei, unten die Spec-Fassung mit einem Paket je Bounded Context

Fehlerfreier ist die EARS-Fassung nicht. Zwei Agenten haben die Fassungen blind begutachtet und in beiden Fehler gefunden, die kein Szenario aufgedeckt hat.

Warum der Schnitt für die Wartung zählt

Dass lose gekoppelte Teile mit hohem inneren Zusammenhang leichter zu ändern sind, ist eines der ältesten Prinzipien der Softwarearchitektur. David Parnas hat den Gedanken dahinter 1972 beschrieben: Ein Modul soll eine Entscheidung verbergen, damit es sich ändern lässt, ohne die anderen anzufassen. Als Kopplung und Kohäsion haben Stevens, Myers und Constantine diese Eigenschaften 1974 bekannt gemacht.

Auch für einen Coding-Agenten zählt der Schnitt. Was er für eine Änderung lesen muss, belegt Platz in seinem Kontextfenster, dem begrenzten Arbeitsgedächtnis des Modells. Soll in der EARS-Fassung etwas an den Veranstaltungen anders werden, kommt er im Prinzip mit einem Paket aus. In der Vibe-Fassung muss er sich in einer Datei mit allen acht Funktionsbereichen zurechtfinden, und jede Erweiterung macht sie größer.

Bei der einen Änderung, die ich gemessen habe, zeigte sich das noch nicht. Beide Fassungen brauchten 3 Prompts, die Spec-Fassung sogar mehr Tokens, weil sie dafür einen ganzen Zyklus mit Dokumenten angelegt hat. Bei dieser Größe überblickt der Agent vermutlich auch die große Datei noch. Für mich ist der Schnitt trotzdem die wichtigste Eigenschaft der Spec-Fassung: Eine Anwendung wächst mit jeder Änderung, und je schlechter sie geschnitten ist, desto teurer wird die nächste.

EARS oder STE machte keinen Unterschied

EARS und STE bestanden bei der ersten Abnahme genau dieselben Szenarien, wie schon in einem kleinen Vorversuch mit einer einfacheren Aufgabe. Eine Spezifikation in freier Sprache habe ich nicht verglichen. Ob die Form der Anforderungen überhaupt eine Rolle spielt, zeigt der Versuch deshalb nicht.

Mit Spec-Driven Development kehrt eine alte Hoffnung zurück: dass ein formales Modell die eigentliche Arbeit ist und der Code daraus folgt. Model Driven Architecture hat das in den Nullerjahren versprochen, und jetzt empfehlen manche Ontologien als Grundlage für Agenten. Durchgesetzt hat sich davon nach meiner Erfahrung wenig, weil das Modell neben dem Code zur zweiten Wahrheit wurde, die niemand pflegte. Pflegen kann es heute der Agent. Wer es liest, ist eine andere Frage. Auch ich habe die Spezifikation nur überschlägig geprüft. In meinem Versuch haben ein guter fachlicher Schnitt und die Fragen geholfen, die das Briefing offenließ. Ein beschriebenes Datenmodell gehört dazu, ein Modell, aus dem Code generiert wird, brauchte es nicht.

Der Agent fragt, wenn er eine Spezifikation schreibt

Von den 7 Punkten, die nur in meinen Vorüberlegungen standen, hatte Vibe 3, die Spec-Fassungen je 2. Die Notfall-Liste gab es nirgends. Gedanken lesen kann auch Opus 5.5 nicht.

Beim Schreiben der Spezifikation hat der Agent dagegen 16 offene Fragen und eine mehrdeutige Stelle in meinem Briefing benannt und zu fast jeder eine Antwort vorgeschlagen. Einiges davon hatte ich nicht bedacht. Er bemerkte etwa, dass mein Briefing offenlässt, ob die Wache die Kontaktdaten des Besuchers oder des Besuchten sehen soll, und fragte, wie lange Besucherdaten aufbewahrt werden. Auch die Vibe-Fassung hat Dinge ergänzt, die ich nicht gesagt hatte. Der Agent hat sie in eine Beschreibung des Moduls geschrieben, gefragt hat er vorher nicht.

Die meisten Vorschläge habe ich übernommen. Anders entschieden habe ich bei der Eindeutigkeit von Gruppennamen und, erst beim Ausprobieren, bei der Aufbewahrungsfrist. Eine der Fragen lautete, ob man Anmeldungen nachträglich bearbeiten können soll. Der Vorschlag war „nicht in diesem Zyklus“, und ich habe zugestimmt. Heute fehlt mir das. Zu einer bestehenden Anmeldung kann ich in keiner Fassung Besucher ergänzen.

Aufgefallen ist mir das erst spät. Die Änderungsanforderung hatte ein Agent vorab für den Versuch geschrieben, und ich kannte sie bis zur Messung nicht. Fachlich geprüft hat sie also niemand. Sie führte Platzzahlen mit Warteliste ein, die es bei uns so nicht gibt. Für den Vergleich bleibt sie fair, am Bedarf ging sie vorbei.

Was die Zahlen nicht sagen

Das ist eine Fallstudie mit je einem Durchgang. Die Spezifikation hat der Agent entworfen, fachlich stützt sie sich nur auf mein Briefing und meine Antworten. Spezifikation, Plan und Szenarien habe ich fachlich nur überschlägig geprüft. Meine These über eine Zerlegung durch Menschen mit Fachwissen ist damit nicht geprüft. Die Spec-Fassungen entstanden nach der Vibe-Fassung, als ich die Domäne und die Abnahmeszenarien schon kannte, und alles lief in einer Woche. Und die Vibe-Fassung hatte mit den Konventionen der Plattform selbst eine Art Spezifikation, zwar nicht für die Fachlichkeit, aber für die Technik. Code und Daten veröffentliche ich nicht, weil die Anwendung intern genutzt wird.

Fazit

Planen und Testen hat der Agent in meinem Versuch weitgehend selbst übernommen. Wichtig bleiben zwei Dinge, der Schnitt der Anwendung und die Antworten auf die fachlichen Fragen. Bei beidem hat die Spezifikation in meinem Versuch geholfen. Sie hat die Domäne in Bounded Contexts zerlegt und offene Fragen zu meinem Briefing sichtbar gemacht. Ob die Anforderungen in EARS oder STE standen, machte keinen Unterschied, und ein Modell, aus dem Code erzeugt wird, brauchte es nicht.