Seit Jahrzehnten folgt die Softwareentwicklung einem vertrauten Muster: Anforderungen sammeln, Spezifikationen schreiben, dann den Code bauen, der diese Spezifikationen Wirklichkeit werden lässt. Die Spezifikation war ein Gerüst: nützlich für die Planung, unverzichtbar für die Abstimmung, aber am Ende weggeworfen, sobald die „eigentliche Arbeit“ des Programmierens begann. Mit immer ausgereifteren KI-Coding-Assistenten entsteht nun ein neues Paradigma, das diesen Ablauf auf den Kopf stellt: Spec-driven Development.
Von Bauplänen zu Motoren: Die Ursprünge von Spec-driven Development
Ganz neu ist Spec-driven Development nicht, aber der Aufstieg der KI-Coding-Tools hat seiner heutigen Form einen gewaltigen Schub gegeben. Die Wurzeln des Konzepts liegen in früheren Methoden wie dem Test-driven Development (TDD), bei dem Kent Beck Entwickler dazu anhielt, zuerst die Tests zu schreiben und dann so lange zu programmieren, bis die tatsächliche Ausgabe der erwarteten entspricht. Während TDD aber die Überprüfung des Verhaltens in den Mittelpunkt stellt, macht Spec-driven Development die Spezifikation selbst ausführbar.
Schwung bekam die heutige Bewegung von Unternehmen wie Amazon, das seit Langem einen „Working Backwards“-Prozess pflegt: Früh im Projekt entstehen Dokumente wie Pressemitteilungen und Blogposts, damit das Denken beim Kunden beginnt. GitHub hat kürzlich Spec Kit als Open Source veröffentlicht, ein Toolkit, das Spezifikationen ins Zentrum des Engineering-Prozesses stellt, und andere Plattformen wie Kiro haben ganze Entwicklungs-Workflows um dieses Konzept gebaut.
Die Grundeinsicht hinter diesem Wandel ist einfach, aber tiefgreifend. Sean Grove von OpenAI hat es so gesagt: „80-90% unserer Arbeit als Programmierer ist strukturierte Kommunikation, und Spezifikationen sind der beste Weg, um zu vermitteln, was die Software tun soll“.
Der Bruch mit der Vergangenheit: Was Spec-driven Development von traditionellen Ansätzen unterscheidet
Um zu verstehen, warum Spec-driven Development ein so radikaler Bruch ist, lohnt sich ein Blick auf das, was davor kam. Die traditionelle Softwareentwicklung hat mehrere große Paradigmen durchlaufen, jedes mit eigenen Merkmalen.
Die Wasserfall-Ära: Als Pläne in Stein gemeißelt waren
Das Wasserfallmodell, 1970 erstmals von Winston W. Royce formalisiert, behandelte Softwareentwicklung als linearen, sequenziellen Prozess. Jede Phase (Anforderungen, Entwurf, Implementierung, Verifikation und Wartung) floss wie bei einem Wasserfall nach unten in die nächste, und die Teams schlossen eine Phase vollständig ab, bevor sie die nächste begannen.
In dieser Welt waren Spezifikationen detaillierte Baupläne, die vorab entstanden und dann von den Entwicklungsteams getreu umgesetzt wurden. Die Spec war heilig, aber statisch: Geänderte Anforderungen bedeuteten teure Neuplanung und womöglich das Scheitern des Projekts.
Die agile Revolution: Veränderung annehmen
Die agile Bewegung, die 2001 im Agilen Manifest ihre Form fand, rebellierte gegen die Starrheit des Wasserfalls. Agile Methoden setzten auf iterative Entwicklung: Die Teams arbeiteten in kleinen Schritten und holten regelmäßig Feedback ein. Zu den zentralen Prinzipien gehörten „Reagieren auf Veränderung mehr als das Befolgen eines Plans“ und „funktionierende Software mehr als umfassende Dokumentation“.
Agile Methoden machten die Softwareentwicklung anpassungsfähiger, drängten Spezifikationen aber oft auf schlanke User Stories oder Backlogs zurück. Der Fokus verschob sich auf funktionierenden Code, die Dokumentation kam hinterher (wenn überhaupt).
Spec-driven: Die Synthese
Spec-driven Development ist eine Synthese dieser Ansätze. Wie der Wasserfall betont es den Wert detaillierter Spezifikationen. Wie Agile setzt es auf iterative Entwicklung und Veränderung. Der entscheidende Unterschied: Es macht die Spezifikation zum lebendigen Zentrum des Entwicklungsprozesses.
Statt Spezifikationen von der Implementierung zu trennen, schafft Spec-driven Development „eine einzige Quelle der Wahrheit“, in der „die Spezifikation die Implementierung, die Checklisten und die Aufgabenaufteilung steuert“. Diese Spezifikationen sind die eine Informationsquelle, an der sich Entwickler und Stakeholder über den gesamten Lebenszyklus eines Features oder Systems orientieren.
Der KI-Vorteil: Warum Spec-driven Development mit modernen Tools glänzt
Seine eigentliche Stärke zeigt Spec-driven Development im Zusammenspiel mit KI-Coding-Assistenten wie Claude Code, GitHub Copilot und Cursor. Diese Tools übersetzen strukturierte Spezifikationen sehr gut in funktionierenden Code, tun sich aber schwer mit dem mehrdeutigen, iterativen Prompting, das einen Großteil der heutigen KI-gestützten Entwicklung prägt.
Von Vibe Coding zu strukturiertem Engineering
Die heutige KI-gestützte Entwicklung ähnelt oft dem, was GitHub „Vibe Coding“ nennt: „Sie beschreiben Ihr Ziel, bekommen einen Block Code zurück, und oft … sieht er richtig aus, funktioniert aber nicht ganz“. Dieser Ansatz bedeutet, „Software mit einem LLM zu bauen, ohne den Code zu prüfen, den es schreibt“, und führt zu dem, was viele Entwickler kennen: schnelles Prototyping, gefolgt von Debugging-Albträumen.
Studien zeigen, dass KI-generierter Code häufig Schwachstellen enthält: Bis zu 40% der von KI erzeugten Abfragen sind anfällig für SQL-Injection-Angriffe. Die Lösungen von KI-Coding-Agenten sind außerdem oft komplexer als von Menschen geschriebene Entsprechungen, behandeln häufig unwahrscheinliche Randfälle und neigen zum Over-Engineering.
Die strukturierte Alternative
Spec-driven Development geht diese Probleme an, indem es KI-Tools eindeutige Anweisungen gibt. Statt Coding-Agenten „wie Suchmaschinen“ zu behandeln, behandelt es sie „eher wie wortwörtlich denkende Pair-Programming-Partner“, die „stark in der Mustererkennung sind, aber trotzdem eindeutige Anweisungen brauchen“.
Plattformen wie Kiro zeigen diesen Ansatz in der Praxis: Statt „sich durch eine Lösung zu viben, beginnen Sie mit einem Prompt zu dem, was Sie bauen wollen, und der KI-Agent hilft Ihnen, es in drei Dokumente aufzuteilen: Anforderungen (User Stories), Entwurf (Architektur und Datenmodell) und Aufgaben (Aufschlüsselung der Implementierungsschritte)“.
Dieser strukturierte Ansatz bringt mehrere Vorteile:
- Weniger Mehrdeutigkeit: Klare Spezifikationen beseitigen das Raten, das die KI zu irrelevantem oder unsicherem Code verleitet
- Bessere Architektur: Wenn Teams für neue Features eine Spec schreiben, „erzwingen sie Klarheit darüber, wie das Feature mit dem bestehenden System zusammenspielen soll“, und sorgen dafür, dass „sich neuer Code wie ein natürlicher Teil des Projekts anfühlt und nicht wie ein angeschraubter Zusatz“
- Wartbares Ergebnis: Anders als Vibe-Coding-Projekte, die mit der Zeit unverständlich werden, erzeugt Spec-driven Development eine Dokumentation, die neben dem Code bestehen bleibt
Vibe Coding durch die Spec-driven-Brille: Eine kritische Analyse
Wer Vibe Coding durch die Brille von Spec-driven Development betrachtet, sieht, warum dieser scheinbar magische Zugang zum Programmieren im professionellen Umfeld oft nicht reicht.
Der Reiz und die Falle
Der Reiz von Vibe Coding liegt in Zugänglichkeit und Tempo: „Mit KI-Assistenten geht es viel schneller, Code zu produzieren und kleine Projekte wie eine Prototyp-Website, ein Spiel oder eine Web-App zusammenzuzimmern“. Andrej Karpathy hat es so beschrieben: Vibe Coding heißt, man „gibt sich den Vibes ganz hin, umarmt die Exponentialkurven und vergisst, dass es den Code überhaupt gibt“.
Im großen Maßstab wird diese Stärke zur Schwäche. Ein reales Beispiel ist ein Indie-Entwickler, der ein SaaS-Produkt komplett per Vibe Coding gebaut hat. Zuerst feierte er, dass sein „saas mit Cursor gebaut wurde, null handgeschriebener Code“, nur um Wochen später zu berichten, dass „zufällige Dinge passieren, Nutzung der api keys am Limit, Leute umgehen das Abo, legen irgendeinen Scheiß in der db an“.
Das fehlende Fundament
Das Grundproblem von Vibe Coding ist die „Unwartbarkeit“, während „Spec-driven-Assets“ ein „Potenzial für bessere Wartbarkeit“ bieten. Simon Willison weist darauf hin, dass professionelle Softwareentwicklung von Entwicklern „Code verlangt, der nachweislich funktioniert, den andere Menschen (und Maschinen) verstehen können und der die weitere Entwicklung in Zukunft trägt“.
Spec-driven Development liefert dieses Fundament. Wo Vibe Coding Entwickler dazu ermuntert, zu „vergessen, dass es den Code überhaupt gibt“, sorgt Spec-driven Development dafür, dass Absicht, Architektur und Randbedingungen klar dokumentiert und ausführbar sind. Das ist der Unterschied zwischen einem Wochenend-Prototyp und Produktionssoftware.
Der Weg nach vorn
Gute Teams „behandeln die KI wie einen superschnellen, aber unerfahrenen Entwickler“, wobei „Sie, der Senior Engineer oder Teamleiter, weiterhin für das Ergebnis verantwortlich sind“. Spec-driven Development liefert den Rahmen für diese Verantwortung. Es sorgt dafür, dass KI-Tools innerhalb festgelegter Grenzen arbeiten, dass sich ihre Ergebnisse an klaren Anforderungen prüfen lassen und dass menschliche Entwickler die entstehenden Systeme verstehen und warten können.
Die Zukunft der Entwicklung: Specs als Quellcode
Mit immer ausgereifteren KI-Tools kommen wir in eine Zeit, in der die traditionellen Grenzen zwischen Spezifikation und Implementierung verschwimmen. Spec-driven Development ist „2025 aus ein paar zentralen Gründen wieder im Trend, vor allem wegen des Aufstiegs KI-nativer Entwicklungstools und einer veränderten Art, wie Teams mit intelligenten Systemen zusammenarbeiten“.
Die Folgen gehen über das Programmieren hinaus. Ein Beobachter meinte: „Die Zukunft des Programmierens könnte ein Haufen Markdown-Dateien sein … und Jazz“. Das mag verkürzt klingen, trifft aber etwas Wichtiges: Wenn die KI mehr von den mechanischen Seiten des Programmierens übernimmt, können sich menschliche Entwickler auf die übergeordneten Probleme konzentrieren, also Systemdesign, User Experience und Geschäftslogik.
Spec-driven Development ist mehr als eine Methode. Es erkennt an, dass in einer von KI unterstützten Welt die Spezifikation kein Gerüst ist, das man wegwirft, sondern das Fundament, auf dem jede erfolgreiche Software steht. Die Revolution steht nicht erst bevor: Für die Teams, die diesen Ansatz übernommen haben, ist sie schon da.
Aus dem Englischen übersetzt: zum Originalbeitrag