KI-Engineering-Teams verabschieden sich von Vibe Coding zugunsten von Specs

Im ersten Quartal 2026 haben mehrere Engineering-Teams, die das vorherige Jahr mit "Vibe Coding" verbracht hatten – also locker einen KI-Agenten prompteten und iterierten, bis etwas funktionierte – leise kehrtgemacht. Der Grund war nicht, dass die Agenten schlechter geworden waren. Sondern dass unstrukturiertes Prompting nicht mehr skalierte, sobald die Agenten mit Änderungen an mehreren Dateien und autonomen Pull Requests betraut wurden. Die Lösung, auf die sich die Teams einigten, ist spec-driven development (SDD): das Schreiben einer strukturierten Spezifikation, bevor ein Agent auch nur eine Zeile Code anfasst, und die Behandlung dieser Spec – nicht des resultierenden Diffs – als Quelle der Wahrheit.

Das ist keine Rückkehr zu Wasserfall-artigen Anforderungsdokumenten, die niemand liest. Es ist eine direkte Reaktion auf eine spezifische Fehlerart: selbstbewusster, plausibel wirkender Code, der leise das falsche Problem löst, weil niemand die Arbeit des Agenten an einer tatsächlichen Definition von "erledigt" festgemacht hat. Mitte 2026 haben alle großen Anbieter von Coding-Agenten – GitHub, AWS, das Claude Code Ecosystem von Anthropic und eine Welle von Open-Source-Frameworks – ihre eigene Version von Spec-First-Workflows ausgeliefert, und das Muster hat sich von "interessantem Experiment" zur Standardpraxis in Produktionsteams entwickelt.

Warum Vibe Coding im großen Maßstab scheitert

Ein einzelner Bugfix in einer Datei oder ein kleines Skript toleriert lockeres Prompting, weil der Schadensradius klein ist und ein Mensch den gesamten Diff in Sekunden überprüft. Funktionen über mehrere Dateien hinweg funktionieren so nicht. Wenn ein Agent beauftragt wird, "Subscription Billing hinzuzufügen", muss er Entscheidungen über Datenbankschema, Fehlerbehandlungskonventionen, Namensmuster und Randfälle treffen, die nie genannt wurden – und er wird sie selbstbewusst treffen, selbst wenn sie falsch sind. Der Fehler zeigt sich nicht als Absturz; er zeigt sich drei Sprints später als architektonische Drift, doppelte Logik und einer Codebasis, die nicht mehr dem mentalen Modell von irgendjemandem entspricht.

Die kommerziellen Belege dafür sind mittlerweile öffentlich. GitHub hat berichtet, dass Teams, die sein Spec Kit Toolkit in internen Projekten einsetzen, Funktionen mit etwa einer Größenordnung weniger "regeneriere von Grund auf"-Zyklen ausliefern als Teams, die mit Ad-hoc-Prompting arbeiten. AWS hat Kundenfälle veröffentlicht, in denen Funktionen, die auf 40 Stunden Engineering-Zeit geschätzt wurden, in weniger als 8 Stunden menschlichem Aufwand ausgeliefert wurden, sobald die Arbeit zuerst als Spec verfasst wurde und der Agent die mechanische Implementierung gegen klare Abnahmekriterien übernahm.

Die Tools, die Specs zum Standard machen

Fünf Frameworks definieren nun die Spec-gesteuerte Landschaft, und sie verfolgen wirklich unterschiedliche Ansätze:

• GitHub Spec Kit – ein Open-Source, MIT-lizenziertes CLI mit mehr als 93.000 GitHub-Sternen (v0.8.7, Mai 2026). Jedes Spec-Kit-Projekt beginnt mit einer "Constitution": einer Markdown-Datei mit unveränderlichen, projektweiten Prinzipien – Teststandards, architektonische Einschränkungen, Namenskonventionen – die über alle Agentensitzungen hinweg als ständiger Vertrag zwischen Entwickler und Agent besteht.
• AWS Kiro – ein VS-Code-Fork, der im Mai 2026 breite globale Verfügbarkeit erreichte und Specs ins Zentrum der IDE stellt. Kiro erzwingt eine strikte Pipeline: requirements.md (User Stories mit Abnahmekriterien in EARS-Notation – "WHEN [Bedingung] THE SYSTEM SHALL [Verhalten]", ein Format, das ursprünglich bei Rolls-Royce für sicherheitskritische Systeme entwickelt wurde) → design.md (Architektur- und Sequenzdiagramme) → tasks.md (diskrete, nachverfolgbare Implementierungsschritte) → Code.
• BMAD-METHOD – ein MIT-lizenziertes Framework (v6.6.0, April 2026; 46.700+ Sterne), das zwölf oder mehr spezialisierte Agenten-Rollen orchestriert – Product Manager, Architect, UX Designer, Developer, QA, Scrum Master –, wobei jeder die Dokumente des vorherigen Agenten liest und eigene produziert, sodass eine nachverfolgbare Kette von der Anforderung zum ausgelieferten Code entsteht.
• Tessl – installiert sich als "Tiles" im Verzeichnis .tessl/ eines Projekts und arbeitet mit jedem MCP-kompatiblen Agenten, einschließlich Claude Code und Cursor. Die Agenten sind angewiesen, zuerst klärende Fragen zu stellen, die Spec zu schreiben, auf explizite Zustimmung des Entwicklers zu warten und erst dann zu implementieren – wobei die Spec als Langzeitspeicher und Audit-Trail im Repository verbleibt, während die App weiterentwickelt wird.
• OpenSpec – die leichtgewichtigste Option: kostenlos, MIT-lizenziert, lebt vollständig im Repository, benötigt weder API-Key noch MCP-Server. Es verwendet optionale Given/When/Then-Szenarien und ein eigenständiges Delta-Tracking-Modell (ADDED / MODIFIED / REMOVED), das speziell für die Weiterentwicklung einer bestehenden Codebasis entwickelt wurde, nicht für Greenfield-Builds.

Die akademische Forschung beginnt, mit der Praxis Schritt zu halten: Eine Process-Taxonomy-Studie von 2026, die Frameworks für KI-Softwareentwicklungs-Agenten verglich, fand heraus, dass der gemeinsame Nenner aller Ansätze die Trennung von "was gebaut werden soll" und "wie es gebaut werden soll" in separate, agentenlesbare Artefakte ist – genau die Disziplin, die Vibe Coding überspringt.

Ein schlechter Prompt vs. eine echte Spec

Der Unterschied lässt sich am besten nebeneinander sehen. Hier ist ein typischer Vibe-Coding-Prompt für eine reale Funktion:

Schlecht: "Fügen Sie eine Möglichkeit für Benutzer hinzu, ihre Daten als CSV-Datei zu exportieren, machen Sie es hübsch."

Einem Agenten mit Schreibzugriff auf mehrere Dateien überlässt dieser Prompt jede echte Entscheidung ungetroffen: welche Felder exportiert werden, wie verschachtelte oder verwandte Daten abgeflacht werden, was bei Exporten mit 500.000 Zeilen passiert, ob der Endpunkt eine Auth-Begrenzung benötigt, wie der Dateiname und die Kodierung aussehen sollen. Der Agent wird Antworten wählen – und sie bei jeder Neugenerierung anders wählen.

Hier ist dieselbe Funktion als Spec, im EARS-Format, das sowohl Kiro als auch Spec Kit empfehlen:

Gut:

• WHEN a user with an active account clicks "Export Data" THE SYSTEM SHALL generate a CSV containing the columns: id, email, created_at, last_login, subscription_tier.
• WHEN the export contains more than 50,000 rows THE SYSTEM SHALL stream the response instead of buffering it in memory.
• WHEN a user without export permission requests the endpoint THE SYSTEM SHALL return a 403 with an error body matching the existing API error schema.
• THE SYSTEM SHALL name the file export-{userId}-{ISO8601 date}.csv and encode it as UTF-8 with BOM for Excel compatibility.

Nichts davon ist exotisches Engineering – es ist dasselbe Denken, das ein kompetenter Ingenieur in einem Design-Review anstellen würde. Der Unterschied besteht darin, dass es niedergeschrieben wird, bevor der Agent beginnt, sodass der Agent gegen explizite Kriterien implementiert, anstatt sie zu improvisieren, und ein Reviewer den Diff gegen die Spec prüfen kann, anstatt die Absicht aus dem Code zurückzuverfolgen.

Was eine gute Spec enthalten muss

Unabhängig davon, welches Framework ein Team einsetzt, haben die Specs, die in agentengesteuerten Workflows wirklich Bestand haben, eine gemeinsame Form:

• Explizite Scope-Grenzen – was die Funktion NICHT tut, nicht nur was sie tut.
• Testbare Abnahmekriterien – formuliert als WHEN/THEN- oder Given/When/Then-Aussagen, die ein Agent (oder eine Testsuite) mechanisch verifizieren kann, nicht als Prosa, die ein Mensch interpretieren muss.
• Datenform und Randfälle – Schema, Nullability, Größenlimits und was an den Grenzen passiert (leere Eingabe, maximale Eingabe, gleichzeitiger Zugriff).
• Nichtfunktionale Einschränkungen – Performance-Budgets, Auth-/Berechtigungsanforderungen und Fehlerbehandlungskonventionen, die zur bestehenden Codebasis passen.
• Eine persistente "Constitution" oder Steuerungsdatei – die projektweiten Regeln (Teststandards, Architekturmuster, verbotene Abhängigkeiten), die nicht in jeder Spec wiederholt werden sollten.
• Ein explizites Human-Approval-Gate – der Punkt, an dem ein Entwickler die Spec freigibt, bevor der Agent Code generieren darf, nicht danach.

Fazit

Teams, die 2026 KI-Coding-Agenten einsetzen, sollten die Spec – nicht den Prompt – als die Einheit der Engineering-Arbeit betrachten. Konkret: Wählen Sie ein Spec-Framework (OpenSpec für einen niedrigschwelligen Einstieg in eine bestehende Codebasis, Spec Kit oder Kiro, wenn das Team eine erzwungene Requirements-Design-Tasks-Pipeline möchte) und verlangen Sie, dass jede agentenbasierte Aufgabe über mehrere Dateien mit einer schriftlichen Spec mit testbaren Abnahmekriterien beginnt. Führen Sie ein dauerhaftes "Constitution"-Dokument mit den Architektur- und Stilregeln, die für jede Funktion gelten, sodass Specs nur das abdecken müssen, was wirklich neu ist. Und bauen Sie die Review-Gewohnheit darauf auf, den Code gegen die Abnahmekriterien der Spec zu prüfen – nicht den gesamten Diff Zeile für Zeile erneut zu lesen, denn das ist genau der Engpass, den Spec-Driven Development beseitigen soll.