Spec-Driven Development für KI-Agenten, richtig gemacht: Spezifikationen als regulierte Artefakte

Spezifikationsgesteuerte Entwicklung ist eines der wenigen Modewörter, das auf einer soliden Grundlage basiert. Es gibt einen Gründungsvortrag (Sean Groves „The New Code“ auf der AI Engineer World's Fair 2025), wegweisende Tools von zwei Giganten (GitHubs Spec Kit, AWS Kiro), einen radikalen Ansatz (Tessls „Spec-as-Source“) und eine nüchterne Taxonomie von Thoughtworks, die verschiedene Ambitionsstufen unterscheidet. Die Kernidee hat sich über ein Jahr der Prüfung bewährt, weil sie einen wahren Kern trifft: Wenn Agenten den Code schreiben, ist die Spezifikation – nicht der Prompt, nicht der Code – der Ort, an dem die menschliche Absicht tatsächlich liegt. Daher sollte sie zuerst geschrieben, aufbewahrt und als „Single Source of Truth“ behandelt werden. Was die Bewegung noch nicht vollständig gelöst hat, ist die Skalierung auf Flottenebene, wenn die Spezifikationen selbst unübersichtlich werden: Dutzende Spezifikationsdateien, konkurrierende AGENTS.md-Varianten und keine Aufzeichnung darüber, welche Spezifikation welches bereitgestellte Verhalten erzeugt hat. Genau darum geht es in diesem Beitrag – denn eine Spezifikation ist ein Gerüst, und ein Gerüst lässt sich steuern.

Bastien, ein Engineering Manager, war ein früher und überzeugter Anhänger. Sein Team führte die spezifikationsgesteuerte Entwicklung im Herbst ein, und sie lieferte genau das, was die Vorträge versprachen: Funktionen, die früher im Prompt-Ping-Pong untergingen, wurden auf Basis einer einseitigen Spezifikation ausgeliefert, Review-Gespräche gewannen an Qualität, und das Zeitfenster für sichere Delegation erweiterte sich von zwanzigminütigen Aufgaben auf nachmittagsfüllende Projekte. Sechs Monate später führte er eine Prüfung durch und sah, wie Erfolg aussieht, wenn niemand ihn steuert: einundvierzig Spezifikationsdateien in neun Repositories, vier davon beschrieben denselben Dienst unterschiedlich; neun AGENTS.md-Varianten, drei davon automatisch generiert und so aufgebläht, dass kein Modell sie zuverlässig befolgen konnte; Spezifikationen, die sich von dem Code entfernt hatten, den sie einst erzeugt hatten, ohne Aufzeichnung darüber, welche Version welcher Spezifikation den Agentenlauf geprägt hatte, der ein bestimmtes Verhalten auslieferte. Die Methode war richtig. Die Artefakte waren außer Kontrolle geraten. Bastiens Frage an sein Plattform-Team war die, die dieser Beitrag beantwortet: „Wir haben Spezifikationen zur Quelle der Wahrheit gemacht – warum ist diese Wahrheit dann nicht versioniert?“

Um diese Frage zu beantworten, beginnen wir dort, wo der Begriff entstand – die Entstehungsgeschichte enthält genau das Argument, das Governance zum logischen nächsten Schritt macht.

1. Woher das Modewort kommt: Grove, der geschredderte Quellcode und die Modellspezifikation

Ein häufig zitierter Ursprungspunkt ist ein Konferenzvortrag. Auf der AI Engineer World's Fair 2025 in San Francisco hielt Sean Grove – damals bei OpenAI im Bereich Alignment tätig – den Vortrag „The New Code“, den viele Praktiker als die präziseste Formulierung der Bewegung bezeichnen. Er lieferte ein zentrales Bild: Entwickler geben einem Modell einen Prompt, behalten den generierten Code und werfen den Prompt weg – was Grove damit verglich, den Quellcode zu schreddern und nur die Binärdatei zu versionieren. Sein Argument ging tiefer als nur Workflow-Hygiene. Code, so argumentierte er, war schon immer nur ein Teil des Wertes eines Programmierers; der größere Teil ist die strukturierte Kommunikation von Absichten – und eine schriftliche Spezifikation ist das Artefakt, das Menschen darüber in Einklang bringt, was gebaut werden soll, noch bevor es ein Modell ausrichtet. Groves Beispiel war die eigene Modellspezifikation (Model Spec)von OpenAI: ein versioniertes, lebendiges Markdown-Dokument, das das beabsichtigte Modellverhalten des Unternehmens ausdrückt, wobei Klauseln eindeutige IDs und Beispiel-Prompts enthalten, die als Unit-Tests fungieren. Absicht, einmal geschrieben, versioniert, testbar – und sowohl von Menschen als auch von Maschinen nutzbar.

Die Reaktion der Branche gab der Idee ihren Namen und ihre Werkzeuge. GitHub veröffentlichte im September 2025 das Spec Kit als Open Source und formulierte den Wandel direkt – in ihren Worten: Die Lingua Franca der Entwicklung wandert eine Ebene nach oben, und Code wird zur „letzten Meile“. AWS veröffentlichte Kiro, eine IDE, die ihren Spezifikations-Workflow vor der Ausführung auf Anforderungen, Design und Aufgaben konzentriert. Tessl vertrat den radikalen Standpunkt: Spezifikationen als das primäre, gepflegte Artefakt, aus dem der Code generiert wird. Und Andrej Karpathy – der im Februar 2025 den Begriff „Vibe Coding“ prägte – beschrieb die nächste Phase ein Jahr später als Agentic Engineering: die Steuerung von Agenten anhand detaillierter Spezifikationen unter menschlicher Aufsicht. Die Vibe-Ära benannte das Problem; SDD lieferte die Korrektur.

2. Was SDD wirklich ist – und Böckelers Leiter

Da sich der Begriff schneller verbreitete als seine Definition, ist Birgitta Böckelers Analyse vom Oktober 2025 für Thoughtworks (veröffentlicht auf martinfowler.com) die nützlichste Orientierungshilfe. Sie untersuchte Spec Kit, Kiro sowie Tessl und stellte fest, dass es sich nicht um eine einzelne Praxis handelt, sondern um eine Leiter der Ambitionen. Spec-first: eine durchdachte Spezifikation schreiben, sie als Grundlage für die KI-gestützte Aufgabe nutzen, fertig – die Spezifikation überlebt das Feature möglicherweise nicht. Spec-anchored: die Spezifikation nach Abschluss der Aufgabe beibehalten und das Feature darüber weiterentwickeln – die Spezifikation wird zur gepflegten Beschreibung des Verhaltens. Spec-as-source: der Tessl-Ansatz – die Spezifikation ist das Artefakt, das Sie pflegen; der Code ist das kompilierte Ergebnis. Die meisten Teams, die heute SDD praktizieren, befinden sich auf den ersten beiden Stufen, und der Arbeitsablauf ist überall erkennbar gleich: spezifizieren, planen, in Aufgaben zerlegen, implementieren – wobei der Agent die Spezifikation in jeder Phase nutzt.

Warum es funktioniert, ist ebenfalls keine bloße Spekulation mehr. Strukturierte Spezifikationen schränken den Suchraum ein, der bei unbeschränkter Generierung zu Chaos führt; Akzeptanzkriterien geben dem Agenten (und seinem Prüfer) etwas Überprüfbares an die Hand; und die Zerlegung verwandelt ein vages Feature in aufgabenorientierte Arbeitsschritte für den Agenten. Berichte aus der Praxis beschreiben, wie sich das Fenster für sichere Delegation von zehn- bis zwanzigminütigen Aufgaben auf mehrstündige Feature-Lieferungen mit gleichbleibender Qualität erweitert – dies sind Erfahrungen aus Teams, die die Praxis anwenden, keine kontrollierten Studien, und sollten auch so gelesen werden. Die ehrliche Grenze wurde in derselben Thoughtworks-Analyse gezogen, die auch die Leiter definierte: SDD eignet sich für größere Features und Greenfield-Projekte; für kleine Bugfixes lohnt sich der Aufwand für die Spezifikation nicht. Eine Disziplin, die ihre eigenen Grenzen kennt, ist meist eine, die man ernst nehmen sollte.

3. Die begleitende Disziplin: Zurückhaltung und das Instruktionsbudget

SDD kam mit einer begleitenden Praxis, die für Agenten ebenso wichtig ist: die Datei für ständige Anweisungen – AGENTS.md, CLAUDE.md und ihre Verwandten –, die in jeder Agentensitzung als beständige Stimme des Projekts mitgeführt wird. Der hart erarbeitete Konsens von 2026 zu diesen Dateien ist ein Diskurs über Zurückhaltung. Die Empfehlungen aus der Praxis haben sich auf eine Richtzahl eingependelt: Frontier-Modelle folgen oft zuverlässig etwa 150–200 ständigen Anweisungen, bevor die Einhaltung nachlässt – eine Faustregel, keine Garantie des Modells. Die automatisch generierte „Alles-inklusive“-Agentendatei ist daher ein Fehler, der sich als Sorgfalt tarnt. Die entstandenen Empfehlungen lesen sich wie die Checkliste eines Redakteurs: Halten Sie die Datei schlank (die häufig zitierte Empfehlung von HumanLayer liegt bei unter ~300 Zeilen); strukturieren Sie sie nach WAS/WARUM/WIE – Stack und Struktur, Zweck, Build-Befehle und Konventionen; fügen Sie explizite Listen mit Geboten und Verboten sowie Berechtigungsgrenzen hinzu; dokumentieren Sie keine Dateipfade (sie veralten), verwenden Sie die Datei nicht als Linter (nutzen Sie dafür Linter), betten Sie keine aufgabenspezifischen Anweisungen ein, die am Freitag bereits veraltet sind. Für größere Codebasen gilt: progressive Offenlegung – eine kurze Root-Datei und tiefere Dateien, die bei Bedarf geladen werden.

Leser dieser Serie werden beide Hälften dieses Ratschlags wiedererkennen. Das Instruktionsbudget ist eine Tatsache des Context-Engineerings, die sich als Dokumentation tarnt – ständige Anweisungen sind vorgeladener Kontext, und vorgeladene Datenmengen schwächen die Aufmerksamkeit, genau wie unser JIT-Kontext-Beitrag beschreibt; progressive Offenlegung ist Just-in-Time-Laden angewandt auf Spezifikationen. Und „die Agentendatei ist die beständige Stimme des Projekts“ ist eine Gerüst-Behauptung – der rote Faden, der zur Governance-Lücke führt, denn Bastiens neun aufgeblähte Varianten waren kein Schreibproblem. Sie waren ein Problem herrenloser Artefakte.

4. Die Lücke bei der Flottenskalierung: Spezifikationen sind Verhalten, und Verhalten breitet sich aus

Hier ist die strukturelle Beobachtung, die der SDD-Diskurs größtenteils noch nicht erreicht hat. Alles, was die Bewegung über Spezifikationen sagt – Quelle der Wahrheit, von Agenten konsumiert, Menschen aufeinander abstimmend – ist die Behauptung, dass Spezifikationen das Verhalten bestimmen. Im Vokabular des Agenten-Glossars ist eine Spezifikation ein Gerüst: Inhalt, mit dem das Modell arbeitet. Eine Änderung am Gerüst ist eine Richtlinienänderung – verhaltensmäßig dieselbe Kategorie von Ereignis wie ein Modellwechsel. SDD, ernsthaft praktiziert, vervielfacht genau diese Artefakte: Funktionsspezifikationen, Plandateien, Aufgabenlisten, AGENTS.md-Varianten, Abnahmekriterien. Jedes davon steuert Agenten. Fast keines davon hat bei einer typischen Einführung eine Versionshistorie, die an Bereitstellungen geknüpft ist, einen Eigentümer, einen Prüfpfad oder eine Antwort auf die Frage: „Welche Durchläufe wurden durch diese Datei geprägt?“

Das ist Bastiens Audit, beim Namen genannt. Einundvierzig Spezifikationen und neun Agentendateien sind kein Problem der Ordnung – sie sind einundvierzig nicht versionierte Verhaltensvorgaben und neun konkurrierende, geltende Richtlinien. Die bekannten SDD-Schmerzpunkte lassen sich alle auf dieselbe Wurzel zurückführen: Spezifikations-/Code-Drift (frühe SDD-Anwender berichten häufig, dass Spezifikationen und Code auseinanderlaufen, sofern die Spezifikation nicht als Teil des Workflows aktualisiert wird) ist eine unüberwachte Divergenz zwischen der erklärten Wahrheit und der bereitgestellten; doppelte Spezifikationen sind geforkte Richtlinien; aufgeblähte, automatisch generierte Agentendateien sind ungeprüfte Richtlinienanhäufungen. Die Bewegung hat Spezifikationen wichtig gemacht; sie hat sie noch nicht reguliert. Software hat genau dieses Problem für Code mit Versionskontrolle, Code-Reviews, CI-Gates und Bereitstellungsprotokollen gelöst – und die Lösung für Spezifikationen ist dieselbe Maschinerie, angewandt auf die neue Artefaktklasse.

‍