Colin Eberhardt, CTO bei Scott Logic, setzte dasselbe Feature zweimal um: einmal mit seinem üblichen Workflow für Coding-Agenten, einmal mit GitHubs Spec Kit. Die zweite Variante erzeugte 2.577 Zeilen Markdown für 689 Zeilen Code und erforderte dreieinhalb Stunden Prüfaufwand. Beim lokalen Start zeigte sich dennoch ein Implementierungsfehler. Nach Eberhardts eigener Einschätzung war sein üblicher Ablauf etwa zehnmal schneller.
Das ist kein allgemeingültiger Leistungsvergleich, sondern der Erfahrungsbericht eines versierten Entwicklers mit einer kleinen Anwendung. Er lenkt den Blick jedoch auf die entscheidende Frage: Spart eine Spezifikation tatsächlich Zeit, oder verhindert sie genügend Fehlentwicklungen, um ihren zusätzlichen Aufwand zu rechtfertigen?
Darin liegt ihr möglicher Wert. Das Team prüft nicht erst, was der Agent gebaut hat. Es klärt schon vorher, was er bauen soll.
Zugleich hat sich Spec-Driven Development von einem Randthema zu einer eigenen Kategorie entwickelt. Zur Popularisierung des Begriffs im Zusammenhang mit Coding-Agenten trugen vor allem AWS Kiro und GitHubs Spec Kit bei. Die Aufmerksamkeit wächst schneller als die empirische Grundlage. Zeit für eine nüchterne Einordnung.
Warum ein Einzeiler im Bestandscode oft nicht reicht
Ein Feature mit einem einzigen Prompt in Auftrag zu geben, kann im Prototyp funktionieren. Im gewachsenen Bestandscode stößt dieses Vorgehen jedoch schnell an Grenzen, sobald mehrere Dateien und ein Team im Spiel sind. Der Grund ist banal: Große ungeprüfte Änderungen lassen sich im Team weder zuverlässig überblicken noch verantworten. Ein Agent, der am Ende einen Diff mit tausend Zeilen ausspuckt, verschiebt die gesamte Prüflast an genau die Stelle, an der niemand mehr Lust hat, gründlich zu prüfen.
Zwei Senior-Entwickler bekommen dasselbe Ticket und denselben Agenten. Der eine beschreibt das Feature in zwei Sätzen, drückt Enter und prüft hinterher den kompletten Diff. Der andere schreibt zuerst eine Spezifikation, lässt daraus Plan und Aufgabenliste ableiten und liest diese, bevor eine einzige Zeile Code entsteht. Beide nutzen dasselbe Modell. Der zweite Ablauf kann zunächst länger dauern. Der entscheidende Unterschied liegt nicht in der Geschwindigkeit, sondern im Zeitpunkt des ersten Prüfschritts.
Das ist die eigentliche Frage hinter dem Hype. Nicht, ob SDD schneller macht, sondern ob das Team zuerst klärt, was der Agent bauen soll, und erst danach prüft, ob er es richtig gebaut hat. Die Spezifikation ersetzt die spätere Prüfung von Code, Tests und Verhalten nicht, sondern ergänzt sie um eine frühere Prüfung. Wer schon einmal einen 800-Zeilen-Pull-Request eines Agenten am Freitagnachmittag abgenommen hat, weiß, warum ein früherer Prüfschritt attraktiv ist.
Was ist Spec-Driven Development?
Spec-Driven Development (SDD) ist kein einheitliches Verfahren. In seiner pragmatischsten Form hält ein Team vor einer nicht trivialen Implementierung überprüfbar fest, was gebaut werden soll. Ein Coding-Agent leitet daraus Plan, Aufgaben und Code ab.
Anspruchsvollere Varianten nutzen die Spezifikation dauerhaft als Bezugspunkt und halten sie fortlaufend aktuell (spec-anchored). Die radikalste Variante behandelt sie als maßgebliche Quelle, aus der der Code entsteht (spec-as-source). Diese Dreiteilung stammt von Birgitta Böckeler (Thoughtworks). Dieser Artikel konzentriert sich auf die pragmatische spec-first-Variante, weil sie sich am ehesten in den Arbeitsalltag von Teams übertragen lässt.
Schon spec-first kann die Abstimmung vor der Umsetzung verbessern. Als dauerhaftes Wissensartefakt für spätere Entwickler und die Wartung wirkt die Spezifikation aber erst, wenn das Team sie auffindbar hält und bei relevanten Änderungen aktualisiert. Eine veraltete Spezifikation kann sonst mehr schaden als nützen.
Im README von GitHub Spec Kit heißt es zugespitzt, Spezifikationen würden „ausführbar“ und erzeugten unmittelbar funktionierende Implementierungen. Noch radikaler formuliert die Methodenbeschreibung: Der Code dient der Spezifikation, nicht umgekehrt. Für den Alltag genügt eine bescheidenere Lesart: Bevor Code entsteht, muss verständlich feststehen, was gebaut werden soll.
Eine weitere relevante Open-Source-Umsetzung ist OpenSpec. Das Projekt hält im Repository fest, wie das System funktionieren soll, und führt geplante Änderungen getrennt mit Vorschlag, technischem Entwurf, Aufgaben und Spec-Deltas. Nach Abschluss werden die Deltas in die bestehende Spezifikation übernommen. Damit liegt OpenSpec konzeptionell näher an spec-anchored als an reinem spec-first und macht die Spezifikation über einzelne Chat-Sitzungen hinaus zu einer gemeinsamen Arbeitsgrundlage. Das beschreibt einen plausiblen Teammechanismus, belegt aber noch keinen generellen Produktivitätsgewinn.
Kurz gefasst: Der plausibelste Nutzen von Spec-Driven Development liegt im Team, nicht darin, dass der Agent schneller Code erzeugt. Eine kurze, gemeinsam geprüfte Spezifikation macht Anforderungen, Randbedingungen und Entscheidungen für alle sichtbar und kann Rückfragen und Nacharbeit vermeiden. Je mehr Beteiligte, Abhängigkeiten und Übergaben es gibt, desto eher lohnt sich der Aufwand. Für kleine, eindeutige Änderungen genügt oft ein Satz im Ticket; ein eigener Plan wäre dann unnötig. Tests und Code-Review bleiben nötig.
Sean Grove von OpenAI treibt die These auf die Spitze: Der eigentliche Code mache nur einen kleinen Teil des Werts aus, das meiste stecke in der strukturierten Kommunikation davor. Man muss ihm nicht bis zu der Zuspitzung folgen, Spezifikationen seien der neue Code, um den Kern zu sehen: Wie gut das Ergebnis wird, hängt wesentlich davon ab, wie klar die Aufgabe beschrieben ist.
Wie dieses Vorgehen, erst die Anforderungen zu prüfen und dann umzusetzen, in eine umfassendere Strategie für Coding-Agenten passt, ordnet der Beitrag Wo Spec-Driven Development in die Agent-Strategie gehört ein. SDD regelt dabei den Arbeitsablauf, nicht die Qualität der einzelnen Eingabe: Welchen Kontext der Agent überhaupt sieht, klärt das Context Engineering für Coding Agents, und die Spezifikation ist eine von mehreren Kontextquellen darin.
Woher der Begriff kommt
Erfunden hat SDD niemand. In seiner klassischen Verwendung bezeichnet „spec-driven“ seit Jahren API-first- und Design-first-Ansätze: Struktur und Verhalten werden vor dem Code festgelegt. Böckeler weist ausdrücklich darauf hin, dass die Idee älter ist als die gegenwärtige Welle generativer KI. Im Zusammenhang mit Coding-Agenten wurde der Begriff erst 2025 populär: Kiro nutzte ihn zuerst prominent, Spec Kit gab dem Ansatz einen griffigen Namen und einen konkreten Werkzeugkasten. Wer „SDD ist neu“ liest, liest Marketing.
Der eigentliche Gewinn: gemeinsames Verständnis vor der Generierung
Der unmittelbare Nutzen von SDD liegt nicht darin, dass der Agent schneller Code erzeugt. Eine gemeinsam geprüfte Spezifikation schafft ein Artefakt, an dem Produktverantwortliche, Entwickler und Reviewer dieselben Anforderungen, Randbedingungen und Entscheidungen prüfen können. Das kann die einzelne Implementierung verlängern und den Ablauf im Team trotzdem beschleunigen, wenn Rückfragen, Fehlentwicklungen oder Übergabeverluste vermieden werden. Der GitHub-Blog benennt die Rollenverschiebung deutlich: Wer mit Agenten arbeitet, steuert nicht nur, sondern verifiziert. Man prüft an definierten Punkten Spezifikation, Plan und Aufgabenliste, korrigiert Fehler, solange Änderungen noch wenig Aufwand verursachen, und lässt erst dann generieren.
Das trifft ein reales Versagensmuster der Agenten. Anthropic beschreibt es im eigenen Leitfaden zu Claude Code nüchtern: Der Agent hält an, sobald die Arbeit fertig aussieht. Fehlt eine Prüfung, ist „sieht fertig aus“ das einzige verfügbare Signal, und die Verifikation bleibt am Menschen hängen. Diese Prüfung bleibt notwendig, egal wie gut die Spezifikation ist. SDD macht sie nicht überflüssig. Es ergänzt sie um einen früheren Schritt. Anthropics empfohlener Vierschritt, erst erkunden, dann planen, dann implementieren, dann committen, greift bereits den Grundgedanken von SDD auf: Recherche und Planung von der Umsetzung zu trennen, damit der Agent nicht das falsche Problem löst.
Deshalb verspricht dieser Artikel keinen pauschalen Zeitgewinn. Eine Spezifikation kann die Implementierung zunächst verlängern und sich im Team dennoch auszahlen, wenn sie spätere Rückfragen, Fehlentwicklungen oder Nacharbeit verhindert. Sie ersetzt weder Tests noch die Prüfung des fertigen Codes. Sie fügt eine frühere Prüfung hinzu, solange sich eine falsche Annahme noch in wenigen Zeilen der Spezifikation korrigieren lässt und nicht erst in zahlreichen Dateien. Wie Werkzeuge diesen Ablauf konkret umsetzen, etwa mit Spec Kits /speckit.*-Kommandos, OpenSpecs Änderungsdeltas, Kiros EARS-Anforderungen oder dem Planungsmodus von Claude Code, ist ein eigenes Thema und gehört in einen Werkzeug-Beitrag, nicht in diese Definition.
Vibe Coding, Wasserfall, BDD und TDD: die Abgrenzung
SDD und Vibe Coding ergänzen sich; sie konkurrieren nicht: Zum Erkunden taugt der freie, tastende Stil, zum Absichern und Ausliefern die Spezifikation. Simon Willison hat die naive Achse „Vibe schlecht, Spezifikation gut“ früh entschärft. Vibe Coding heiße, mit einem Sprachmodell Software zu bauen, ohne den erzeugten Code zu prüfen; sobald man den Code prüft, testet und erklären kann, sei es schlicht Softwareentwicklung. Die eigentliche Trennlinie ist also nicht, ob ein Spezifikationsdokument existiert, sondern ob geprüft wird. Warum Vibe Coding an der Produktionsgrenze kippt, steht ausführlich im Beitrag Vibe Coding funktioniert bis zur Produktion; hier reicht die Abgrenzung.
Und ist das nicht einfach Wasserfall? Nein, und hier ist der Unterschied
Der Wasserfall-Vorwurf ist die häufigste und die ernsthafteste Kritik. Die Antwort lautet: Der Einwand trifft eine schlechte Umsetzung von SDD, nicht die Methode an sich. Marc Brooker (AWS, baut selbst an Kiro, Interessenkonflikt offengelegt) formuliert die Unterscheidung präzise: „the specification is the thing being iterated on, rather than the implementation.“ Wasserfall behandelt die Spezifikation als frühe Phasenbasis und macht spätere Änderungen teuer; bei SDD wird die Spezifikation fortlaufend überarbeitet; daraus entstehen neue Pläne und Implementierungen. Der ehrliche Zusatz, den auch Befürworter machen: Das Verfahren ist iterativ gedacht, doch ohne klare Leitplanken kann die Praxis dennoch in Richtung Wasserfall driften. Die Spannung ist real, nicht wegzuwischen.
Abgrenzung zu BDD und TDD: der Unterschied liegt im maßgeblichen Artefakt
Bei TDD gibt der nächste fehlschlagende Test vor, was als Nächstes implementiert werden muss; BDD macht konkrete Verhaltensbeispiele in Geschäftssprache überprüfbar. SDD bezeichnet den breiteren Ablauf, in dem ein Agent aus geprüften Vorgaben zu Verhalten, Architektur und Randbedingungen die Implementierung samt Tests und Dokumentation ableitet. Die Verfahren lassen sich kombinieren; der Unterschied liegt darin, welches Artefakt maßgeblich ist. IBM bringt die entscheidende Frage auf den Punkt: Haben wir klar definiert, was wir bauen, und für wen? Bei SDD wird diese Frage beantwortet, bevor der erste Code entsteht.
Wann sich die Spezifikation lohnt und wann ein Satz reicht
Ein eigener SDD-Ablauf lohnt sich besonders, wenn der Weg unklar ist, mehrere Dateien oder Teams betroffen sind oder die Codebasis wenig vertraut ist. Bei kleinen, eindeutigen Änderungen genügt dagegen oft eine knappe Beschreibung im Ticket; ein separater Plan wäre dann mehr Prozess als Hilfe. Bemerkenswert ist, dass nicht ein SDD-Kritiker, sondern Anthropic selbst diese Grenze im eigenen Leitfaden zu Claude Code zieht: „If you could describe the diff in one sentence, skip the plan.“ Das ist die brauchbarste Entscheidungsregel im ganzen Feld.
Böckeler liefert das Anschauungsbeispiel für den Overkill: Eine Kiro-Anfrage blähte einen kleinen Fehler zu vier User Stories mit 16 Akzeptanzkriterien auf. Die Regel, die daraus folgt, ist einfach: Die Spezifikation sollte nur so ausführlich sein, wie es nötig ist, um die relevante Unklarheit zu beseitigen. Die Regel ist eine Orientierung, kein Dogma.
Was in vielen Blogbeiträgen der Anbieter fehlt: Bis Juli 2026 ist keine belastbare kontrollierte Studie öffentlich auffindbar, die zeigt, dass SDD den Nachbearbeitungsaufwand senkt. Häufig genannte Werte wie 50 Prozent weniger Fehler oder 75 Prozent kürzere Zyklen stammen aus Positionspapieren, die ihr eigenes Feld als noch jung bezeichnen, nicht aus kontrollierten Untersuchungen.
Direkte Evidenz für SDD mit Coding-Agenten ist weiterhin dünn. Für den Teammechanismus dahinter gibt es jedoch Hinweise aus der Requirements-Forschung. Eine Fallstudie in drei Organisationen führte 41 Nacharbeitsaufgaben auf fehlendes gemeinsames Verständnis nichtfunktionaler Anforderungen zurück; 78 Prozent davon galten als vermeidbar. Eine industrielle Langzeitstudie über fünf Jahre nennt leichtgewichtige Dokumentation und ein gemeinsames Verständnis der Anforderungen als zwei tragende Prinzipien. Sie warnt zugleich vor beiden Extremen: Zu viel Dokumentation verschwendet Aufwand, zu wenig lässt Wissen verloren gehen. Das beweist keinen allgemeinen SDD-Effekt. Es stützt aber die Annahme, dass eine knappe, gemeinsam geprüfte Spezifikation als Koordinationsartefakt Wert schaffen kann.
Die bislang direkteste empirische Arbeit ist ein im April 2026 veröffentlichtes SSRN-Working-Paper von Brenn Hill. In der derzeit abrufbaren Fassung untersucht es mehr als 100.000 Pull Requests aus 119 Open-Source-Repositories. Die Analyse findet keinen Beleg dafür, dass Spezifikationen Defekte oder Nacharbeit senken. Weil Spezifikationen möglicherweise häufiger bei komplexen Aufgaben eingesetzt werden, erlaubt die Beobachtungsstudie keinen kausalen Schluss.
Sie ist aber deutlich direkter als das oft zitierte ClassEval-Experiment, das einen wasserfallartigen Multi-Agent-Prozess für Python-Aufgaben untersuchte. Bei zwei von drei Modellen sank die funktionale Korrektheit deutlich; beim dritten stieg sie. Das Experiment zeigt damit vor allem, dass zusätzliche Prozessstruktur die Ergebnisse verändert, nicht dass sie grundsätzlich verbessert oder verschlechtert. Ein weiterer Preprint zu „Spec Kit Agents“ meldete in einer LLM-basierten Bewertung einen kleinen Anstieg von 3,51 auf 3,66 Punkten. Eine ergänzende verblindete Bewertung durch Menschen bestätigte diesen Vorteil jedoch nicht. Der Anstieg von 3,51 auf 3,66 betrifft außerdem nur den vollständigen Spec-Kit-Ablauf mit und ohne Kontext-Hooks. Die Studie beantwortet daher nicht, ob SDD einem ebenso sorgfältig geplanten Arbeitsablauf ohne SDD überlegen ist.
Wer SDD heute mit einer festen ROI-Zahl bewirbt, behauptet daher mehr, als die Daten hergeben.
Die Befunde widersprechen sich nicht zwingend. Eine Spezifikation verbessert nicht automatisch den erzeugten Code. Sie kann dennoch die Abstimmung im Team erleichtern und, wenn sie aktuell gehalten wird, Wissen über Anforderungen und Entscheidungen erhalten. Ob daraus weniger Gesamtaufwand entsteht, hängt von Aufgabe, Team und Pflege des Artefakts ab. Wie sich der Spezifikationsaufwand gegen Token- und Prüfkosten rechnet, gehört in die Kostenbetrachtung für KI-Coding-Tools.
Vom Prompt zur Spezifikation
Der Wechsel beginnt nicht mit einem neuen Tool, sondern mit einer gemeinsamen Arbeitsweise: Das Team hält vor der Generierung prüfbar fest, was gebaut werden soll, und entwickelt zugleich ein Gespür dafür, wann dieser Schritt keinen Nutzen bringt. Thoughtworks nahm SDD im Technology Radar vom November 2025 in den Ring „Assess“ auf und bezeichnet es als jungen Ansatz, warnt aber im selben Atemzug vor einer bitteren Lektion: dass sich von Hand gepflegte Detailregeln für KI auf Dauer nicht skalieren lassen. Beides gehört zusammen. Der Ansatz kann nützlich sein, ist aber jung, und wer ihn mechanisch auf jede Aufgabe wirft, lernt die bittere Lektion neu.
Ein kurzes Beispiel: vom Wunsch zur prüfbaren Vorgabe
Nehmen wir das Ticket „Ergänze einen Datumsfilter für den CSV-Export“. Der Satz nennt eine Funktion, lässt aber Entscheidungen offen: Gilt der Zeitraum einschließlich oder ausschließlich seiner Grenzen? Welche Zeitzone zählt? Was passiert, wenn kein Zeitraum gewählt wird? Eine knappe Spezifikation könnte diese Unklarheiten beseitigen, ohne daraus ein Pflichtenheft zu machen:
- Ziel: Nutzende können Buchungen aus einem gewählten Zeitraum als CSV exportieren.
- Akzeptanz: Der Startzeitpunkt zählt mit, der Endzeitpunkt nicht; ohne Auswahl bleibt das bisherige Exportverhalten bestehen.
- Randbedingungen: Die bestehende Berechtigungsprüfung und das CSV-Format bleiben unverändert; maßgeblich ist die Zeitzone des Kontos.
- Nicht-Ziel: Gespeicherte Filter und neue Exportformate gehören nicht zu diesem Ticket.
Noch bevor der Agent Code erzeugt, kann eine zweite Person nun prüfen, ob Grenzwerte, Zeitzone und Bestandsschutz richtig verstanden sind. Genau das ist der vorgezogene Prüfschritt. Die vier Felder sind keine verbindliche Vorlage; sie zeigen nur, wie wenig Text nötig sein kann, um die relevante Unklarheit sichtbar zu machen.
Übertragen Sie dieses Muster auf Ihr nächstes Ticket: Formulieren Sie zunächst nur Ziel und Akzeptanz, ergänzen Sie anschließend Randbedingungen und Nicht-Ziele und lassen Sie die vier Punkte prüfen. Erst danach startet der Agent.
In meinen Workshops mit Teams in Köln und Umgebung liegt der Aha-Moment selten im Werkzeug selbst. Entscheidend ist die Frage, wer die Spezifikation verantwortet. Das ist eine Teamentscheidung, keine technische Detailfrage. SDD setzt häufig voraus, dass Entwickler einen Teil der Anforderungsarbeit übernehmen, die traditionell im Produktbereich liegt. Wer das nicht klärt, verschiebt Verantwortung und Aufwand, ohne beides sichtbar zu machen. Wird die Spezifikation zu einem verbindlichen Prüfschritt, wird SDD auch zu einer Governance-Frage.
Probieren Sie das Verfahren in der kommenden Woche an einem Ticket aus, das Änderungen an mehreren Dateien erfordert. Schreiben Sie vor dem Start des Agenten eine kurze Spezifikation und lassen Sie sie von einer zweiten Person prüfen. Prüfen Sie anschließend weiterhin Code, Tests und Verhalten mit einer Gründlichkeit, die dem Risiko entspricht. Achten Sie darauf, welche Fragen nun vor der Codegenerierung geklärt werden, statt erst im Pull Request aufzutauchen.
Dann haben Sie die Prüfung sinnvoll erweitert, nicht nur verlagert. Das ist der Kern. Alles andere ist Werkzeugwahl.
