Spec-Driven Development: Wie Sie KI-Coding-Agenten unter Kontrolle halten

Vom Prompt zur Spezifikation: Warum sich das Delivery-Paradigma verschiebt

Innerhalb von rund zwei Jahren hat sich die Art, wie Software entsteht, fundamental verschoben. KI-Coding-Agenten erzeugen Pull Requests, refaktorieren Module und schreiben Tests in einem Tempo, das menschliche Reviewer nicht mehr Zeile für Zeile nachvollziehen können. Die anfängliche Euphorie um „Vibe Coding" — frei improvisierte Prompts, aus denen lauffähiger Code fällt — ist einer ernüchterten Praxisfrage gewichen: Wie behält eine Organisation die Kontrolle über Code, den sie nicht selbst geschrieben und nicht vollständig gelesen hat?

Die Antwort, die sich 2025 und 2026 als Enterprise-Standard herausgebildet hat, heißt Spec-Driven Development (SDD). Der Kern ist eine Umkehrung: Nicht der Prompt ist das primäre Artefakt, sondern eine versionierte, maschinen- und menschenlesbare Spezifikation. Der KI-Agent ist der Ausführende — die Spezifikation ist die Quelle der Wahrheit, gegen die jeder generierte Code geprüft wird. InfoQ beschreibt diesen Übergang als die entscheidende Reifestufe, mit der KI-Codegenerierung aus dem Experiment in die regulierte Delivery-Pipeline wechselt.

Diese Verschiebung ist mehr als ein Werkzeugwechsel. Sie verändert, wo in der Wertschöpfungskette die intellektuelle Arbeit stattfindet. Früher floss die Sorgfalt in das Schreiben des Codes; künftig fließt sie in die präzise Formulierung von Absicht, Randbedingungen und Akzeptanzkriterien. Die Branche hat dafür den Begriff „Intent Engineering" geprägt — die Disziplin, eine fachliche Absicht so vollständig und eindeutig zu spezifizieren, dass ein Agent sie korrekt umsetzen kann und ein Mensch das Ergebnis gegen die Absicht prüfen kann.

Für Verantwortliche im IT-Delivery-Management ist das eine Governance-Frage ersten Ranges. Wenn die ausführende Instanz keine Person mehr ist, sondern ein nicht-deterministisches Modell, dann verlagern sich Nachvollziehbarkeit, Prüfbarkeit und Haftung von der Person auf den Prozess. Genau diese Brücke — von der strategischen KI-Bereitschaft zur operativen Delivery-Realität — ist das Thema dieses Artikels.

„Vibe Coding ist tot": Was der Begriff wirklich bedeutet

Die Formulierung „Vibe Coding ist tot" kursiert seit dem jüngsten Thoughtworks Technology Radar als Schlagwort. Sie ist zugespitzt, aber sie trifft einen realen Befund. „Vibe Coding" bezeichnete die frühe Praxis, einem Modell unstrukturierte Anweisungen zu geben und das Ergebnis intuitiv zu beurteilen — schnell, kreativ und für Prototypen oft brillant. Für produktive, gewartete Systeme erzeugt diese Arbeitsweise jedoch ein strukturelles Problem: Es entsteht Code ohne nachvollziehbare Absicht.

Thoughtworks und andere fassen die Folge unter dem Begriff der kognitiven Schuld. Gemeint ist nicht fehlerhafter Code — der kann technisch einwandfrei sein. Gemeint ist, dass das gemeinsame mentale Modell des Systems erodiert: Das Team kann nicht mehr zuverlässig erklären, warum eine Komponente so funktioniert, wie sie funktioniert. Diese Schuld ist tückisch, weil sie sich erst beim nächsten Inkrement, beim nächsten Incident oder beim nächsten Personalwechsel zeigt. Wir behandeln diese Mechanik ausführlich in unserer Auseinandersetzung mit moderner technischer Schuld; im vorliegenden Kontext genügt die Feststellung, dass Vibe Coding kognitive Schuld systematisch produziert.

Spec-Driven Development ist die direkte Antwort darauf. Indem die Absicht vor der Generierung explizit, versioniert und prüfbar festgehalten wird, bleibt das mentale Modell des Systems extern dokumentiert — unabhängig davon, wer oder was den Code geschrieben hat. Der Tod des Vibe Codings ist also kein Verbot von KI-Assistenz. Er ist der Übergang von improvisierter zu spezifizierter KI-Assistenz.

Wichtig ist die Abgrenzung: SDD ersetzt nicht die agile Arbeitsweise und auch nicht das fachliche Backlog. Es ersetzt den unkontrollierten Zwischenschritt zwischen Anforderung und generiertem Code durch ein verbindliches, prüfbares Zwischenartefakt. Für Organisationen, die ihre DevOps-Reife bereits strukturiert betrachten, ist SDD die logische Erweiterung der Feedback- und Versionskontroll-Disziplin auf die KI-Schicht.

Spec-Driven, Prompt-getrieben, Vibe Coding: der direkte Vergleich

Die drei Arbeitsweisen lassen sich nicht entlang von „gut" und „schlecht" sortieren, sondern entlang von Kontrollierbarkeit und Eignung für produktive, regulierte Umgebungen. Die folgende Gegenüberstellung macht die governance-relevanten Unterschiede explizit.

Das Governance-Modell: versionierte Spec-Repos als Kontrollpunkt

Der architektonische Kern von Spec-Driven Development ist banal und gerade deshalb wirksam: Die Spezifikation lebt im Versionskontrollsystem, gleichberechtigt neben dem Code. Sie wird über Pull Requests geändert, durchläuft Review, hat eine Commit-Historie und ist damit zu jedem Zeitpunkt der Vergangenheit rekonstruierbar. Was für Code seit zwei Jahrzehnten selbstverständlich ist, wird hier auf die Absicht angewandt.

Damit löst SDD ein Problem, das KI-Assistenz andernfalls verschärft: die Diffusion von Verantwortung. Wenn ein Agent Code erzeugt, ist die Frage „Wer hat das so entschieden?" sonst unbeantwortbar. Mit einem versionierten Spec-Repo ist sie es nicht: Die Entscheidung steht in der Spec, die Spec hat einen Autor und einen Reviewer, und der generierte Code ist eine nachvollziehbare Ableitung daraus. Das ist die Grundlage jeder belastbaren KI-Governance — und der Punkt, an dem ein strukturiertes Governance-Dokumentationsmodell die Spec-Disziplin formell verankern sollte.

Ein zweiter Effekt ist die Verschiebung des Review-Schwerpunkts. Klassisches Code-Review skaliert nicht gegen agentisch erzeugte Volumina — niemand liest fünftausend generierte Zeilen mit derselben Sorgfalt wie fünfzig handgeschriebene. SDD beantwortet das nicht mit „mehr Review", sondern mit konzentriertem Review an wenigen, hochwertigen Kontrollpunkten: Die Spezifikation wird gründlich geprüft, weil sie kompakt, fachlich und langlebig ist. Der generierte Code wird primär gegen die Spec validiert, idealerweise automatisiert.

Daraus folgt ein konkretes Governance-Vorgehen, das auch ohne FAANG-Budget umsetzbar ist:

1. 1Spec-Repo etablieren: Legen Sie Spezifikationen als versionierte Artefakte in dasselbe oder ein eng gekoppeltes Repository wie den Code. Definieren Sie ein verbindliches, schlankes Spec-Format — Absicht, Akzeptanzkriterien, Randbedingungen, explizite Nicht-Ziele.
2. 2Review-Pflicht auf die Spec verlagern: Machen Sie das Spec-Review zum verbindlichen Gate vor jeder Agenten-Generierung. Konzentrieren Sie menschliche Prüfkapazität dort, wo eine Entscheidung getroffen wird, nicht dort, wo sie nur ausgeführt wird.
3. 3High-Value-Checkpoints definieren: Identifizieren Sie die wenigen Stellen, an denen menschliches Urteil unverzichtbar ist — Sicherheits- und Datenschutzgrenzen, fachliche Korrektheit, Architekturentscheidungen. Alles andere wird automatisiert geprüft.
4. 4Spec-zu-Code-Konformität in CI/CD verankern: Lassen Sie die Pipeline prüfen, ob der generierte Code die in der Spec definierten Akzeptanzkriterien und Tests erfüllt. Ein Build, der die Spec verletzt, ist ein roter Build.
5. 5Agenten-Berechtigungen begrenzen: Geben Sie Agenten nur die Rechte, die ihre Rolle erfordert — kein direkter Push auf geschützte Branches, kein Bypass der Spec-Gates, keine Produktionszugriffe ohne menschliche Freigabe.
6. 6Audit-Trail schließen: Verknüpfen Sie Spec-Commit, Agentenlauf und resultierenden Pull Request über stabile Referenzen, sodass jede Codeänderung lückenlos auf eine geprüfte Absicht zurückführbar ist.
7. 7Periodisch nachjustieren: Behandeln Sie das Spec-Format und die Gate-Kriterien als lebende Governance-Artefakte und überprüfen Sie sie in festen Intervallen gegen reale Vorfälle und Reviews.

CI/CD-Integration: Wo die Spezifikation in die Pipeline greift

Spec-Driven Development entfaltet seine Governance-Wirkung erst in der Pipeline. Eine Spezifikation, die niemand automatisiert prüft, ist eine Wunschliste. Der entscheidende Schritt ist daher, die Spec-zu-Code-Konformität zu einem harten Gate im CI/CD-Prozess zu machen — mit derselben Verbindlichkeit, mit der ein fehlgeschlagener Unit-Test den Build stoppt.

Praktisch heißt das: Der Pull Request eines Agenten referenziert die Spec-Version, gegen die er generiert wurde. Die Pipeline leitet aus der Spec die Akzeptanzkriterien ab — als ausführbare Tests, Contract-Checks oder Policy-Prüfungen — und blockiert den Merge, wenn der Code von der spezifizierten Absicht abweicht. Microsoft beschreibt eine solche durchgängige, agentengestützte Lieferkette, in der Spezifikation, Generierung und Validierung als zusammenhängender Lebenszyklus orchestriert werden, statt als lose gekoppelte Einzelschritte.

Für Organisationen ohne hochspezialisiertes Plattformteam ist die pragmatische Reihenfolge entscheidend. Beginnen Sie nicht mit einer vollautomatischen Agentenfabrik, sondern mit dem einfachsten wirksamen Gate: Spec im Repo, verpflichtendes Spec-Review, ein CI-Schritt, der die in der Spec hinterlegten Akzeptanztests ausführt. Dieser Minimal-Stack erzeugt bereits den Großteil des Governance-Werts, weil er Nachvollziehbarkeit und automatische Abweichungserkennung herstellt.

Wer die DevOps-Grundlagen — automatisierte Tests, saubere Versionskontrolle, schnelle Feedback-Schleifen — noch nicht belastbar etabliert hat, sollte diese zuerst stabilisieren. SDD verstärkt eine reife Pipeline, aber es kann eine unreife nicht ersetzen. Eine strukturierte Standortbestimmung der DevOps-Reife ist deshalb sinnvollerweise der erste Schritt, bevor agentische Generierung in größerem Umfang freigegeben wird.

Das Tooling-Spektrum: Spec Kit, Kiro und BMAD im Überblick

Drei Ansätze prägen die aktuelle Spec-Driven-Diskussion, jeder mit einem anderen Schwerpunkt. Es geht nicht darum, das „beste" Werkzeug zu küren, sondern zu verstehen, welches Modell zu welcher Organisationsreife passt. Die folgende Übersicht ordnet die Optionen entlang ihres Governance-Schwerpunkts ein; konkrete Funktionsumfänge entwickeln sich schnell weiter.

Werkzeugwahl ohne FAANG-Budget: die pragmatische Entscheidung

Mittelgroße Organisationen stehen vor einer anderen Realität als Großkonzerne mit dedizierten Plattform- und Tooling-Teams. Sie haben weder das Budget noch die Kapazität, eine eigene agentische Lieferkette zu bauen, und sie können sich kein gescheitertes Großprojekt leisten. Die gute Nachricht aus der Praxis: Der Governance-Wert von SDD entsteht zum überwiegenden Teil aus dem Prinzip, nicht aus dem Werkzeug.

Konkret bedeutet das: Eine versionierte Spec, ein verpflichtendes Spec-Review und ein CI-Gate lassen sich mit den Werkzeugen umsetzen, die ohnehin im Einsatz sind — Git, Pull Requests, eine bestehende CI-Pipeline. Spec Kit ist für Teams attraktiv, die genau hier ansetzen und ihren etablierten Git-Workflow nur um das Spec-Artefakt erweitern wollen. Kiro adressiert Organisationen, die einen stärker geführten, phasenorientierten Ablauf bevorzugen. BMAD ist für jene sinnvoll, die zuerst die Methode und das Rollenmodell verankern wollen, bevor sie sich auf ein spezifisches Tool festlegen.

Die Empfehlung aus Beratungssicht ist konsequent inkrementell: Wählen Sie nicht das umfassendste, sondern das am leichtesten einführbare Modell, das in Ihre bestehende Pipeline passt. Beweisen Sie den Governance-Nutzen an einem realen, nicht-kritischen Wertstrom. Skalieren Sie erst, wenn das Spec-Gate nachweislich Abweichungen abfängt, die ein klassisches Code-Review übersehen hätte. CGI beschreibt diesen Wandel als Übergang vom improvisierten Coden zum Intent Engineering — und genau dieser Übergang lässt sich klein beginnen.

Ein verbreiteter Fehler ist die Annahme, Tool-Auswahl sei die zentrale Entscheidung. Sie ist es nicht. Die zentrale Entscheidung ist organisatorisch: Wer darf Spezifikationen freigeben, welche Checkpoints sind nicht delegierbar, und wie ist der Audit-Trail abgesichert. Das ist eine Governance-Frage, keine Werkzeugfrage — und sie sollte vor der Toolauswahl beantwortet sein.

Die Brücke: von KI-Bereitschaft zur agentischen Delivery

Spec-Driven Development ist die operative Einlösung dessen, was eine strategische KI-Bereitschaftsbewertung auf der Strategieebene fordert. Ein AI Readiness Assessment Guide stellt unter anderem die Fragen: Sind die Prozesse so strukturiert, dass KI-Outputs kontrolliert einfließen können? Existiert ein Verantwortungsmodell für algorithmische Entscheidungen? SDD ist die konkrete Antwort auf genau diese Fragen in der Delivery-Domäne.

Damit schließt sich eine Lücke, die viele Organisationen unterschätzen. Strategische KI-Bereitschaft ohne operative Delivery-Governance erzeugt genau das Muster, das aus gescheiterten KI-Initiativen bekannt ist: beeindruckende Pilotergebnisse, die in Produktion nicht beherrschbar sind. SDD ist der Mechanismus, der einen erfolgreichen Agenten-Piloten in einen reproduzierbaren, auditierbaren Produktionsprozess überführt — die Stelle, an der die meisten KI-Vorhaben sonst scheitern.

Die Reihenfolge der Reifeschritte ist dabei nicht beliebig. Eine Organisation, deren DevOps-Reife schwach ist — instabile Pipelines, lückenhafte Testautomatisierung, langsame Feedback-Schleifen — wird durch Agenten zwar schneller, aber nicht sicherer. Der DORA-Befund, dass KI ein Verstärker und keine Reparatur ist, gilt hier unmittelbar: Agentische Generierung verstärkt die Reife, die bereits da ist, und vergrößert die Lücken, die nicht geschlossen wurden. Eine DevOps Maturity Assessment-Standortbestimmung ist deshalb kein Nebenschauplatz, sondern Voraussetzung.

Für Verantwortliche im Mid-Size-Segment ergibt sich daraus ein klarer Pfad: erst die Delivery-Grundlagen verlässlich machen, dann die Spec-Disziplin als Kontrollpunkt einführen, dann agentische Generierung schrittweise und unter Gate-Kontrolle ausweiten. Diese Reihenfolge ist nicht die schnellste, aber sie ist die einzige, die ohne Großkonzern-Ressourcen nachhaltig trägt.

Praxis-Fahrplan: Agentic SDLC ohne Großkonzern-Ressourcen

Der Weg zu governanter Agentic Delivery ist für mittelgroße Organisationen ein Pfad mit überschaubaren Etappen, nicht ein Großprojekt. Aus der Beratungspraxis hat sich ein Vorgehen bewährt, das in der ersten Etappe ohne neue Werkzeuge und ohne organisatorischen Umbau auskommt.

In den ersten Wochen zählt die Etablierung des Prinzips, nicht der Aufbau einer Plattform. Wählen Sie einen einzelnen, nicht-kritischen Wertstrom. Führen Sie für ihn ein schlankes, verbindliches Spec-Format ein und machen Sie das Spec-Review zum Pflicht-Gate vor jeder Agenten-Generierung. Ergänzen Sie einen CI-Schritt, der die in der Spec hinterlegten Akzeptanztests ausführt. Mehr braucht es für den ersten Nachweis nicht.

In der zweiten Phase geht es um Konsolidierung und Audit-Trail. Verknüpfen Sie Spec-Commit, Agentenlauf und Pull Request über stabile Referenzen, sodass jede Änderung lückenlos auf eine geprüfte Absicht zurückführbar ist. Begrenzen Sie Agenten-Berechtigungen restriktiv und definieren Sie die wenigen nicht-delegierbaren Checkpoints — typischerweise Sicherheits-, Datenschutz- und Architekturentscheidungen — explizit und schriftlich.

Erst in der dritten Phase erfolgt die Skalierung über weitere Wertströme und die Bewertung, ob ein dediziertes SDD-Werkzeug den manuellen Aufwand rechtfertigt. Diese Entscheidung trifft man datenbasiert: Wenn das Spec-Gate nachweislich Abweichungen abfängt, die klassisches Review übersehen hätte, ist die Investition in Tooling begründbar. Vorher ist sie Spekulation.

Begleitend ist eine Erwartungssteuerung nach innen unerlässlich. Die Botschaft an Teams und Leitung lautet nicht, dass KI das Engineering ersetzt, sondern dass sie den Ort der Sorgfalt verschiebt — von der Codezeile zur Spezifikation. Wer diese Erzählung nicht aktiv führt, riskiert, dass Spec-Disziplin als Bürokratie wahrgenommen wird statt als das, was sie ist: die Bedingung dafür, KI-Geschwindigkeit ohne Kontrollverlust zu nutzen.