Spec-driven Development (auch Specification-driven Development, kurz SDD) ist ein Ansatz der KI-gestützten Softwareentwicklung, bei dem KI-Agenten auf Basis von Large Language Models Software anhand einer zuvor erstellten Spezifikation entwickeln. Diese wird häufig in natürlicher Sprache formuliert und dient als maßgebliche Grundlage für die Umsetzung. Die KI-Agenten unterstützen bereits beim Ausformulieren der Anforderungen, zerlegen diese in Teilaufgaben und erzeugen daraus Quelltext und Softwaretests. Entwickler prüfen in der Regel die Zwischenergebnisse und präzisieren gegebenenfalls die Spezifikation erneut. Der Ansatz wird häufig als strukturiertere Alternative zum Vibe-Coding eingeordnet.
Der Begriff Spec-driven Development wird in der Fachliteratur und von Anbietern von Entwicklungswerkzeugen uneinheitlich verwendet und ist nicht eindeutig definiert. Vereinzelt wurde die Bezeichnung bereits vor der Verbreitung generativer KI-Modelle verwendet, etwa 2004 für einen agilen Ansatz, der testgetriebene Entwicklung mit dem Prinzip des Design by Contract verbindet. Mit der Verbreitung KI-gestützter Programmierwerkzeuge wird der Begriff überwiegend in diesem Kontext verwendet.
Anforderungen vor der Implementierung festzulegen, ist kein neues Vorgehen. Es ist Gegenstand des Anforderungsmanagements und liegt auch der testgetriebenen Entwicklung, dem Behavior Driven Development und der modellgetriebenen Softwareentwicklung zugrunde. Anders als die Codegeneratoren der modellgetriebenen Softwareentwicklung erzeugen Large Language Models den Quelltext jedoch nicht deterministisch, sodass aus derselben Spezifikation unterschiedlicher Code entstehen kann.
Die Arbeit wird meist in aufeinanderfolgende Schritte gegliedert, in denen jeweils ein eigenes Dokument entsteht. Zunächst werden übergeordnete Grundsätze und Anforderungen festgehalten und Mehrdeutigkeiten aufgelöst. Anschließend erstellt der KI-Agent einen technischen Entwurf, zerlegt die Arbeit in Einzelaufgaben und setzt diese um. Das Ergebnis wird abschließend gegen die Spezifikation geprüft. Auf diese Weise sollen die ursprünglichen Anforderungen über alle Schritte hinweg erhalten bleiben, statt mehrfach neu interpretiert zu werden.
Üblicherweise werden drei aufeinander aufbauende Reifegrade unterschieden. Beim Spec-first-Vorgehen entsteht die Spezifikation einmalig zu Beginn der Arbeit an einem Feature und wird danach nicht zwingend weitergepflegt. Bei Spec-anchored bleibt sie nach der Implementierung als Referenz für die Weiterentwicklung erhalten und wird fortgeschrieben, wobei sie sich auch auf einzelne Funktionen oder Entwicklungsschritte beschränken kann. Dadurch lässt sich der Ansatz iterativ einsetzen. Bei Spec-as-source dient die Spezifikation als primäres Artefakt, aus dessen Änderungen der Quellcode automatisch erzeugt oder aktualisiert wird.
Die empirische Evidenz zu Vor- und Nachteilen von Spec-driven Development ist bislang begrenzt. Eine 2026 veröffentlichte Studie untersuchte rund 88.000 Pull-Requests aus 119 Open-Source-Repositories und fand keinen statistisch signifikanten Zusammenhang zwischen den untersuchten Spezifikationsartefakten und einer Verringerung von Programmfehlern oder nachträglichen Korrekturen. Die Studie untersuchte jedoch keine von aktuellen SDD-Werkzeugen erzeugten Spezifikationen.
Eine weitere empirische Untersuchung zeigte, dass die Qualität der Anforderungen die Ergebnisse der Codegenerierung beeinflusst. Eine Studie zu sogenannten Requirement Smells fand bei zunehmender Dichte problematischer Anforderungen eine geringere funktionale Korrektheit des erzeugten Codes. Zugleich führte auch eine hohe Qualität der Anforderungen nicht in allen Fällen zu korrektem Code.