Was ist Spec-Driven Development?

Im ersten Teil dieser Reihe ging es um die Vorgeschichte: fünfzig Jahre Versuche, die Lücke zwischen dem, was man bauen will, und dem, was am Ende gebaut wird, zu schließen. Am Ende stand die Beobachtung, dass diesmal nur eines wirklich neu ist, nämlich der Übersetzer. Ein Sprachmodell nimmt Sätze statt Mengenlehre, UML oder Gherkin.

Bleibt die Frage, die ich dort vor mir hergeschoben habe. Wenn die Spezifikation jetzt in normaler Sprache geschrieben wird, was genau ist sie dann? Ein Pflichtenheft? Ein langer Prompt? Und woran erkennt man, ob sie taugt?

Was eine Spezifikation hier bedeutet

Die brauchbarste Definition stammt von Birgitta Böckeler, die bei Thoughtworks die Serie „Exploring Generative AI" mit Praxisberichten füllt. Sie schreibt:

A spec is a structured, behavior-oriented artifact - or a set of related artifacts - written in natural language that expresses software functionality and serves as guidance to AI coding agents.

Vier Merkmale stecken darin. Die Spezifikation ist strukturiert, sie hat also eine Form und ist kein Fließtext. Sie beschreibt Verhalten, nicht Bauweise. Sie steht in natürlicher Sprache. Und sie richtet sich an einen Agenten, nicht an einen Menschen, auch wenn Menschen sie lesen müssen.

Der letzte Punkt erklärt, warum der Begriff so schnell verwässert. Eine Anweisung an ein Sprachmodell ist auch natürliche Sprache, und so rutscht das Wort. Böckeler notiert das sichtlich genervt: Der Begriff sei noch nicht gut definiert und bereits „semantically diffused", sie habe Leute „spec" als Synonym für einen detaillierten Prompt benutzen hören. Der Unterschied ist trotzdem greifbar. Ein Prompt ist weg, wenn die Antwort da ist. Eine Spezifikation bleibt liegen und wird beim nächsten Mal wieder gelesen.

Drei Stufen, und wer sie erfunden hat

Aus genau dieser Frage, was mit der Spezifikation nach getaner Arbeit passiert, hat Böckeler im Oktober 2025 eine Einteilung gebaut, die seither überall auftaucht. Drei Stufen, in ihren Worten:

Spec-first: A well thought-out spec is written first, and then used in the AI-assisted development workflow for the task at hand.

Spec-anchored: The spec is kept even after the task is complete, to continue using it for evolution and maintenance of the respective feature.

Spec-as-source: The spec is the main source file over time, and only the spec is edited by the human, the human never touches the code.

Auf der ersten Stufe ist die Spezifikation ein Werkzeug für eine Aufgabe und wird danach meist weggeworfen. Auf der zweiten überlebt sie die Aufgabe und wird gepflegt wie Code. Auf der dritten ist sie der Quelltext, und was das Modell daraus erzeugt, liest niemand mehr.

Die Einteilung hat Karriere gemacht, oft ohne ihren Namen. Die Beratung Senacor etwa beschreibt sie im Dezember 2025 fast wortgleich, stellt eine vierte Stufe voran, das „traditionelle (KI-unterstützte) Coding", und nennt Böckeler an keiner Stelle. Auch ein arXiv-Paper vom Januar 2026 übernimmt die drei Begriffe. Wer sie benutzt, sollte wissen, woher sie kommen.

Wichtig an der Einteilung ist, dass sie kein Reifegrad im Sinne von besser und schlechter ist, auch wenn das Wort das nahelegt. Sie beschreibt, wie weit man bereit ist, den Code aus der Hand zu geben. Und je weiter man das tut, desto genauer muss die Spezifikation sein.

Der Ablauf: Spezifikation, Plan, Aufgaben, Code

In der Praxis sieht das bei allen Werkzeugen ähnlich aus. Amazons Kiro führt durch drei Stufen: Anforderungen, Entwurf, Aufgaben. GitHubs Spec Kit macht dasselbe in vier bis fünf Schritten und stellt eine „Constitution" voran, in der unverrückbare Prinzipien des Projekts stehen. Dann folgen Spezifikation, Plan, Aufgabenliste und erst danach die Umsetzung.

Der Schnitt ist immer derselbe: erst das Was, dann das Wie, dann die Zerlegung in Stücke, dann der Code. Der Sinn dieser Kette liegt nicht in der Bürokratie, sondern in den Haltepunkten. Nach jedem Schritt liegt etwas vor, das man lesen und ablehnen kann, bevor daraus etwas Größeres wächst. Eine falsche Annahme in der Spezifikation kostet eine Minute. Dieselbe Annahme, dreihundert Zeilen später entdeckt, kostet den Nachmittag.

Die Schritte unterscheiden sich darin, welche Frage sie beantworten. In der Spezifikation steht, was das fertige Ding können soll und woran man erkennt, dass es das tut. Im Plan steht, wie es gebaut wird, welche Dateien betroffen sind und welche Entscheidung zwischen zwei Wegen fällt. In der Aufgabenliste steht die Reihenfolge. Diese Trennung klingt nach Formalismus, ist aber der Punkt, an dem die meisten Durchläufe scheitern: Sobald technische Details in die Spezifikation rutschen, steht dort eine Lösung statt einer Anforderung, und niemand prüft mehr, ob es die richtige Anforderung war.

Der Preis ist Papier. Böckeler beschreibt, wie Kiro aus einem kleinen Fehler „4 'user stories' with a total of 16 acceptance criteria" machte, und schreibt über das Spec Kit einen Satz, den ich seither nicht mehr loswerde:

To be honest, I'd rather review code than all these markdown files.

Das ist der Kern des Problems. Die Kette verlagert Arbeit vom Schreiben zum Prüfen, und Prüfen ist die unbeliebtere Hälfte.

Woran man eine gute Spezifikation erkennt

Hier wird es konkret. Addy Osmani hat 2026 aufgeschrieben, was eine Spezifikation für Agenten leisten muss, gestützt auf eine GitHub-Auswertung von über 2.500 Agent-Konfigurationsdateien. Sechs Bereiche kommen in den wirksamen Dateien vor: Kommandos, Tests, Projektstruktur, Codestil, Git-Arbeitsweise und Grenzen. Fehlt einer, fehlt dem Agenten etwas.

Am meisten mitgenommen habe ich den letzten Punkt. Grenzen gehören nicht als Liste von Verboten in die Spezifikation, sondern in drei Stufen: Was der Agent immer darf, was er vorher fragen muss, und was er nie tun darf. Schemaänderungen und neue Abhängigkeiten stehen in der mittleren Stufe. Das ist deutlich nützlicher als ein Absatz mit zehn „bitte nicht".

Und dann ist da ein Befund, der gegen jeden Reflex läuft, den eine Spezifikation auslöst. Osmani nennt ihn nach einer Studie den „curse of instructions": Je mehr Anweisungen in einem Prompt stehen, desto schlechter befolgt das Modell jede einzelne. Bei zehn Regeln hält es die ersten paar ein und übersieht den Rest. Eine Spezifikation wird also nicht dadurch besser, dass sie vollständiger wird. Die Kunst ist, dem Modell jeweils nur das Stück zu geben, das es gerade braucht. Osmanis Zusammenfassung der häufigsten Ursache für nutzlose Agent-Dateien ist trotzdem eine andere: „Most agent files fail because they're too vague."

Den praktischsten Rat holt Osmani bei Simon Willison. Er schlägt vor, zur Spezifikation eine Sammlung von Konformitätstests zu legen, sprachunabhängig und oft als YAML, die jede Umsetzung bestehen muss. Osmani nennt sie einen Vertrag: Wer eine Schnittstelle baut, schreibt die erwarteten Ein- und Ausgaben dort hinein, und der Code des Agenten muss alle Fälle erfüllen. Das ist strenger als ein paar nachträglich geschriebene Tests, weil es direkt aus der Spezifikation kommt. Und es ist genau die Pointe des Papers von 2004, das im ersten Teil dieser Reihe stand: Eine Spezifikation, die sich ausführen lässt, kann nicht veralten, ohne dass es jemand merkt. In der neuen Welle ist dieser Gedanke die Ausnahme geblieben, nicht die Regel.

Die Werkzeuge und ihr Stand

Die Landschaft ist in vierzehn Monaten entstanden. Im Juli 2025 stellt Amazon Kiro vor und wirbt offensiv mit dem Begriff. Im September folgt GitHub mit dem Spec Kit, das ein Jahr später auf Version 1.0 kommt. Daneben stehen Tessl, das als einziges ernsthaft auf die dritte Stufe zielt, sowie OpenSpec und BMAD.

OpenSpec zeigt dabei gut, wohin sich die Gattung entwickelt. Das Kommandozeilenwerkzeug führt vom Erkunden der Idee über einen Vorschlag zur Spezifikation und kommt, anders als die Tutorials der meisten Werkzeuge, auch mit bestehendem Code zurecht. Im Juli 2026 berichtete heise über Version 1.6, deren wichtigste Neuerung ein Befehl ist, mit dem sich eine vorhandene Spezifikation vor der Umsetzung ändern lässt, ohne alles noch einmal von vorn zu beginnen. Das klingt klein, ist aber der Unterschied zwischen einem Dokument, das man wegwirft, und einem, mit dem man arbeitet.

Interessant ist, wie sich diese Werkzeuge bewegen. Böckeler ordnete das Spec Kit im Oktober 2025 noch klar auf der ersten Stufe ein, es sei „still what I would call spec-first only, not spec-anchored over time". Am 17. Juni 2026 hat GitHub an einem einzigen Tag zwei Dinge nachgeliefert: einen Leitfaden für mitwachsende Spezifikationen mit einem Modell namens „living spec", bei dem die Spezifikation der Vertrag ist und Plan und Aufgaben daraus abgeleitet werden, und ein Kommando namens converge, das Code gegen Spezifikation abgleicht und offene Arbeit zurückmeldet. Ob das die zweite Stufe ist, sagt GitHub nicht, denn es benutzt Böckelers Wortschatz nicht. Ich halte es für dasselbe unter anderem Namen, aber das ist meine Einordnung und kein Beleg.

Thoughtworks selbst bleibt zurückhaltend. Im Technology Radar vom November 2025 steht Spec-Driven Development im Ring „Assess", also beobachten und ausprobieren, nicht übernehmen. Die Begründung ist freundlich und deutlich: Man finde den Bereich faszinierend, doch „the workflows remain elaborate and opinionated". Und man lerne hier womöglich gerade eine bittere Lektion neu, nämlich dass handgeschriebene Detailregeln für AI am Ende nicht skalieren. Ein halbes Jahr später, im April 2026, kommt der Rat dazu, angesichts stärker werdender Modelle regelmäßig neu zu prüfen, ob man das Werkzeug überhaupt noch braucht.

Was Spec-Driven Development nicht ist

Zwei Verwechslungen lohnen die Klärung.

Die erste ist die modellgetriebene Entwicklung. Senacor bringt die Trennung auf den Punkt und benutzt dafür ein Bild, das hängen bleibt: „Die KI übernimmt damit eine Rolle, die mit der des Compilers vergleichbar ist, nur auf einer höheren Abstraktionsebene." Nur stimmt das Bild an einer entscheidenden Stelle nicht, und Senacor sagt das selbst. Modellgetriebene Entwicklung ist vollständig deterministisch, dieselbe Modellbeschreibung führt immer zum gleichen Code. Spec-Driven Development ist es nicht. Dieselbe Spezifikation kann zweimal Verschiedenes ergeben. Ein Compiler, der gelegentlich etwas anderes übersetzt, wäre ein kaputter Compiler.

Die zweite Verwechslung ist die mit dem Dokument. Roman Stranghöner von INNOQ hat im April 2026 beschrieben, was passiert, wenn Teams die Spezifikation als Übergabe missverstehen: Sie wird dicker, das Gefühl von Sicherheit wächst, und daraus folgt noch lange nicht, dass etwas Besseres gebaut wird. Er beruft sich dabei auf einen Satz von Jeff Patton, den er aus einer Schulung mitgenommen hat: „Shared documents are not shared understanding." Der Satz ist die beste Warnung vor der Falle, die Spec-Driven Development mit sich bringt. Eine Spezifikation ersetzt kein Gespräch, sie hält nur fest, was im Gespräch entschieden wurde.

Wo die Arbeit hinwandert

Bleibt die Frage, was das mit der Arbeit macht. Die klarste Beobachtung dazu kommt von Simon Martinelli, einem Schweizer Berater, der mehrere Kundenprojekte spezifikationsgetrieben umgesetzt hat. In einem Projekt für das Schweizer Parlament ist er der Einzige, der Code anfasst, und zwei Product Owner haben inzwischen mehr zu tun als er. Sein Bild vom Takt: früher zwei Wochen Anforderungen und zwei Wochen Implementierung, heute zwei Wochen, dann fünf Minuten, dann wieder zwei Wochen.

Das ist die eigentliche Verschiebung. Nicht das Programmieren verschwindet, sondern der Engpass wandert dorthin, wo entschieden wird, was gebaut werden soll. Wer dort keine Antworten hat, bekommt sie auch vom besten Werkzeug nicht.

Wie das konkret aussehen kann, habe ich unter Spec-Driven Workflow aufgeschrieben, mit der Kette an Schritten, nach der ich selbst arbeite. Ob man dafür überhaupt ein Werkzeug braucht oder ob man sich das Ganze sparen und einfach drauflos bauen kann, ist die Frage des nächsten und letzten Teils dieser Reihe.