Kurze Geschichte von Spec-Driven Development

Im Oktober 1968 treffen sich mehr als fünfzig Fachleute aus elf Ländern in Garmisch. Die NATO hat zu einer Konferenz über „Software Engineering" eingeladen, ein Wort, das damals noch als Provokation gemeint ist. Im Tagungsbericht steht ein Satz, der bis heute nachhallt. Einige Teilnehmer, heißt es dort, sprächen von der „software crisis" oder dem „software gap": Projekte werden zu spät fertig, kosten zu viel und tun nicht, was sie sollen.

Sechsunddreißig Jahre später, im Juni 2004, tagt am selben Ort die Konferenz XP 2004. Drei Forscher stellen dort ein Paper mit dem Titel „Agile Specification-Driven Development" vor. Es ist die früheste bekannte Verwendung des Namens, der heute durch die Entwicklerwelt geht.

Zweimal Garmisch, und dazwischen liegt die eigentliche Geschichte. Sie handelt von einer einzigen Lücke: der zwischen dem, was man bauen will, und dem, was am Ende gebaut wird. Spec-Driven Development ist der jüngste Versuch, sie zu schließen. Es ist bei weitem nicht der erste.

Die Anfänge: drei Anläufe

Erster Anlauf: Mathematik

Die erste Antwort auf die Krise kommt aus der Logik. Wenn Programme nicht tun, was sie sollen, muss man eben präzise aufschreiben, was sie sollen, und zwar so präzise, dass es sich beweisen lässt. David Parnas zeigt 1972, wie man ein Modul so spezifiziert, dass jemand anderes dagegen programmieren kann, ohne nachzufragen. Im Wiener IBM-Labor entsteht in den Siebzigern die Vienna Development Method. Jean-Raymond Abrial schlägt 1977 die Z-Notation vor. Edsger Dijkstra beschreibt 1976 in A Discipline of Programming, wie sich ein Programm Schritt für Schritt aus seiner Spezifikation ableiten lässt.

Diese formalen Methoden funktionieren. Sie werden bis heute dort eingesetzt, wo Fehler Menschenleben oder sehr viel Geld kosten. In der Breite kommen sie nie an, denn sie verlangen Mengenlehre und Prädikatenlogik von Leuten, die eigentlich eine Lagerverwaltung bauen wollen.

Zweiter Anlauf: Verträge und Modelle

Der zweite Anlauf versucht es näher am Code. Bertrand Meyer veröffentlicht 1986 die Sprache Eiffel und mit ihr die Idee des Design by Contract: Jede Routine sagt, was sie voraussetzt und was sie zusichert, und die Sprache prüft das mit. Ein Jahr später stellt Ivar Jacobson auf der OOPSLA die Use Cases vor, eine Form, in der Fachleute und Entwickler dasselbe Dokument lesen können.

Dann wird es groß. Die 1980er bringen CASE-Tools, die aus Diagrammen Code erzeugen sollen. 1997 nimmt die OMG die UML als Standard an, 2001 folgt die Model-Driven Architecture: fachliches Modell rein, lauffähige Anwendung raus. Das Versprechen klingt vertraut. Eingelöst wird es nicht. Martin Fowler schreibt 2004 trocken, er sehe nicht, dass die UML den nötigen Abstraktionssprung liefere, „and without it the MDA will not succeed". Eine Studie von Marian Petre findet 2013 unter fünfzig befragten Entwicklern fünfunddreißig, die UML überhaupt nicht nutzen.

Die Modelle scheitern an ihrer eigenen Starrheit. Wer alles im Diagramm ausdrücken muss, programmiert am Ende im Diagramm, nur mit schlechteren Werkzeugen.

Dritter Anlauf: Beispiele

2001 erscheint das Agile Manifest, auch als Reaktion auf zentnerschwere Anforderungsdokumente. Man könnte meinen, damit sei die Spezifikation erledigt. Das Gegenteil passiert: Sie wechselt die Form. Kent Beck macht mit Test-Driven Development den Test zur Spezifikation, die vor dem Code entsteht. Ward Cunningham baut 2002 mit FIT ein Werkzeug, in dem Fachleute Beispiele in Tabellen schreiben, die sich gegen das System ausführen lassen. Dan North nennt das Ganze 2006 Behaviour-Driven Development und gibt ihm mit „Given, When, Then" eine Sprache. 2008 folgt Cucumber, 2011 fasst Gojko Adzic die Erfahrungen in Specification by Example zusammen.

Der entscheidende Gedanke dieses Anlaufs: Eine Spezifikation, die sich ausführen lässt, kann nicht veralten, ohne dass es jemand merkt. Sie schlägt fehl.

Der Begriff: Garmisch, Juni 2004

Mitten in diese Zeit fällt das Paper von Jonathan Ostroff, David Makalsky und Richard Paige. Die drei wollen zwei Lager versöhnen, die sich für Gegensätze halten: die Test-first-Gemeinde um Beck und die Vertrags-Schule um Meyer. Ihre These passt in einen Satz: „both unit tests and contracts are specifications". Tests beschreiben Szenarien gut, Verträge beschreiben Regeln, die immer gelten. Wer beides kombiniert, entwickelt spezifikationsgetrieben. Sie nennen das Specification-Driven Development.

Aus heutiger Sicht ist vor allem interessant, was das Paper nicht meint. Die Spezifikation von 2004 ist kein Textdokument. Sie ist Code, der läuft und prüft. Dokumentenlastige, plangetriebene Entwicklung kritisieren die Autoren ausdrücklich.

Der Name setzt sich damals nicht durch. Die Idee taucht trotzdem immer wieder auf, etwa 2010 bei GitHub-Mitgründer Tom Preston-Werner, der unter dem Titel Readme Driven Development fordert: „Write your Readme first." Erst aufschreiben, was die Software tun soll, dann bauen. Ein Mittelweg, wie er selbst sagt, zwischen dem Wasserfall und einem Agile, das gar nichts mehr aufschreibt.

Die Gegenwart: die Idee trifft auf AI

Im Februar 2025 erfindet Andrej Karpathy ein Wort für das Gegenteil von alldem. „Vibe Coding" nennt er es, wenn man sich ganz dem Sprachmodell überlässt und vergisst, dass der Code überhaupt existiert. Er meint damit Wochenendprojekte zum Wegwerfen. Das Wort macht trotzdem Karriere, und mit ihm die Erfahrung, dass so entstandene Software schnell wächst und schlecht altert.

Die Gegenbewegung folgt binnen Monaten, und sie greift nach dem alten Namen. Im Juli 2025 stellt Amazon die Entwicklungsumgebung Kiro vor und wirbt ausdrücklich mit „spec-driven development". Im September veröffentlicht GitHub das Spec Kit. Ein Jahr später hat das Projekt über 137.000 Sterne und die Version 1.0 erreicht. Daneben entstehen Tessl, OpenSpec, BMAD und ein Dutzend weitere Werkzeuge. Das Muster ist überall ähnlich: erst eine Spezifikation in natürlicher Sprache, daraus ein Plan, daraus Aufgaben, und erst dann schreibt ein Agent den Code.

GitHub formuliert den Anspruch im Methodik-Text des Spec Kit ohne falsche Bescheidenheit:

Specifications don't serve code—code serves specifications.

Wenn Spezifikationen den Code erzeugen, heißt es dort weiter, gebe es keine Lücke mehr, „only transformation". Das ist, fast wörtlich, das Versprechen von 1968, von den CASE-Tools und von der Model-Driven Architecture.

Genau davor warnt Birgitta Böckeler von Thoughtworks. Sie hat drei der Werkzeuge ausprobiert und im Oktober 2025 beschrieben, was sie vorfand: einen kleinen Bugfix, aus dem das Werkzeug vier User Stories mit sechzehn Akzeptanzkriterien machte, und Berge von Markdown, die jemand lesen muss. Ihre Sorge gilt der Parallele zur modellgetriebenen Entwicklung, mit der sie ihre Laufbahn begonnen hat:

I wonder if spec-as-source, and even spec-anchoring, might end up with the downsides of both MDD and LLMs: Inflexibility and non-determinism.

Kent Beck, der Mann hinter dem dritten Anlauf, legt Anfang 2026 nach. Wer die ganze Spezifikation vor der Umsetzung schreibe, unterstelle, dass man beim Bauen nichts mehr lernt. Das sei eine, in seinen Worten, bizarre Annahme.

Eine leisere Beobachtung kommt aus der Praxis. Der Schweizer Berater Simon Martinelli, der nach eigenen Angaben sechs Kundenprojekte spezifikationsgetrieben umgesetzt hat, berichtete im Juni 2026 auf der AI Native DevCon, wohin die Arbeit wandert: In einem Projekt für das Schweizer Parlament hätten die beiden Product Owner inzwischen mehr zu tun als der einzige Entwickler. Die Umsetzung dauert Minuten, das Spezifizieren Wochen. Der Engpass sitzt jetzt dort, wo entschieden wird, was gebaut werden soll.

Was diesmal anders ist und was nicht

Neu ist der Übersetzer. Die formalen Methoden verlangten Mathematik, die Modelle verlangten UML, die ausführbaren Beispiele verlangten Gherkin. Ein Sprachmodell nimmt, was Menschen ohnehin schreiben: Sätze. Die Einstiegshürde, an der fünfzig Jahre lang jeder Anlauf hängen blieb, ist damit tatsächlich gefallen.

Alt ist alles andere. Eine Spezifikation in Markdown lässt sich nicht ausführen. Sie kann veralten, ohne dass ein Test rot wird, und das Modell, das sie liest, liefert nicht zweimal dasselbe Ergebnis. Die Pointe des Papers von 2004, dass eine gute Spezifikation sich selbst überprüft, ist in der neuen Welle weitgehend verloren gegangen. Die interessantesten Werkzeuge arbeiten gerade daran, sie zurückzuholen.

Zur Ehrlichkeit gehört auch: Dass Spec-Driven Development mit AI bessere Software liefert, ist bisher eine Erfahrung einzelner Teams und kein Befund. Eine belastbare Studie dazu habe ich nicht gefunden. Ich arbeite trotzdem so, aus einem schlichten Grund. Die Frage, was eigentlich gebaut werden soll, stellt sich in jedem Projekt. Man kann sie vorher beantworten oder hinterher.

Was genau eine Spezifikation in diesem Sinn ist, welche Stufen es gibt und wie die Werkzeuge sich unterscheiden, ist Thema des nächsten Artikels dieser Reihe.