Spec-Driven Development beschreibt eine Arbeitsweise, in der die Spezifikation das führende Artefakt eines Projekts ist. Sie ist die verbindliche Quelle, aus der Implementierung, Tests und Dokumentation abgeleitet werden. Der Ansatz zielt auf ein Problem, das mit KI-Unterstützung größer geworden ist, weil ein Modell zu jeder Beschreibung Code erzeugt, auch zu einer, die zwei Beteiligte unterschiedlich verstehen. Spec-Driven Development übersetzt vorhandene Klärung in eine Form, die eine Maschine lesen kann. Die Klärung selbst leistet weiterhin das Projektteam.
Wie läuft Spec-Driven Development ab?
Das Grundprinzip ist werkzeugunabhängig: Zwischen den Phasen stehen geprüfte Artefakte, und die nächste Phase arbeitet mit dem Artefakt der vorigen weiter. Das funktioniert auch mit reinen Markdown-Dateien. GitHub Spec Kit ist eine konkrete Umsetzung davon und dient hier als Beispiel.
GitHub Spec Kit führt ein Vorhaben durch vier Phasen: Spezifikation, Plan, Tasks, Implementierung. Jede Phase hinterlässt ein Markdown-Artefakt, das die nächste Phase als Kontext übernimmt, statt dass ein Entwickler denselben Zusammenhang erneut in einen Prompt tippt. Davor legt das Team ein Dokument an, das Spec Kit constitution nennt. Darin steht, was das Projekt umfasst, in welcher Domäne es arbeitet, welche Versionen gelten, wie das Team Code schreibt und wie das Repository aufgebaut ist. Ein Agent, der diese Datei liest, hält sich an die Architekturgrenzen, die dort stehen, und leitet sie nicht aus dem Code ab, den er gerade vorfindet.
Eine fachliche Anforderung mit Akzeptanzkriterien lässt sich gegen das Ergebnis halten, eine Aufgabenbeschreibung im Ticketsystem sagt nur, was jemand tun soll. Stehen die Akzeptanzkriterien im selben Artefakt, aus dem der Agent die Implementierung ableitet, dann stammen Umsetzung und Prüfung aus derselben Quelle.
Woher kommt Spec-Driven Development?
Spec-Driven Development ist als Gegenbewegung zum Vibe Coding entstanden, also zum Übernehmen generierten Codes, ohne ihn zu lesen. Andrej Karpathy hat den Ausdruck im Februar 2025 geprägt und ihn Anfang 2026 selbst auf Wegwerfprojekte, Demos und Erkundungen beschränkt. Für ein Wegwerf-Skript ist die Arbeitsweise vertretbar, weil niemand es in zwei Jahren erweitern wird. In einem System, das über Jahre betrieben und erweitert wird, kostet dieselbe Arbeitsweise später Zeit: Der Code läuft, die Begründung für seine Struktur existiert nirgends, und beim nächsten Fehler rekonstruiert sie jemand von vorn. Das Fachmagazin iX hat fünf Werkzeuge für Spec-Driven Development verglichen und dabei ein Reifegradmodell vorgestellt.
Die drei Reifegrade
Das Modell unterscheidet drei Stufen entlang der Frage, wie weit ein Team die Spezifikation fortschreibt, nachdem die Entwicklung begonnen hat. Die Stufen sind keine Leiter, auf der oben besser ist. Welche passt, entscheidet der Kontext, und Teams mischen die Stufen durchaus.
| Reifegrad | Was mit der Spezifikation passiert | Voraussetzung |
|---|---|---|
| spec-first | entsteht einmal vor der Entwicklung und bleibt danach stehen | stabiler Umfang |
| spec-anchored | wird über die Projektlaufzeit als lebendes Dokument fortgeschrieben und mit dem Code in Deckung gehalten | laufende Pflege, die jede Änderung mitnimmt |
| spec-as-source | ist das Artefakt, an dem geändert wird, der Code entsteht daraus | eine Testsuite, die eine Neugenerierung blockiert |
Auf der ersten Stufe, spec-first, entsteht die Spezifikation einmal vor der Entwicklung. Danach ändert sich der Code mit jedem Commit, während das Dokument auf dem Stand des ersten Tages bleibt. Das reicht für ein abgegrenztes Vorhaben mit stabilem Umfang und wird unbrauchbar, sobald sich Anforderungen während der Umsetzung verschieben.
spec-anchored schreibt die Spezifikation über die Projektlaufzeit als lebendes Dokument fort und hält sie mit dem Code in Deckung. Diese Stufe kostet laufend Pflegezeit, und sie ist die erste, auf der die Dokumentation am Projektende noch beschreibt, was tatsächlich gebaut wurde.
Auf spec-as-source arbeitet niemand mehr direkt am Code, die Spezifikation ist das Artefakt, an dem geändert wird, und der Code entsteht daraus. Wer dort ankommen will, braucht vorher eine Testsuite, die eine Neugenerierung blockiert, sobald sie etwas kaputt macht. Ohne diese Rückmeldung merkt niemand, was ein Durchlauf unterwegs verloren hat.
Thoughtworks führt den Ansatz weiter als prüfenswert
Die Einordnung fällt vorsichtiger aus, als die Diskussion um das Thema vermuten lässt. Der Technology Radar hat Spec-Driven Development im November 2025 im Ring Assess geführt, also unter den Ansätzen, die eine Prüfung wert sind und noch keine gesetzte Praxis. In der aktuellen Ausgabe steht der Eintrag nicht mehr, und Thoughtworks hält zu solchen Einträgen fest, dass sie in der Sache weiterhin gelten dürften.
Aufgenommen ist stattdessen das Werkzeug. GitHub Spec Kit steht im Volume 34 vom April 2026 ebenfalls im Ring Assess, und die Begründung dort ist für die Projektplanung interessanter als die Einstufung: Den größten Nutzen sehen die Autoren bei erfahrenen Entwicklungsteams, die Clean Code und Architekturregeln schon praktizieren. Als Schwächen nennen sie Anweisungsmengen, die mit jedem Zusatz wachsen und den Kontext verwässern, überflüssige defensive Prüfungen im generierten Code und Markdown-Ausgaben, die so lang werden, dass sie niemand mehr liest.
Ein Entwicklungsteam, das Architekturentscheidungen dokumentiert und seine Tests pflegt, bekommt mit einer Spezifikation ein Werkzeug, das diese Arbeit für einen Agenten lesbar macht. Ein Entwicklungsteam ohne diese Grundlage bekommt ein weiteres Dokument.
Im Bestandssystem scheitert der Agent an der Umgebung
Diesen Rahmen fasst der Begriff Agent Harness zusammen, der aus der Diskussion um Agentic Engineering stammt und den Christopher Flocke und Daniel Engelhardt bei heise developer ausführen. Ein Agent beginnt jede Sitzung ohne Gedächtnis, liest Quelltexte, Konfigurationsdateien, Tickets und Dokumentation und rekonstruiert daraus ein Bild des Systems. In einer über zehn oder zwanzig Jahre gewachsenen Anwendung weicht dieses Bild vom tatsächlichen Verhalten ab, und der Agent arbeitet auf einer Annahme weiter, die niemand geprüft hat. Für die Autoren liegt das Problem in der Umgebung, die dem Agenten fehlt.
Was ein Agent baut, bildet den Zustand des Systems ab, samt der Abweichungen, die niemand mehr aufgeschrieben hat. Eine Spezifikation hilft deshalb dort am wenigsten, wo sie am dringendsten gebraucht würde. In einem Legacy-System ohne Tests, die Regressionen melden, ohne dokumentierte Architektur und ohne deterministische Pipeline arbeitet ein Team zuerst an genau diesen drei Punkten, bevor die erste Spezifikation entsteht.
Damit ist auch gesagt, was Spec-Driven Development in einem Projekt tatsächlich bewirkt. Es überträgt die Klärung, die ein Team schon geleistet hat, in ein Artefakt, das eine Maschine auswerten kann. Wo diese Klärung fehlt, beschleunigt der Ansatz die Produktion von Code, über den später niemand Auskunft geben kann.
Welcher Reifegrad passt zu welchem Projekt?
Für die meisten Vorhaben im Mittelstand ist spec-anchored die Stufe, die den Aufwand einspielt, weil eine Anwendung dort über Jahre weiterentwickelt wird und nur eine fortgeschriebene Spezifikation am Ende noch beschreibt, was im System steht. spec-first genügt bei einem abgegrenzten Vorhaben mit festem Umfang, etwa einem einmaligen Migrations- oder Auswertungsskript, und wird zum Risiko, sobald während der Umsetzung neue Anforderungen dazukommen. spec-as-source setzt eine Testabdeckung voraus, die in gewachsenen Anwendungen selten vorliegt, und ist damit heute eine Option für neu gebaute Dienste.
Ein bestimmtes Werkzeug ist für keine dieser Stufen Voraussetzung. Entscheidend ist, dass jemand die Spezifikation pflegt und dass die Pipeline gegen sie prüft.
Woran Sie ein Projekt erkennen, in dem die Spezifikation führt
Vier Merkmale können Sie vor der Beauftragung abfragen, egal mit welchem Werkzeug ein Entwicklungspartner arbeitet.
- Die Akzeptanzkriterien stehen vor der Umsetzung fest und sind so formuliert, dass sich das Ergebnis daran messen lässt.
- Ihr Entwicklungspartner kann Ihnen sagen, welche Architektur er gewählt hat, welche Alternativen er verworfen hat und warum.
- Tests und statische Analyse laufen lokal wie in der Pipeline, ergänzt um Abhängigkeits- und Lizenzprüfung im CI, damit ein Ergebnis nicht davon abhängt, wer es erzeugt hat.
- Am Ende jeder Iteration steht ein lauffähiges Ergebnis und ein Artefakt, das die Entscheidungen dahinter festhält.
Ein Entwicklungspartner, der diese vier Punkte nicht belegen kann, hat kein Werkzeugproblem.
Worauf devosphere in Projekten hinarbeitet
Der API-Vertrag steht vor dem ersten Endpunkt, ein angrenzendes Team entwickelt gegen diese Spezifikation, während die Implementierung noch läuft, und die Dokumentation entsteht aus derselben Datei, aus der auch der Vertragstest läuft. Security-Tests laufen in der CI/CD-Pipeline mit, und wir instrumentieren die Anwendung im Code, damit im Betrieb sichtbar ist, welcher Aufruf wo hängt, statt das nach dem Go Live zu ergänzen. Das ist das Zielbild, an dem wir unsere Projekte ausrichten. Wie weit ein einzelnes Vorhaben dort steht, hängt vom Bestand ab und davon, welche Schritte auf Auftraggeberseite mitgehen. Beides klären wir am Anfang. Die Arbeitsweise dahinter ist agile Softwareentwicklung, die technischen Bausteine gehören zu unserem Technologiestack, und den Betrieb in Deutschland übernimmt cloudriven.
Geändert hat sich mit Coding-Agenten der Adressat. Artefakte, die bisher ein Team und den nächsten Entwicklungspartner adressiert haben, liest jetzt auch eine Maschine, und sie nimmt sie wörtlicher, als ein Mensch es täte.
Häufige Fragen
Quellen
- iX 7/2026, Jannis Mainczyk und Jan Oberhagemann, „Fünf Tools für Spec-driven Development im Überblick", 08.06.2026
- Thoughtworks Technology Radar, „Spec-driven development", Ring Assess, November 2025
- Thoughtworks Technology Radar, „GitHub Spec Kit", Ring Assess, Volume 34, April 2026
- heise developer, „Harness Engineering: Wie KI-Agenten in Brownfield-Projekten produktiv werden", 18.08.2026
- GitHub Spec Kit, Dokumentation, Stand 27.05.2026
- The New Stack, Darryl K. Taft, „Vibe coding is passé. Karpathy has a new name for the future of software", 10.02.2026.
Fabian Friedrich
