Spec-driven Development
Spec-driven Development (auch Specification-driven Development, kurz SDD) ist eine Arbeitsweise der KI-gestützten Softwareentwicklung, bei der eine strukturierte Spezifikation als zentrale Grundlage des Entwicklungsprozesses dient. Sie wird vor der Implementierung erstellt und bildet für Softwareentwickler und generative KI-Modelle die maßgebliche Referenz (Single Source of Truth). Quellcode, Tests und weitere Entwicklungsartefakte können aus der Spezifikation abgeleitet oder auf ihre Übereinstimmung mit ihr geprüft werden. Der Ansatz wird dabei häufig als stärker strukturierte Alternative zum Vibe-Coding eingeordnet.[1][2]
Begriff
[Bearbeiten | Quelltext bearbeiten]Der Begriff Spec-driven Development wird in der Fachliteratur und von Anbietern von Entwicklungswerkzeugen uneinheitlich verwendet und ist nicht eindeutig definiert.[3] Vereinzelt wurde die Bezeichnung bereits vor der Verbreitung generativer Sprachmodelle verwendet, etwa 2004 für einen agilen Ansatz, der testgetriebene Entwicklung mit dem Prinzip des Design by Contract verbindet.[4] In seiner heutigen Bedeutung bezeichnet der Begriff jedoch überwiegend eine Arbeitsweise der KI-gestützten Softwareentwicklung. Die Grundidee, das gewünschte Verhalten zunächst zu spezifizieren und die Implementierung daran auszurichten, teilt Spec-driven Development mit älteren Verfahren wie der testgetriebenen Entwicklung, dem Behavior Driven Development und der modellgetriebenen Softwareentwicklung.[3][1][5]
Ansatz
[Bearbeiten | Quelltext bearbeiten]Beim Spec-driven Development wird der Implementierung einer Software oder einzelner Features eine strukturierte Spezifikation vorangestellt, die das gewünschte Verhalten in natürlicher Sprache beschreibt. Sie enthält insbesondere Anforderungen, Randbedingungen sowie Sonderfälle und dient als Referenz für die weitere Planung und Umsetzung. Eine solche Spezifikation liefert einem KI-Agenten den entsprechenden Kontext, aus dem er Quellcode, Tests und weitere Artefakte erzeugt.[2][6]
Die zugehörigen Vorgehensmodelle gliedern die Entwicklung in aufeinanderfolgende Schritte, bei denen jeweils ein eigenes Dokument entsteht. Üblicherweise werden zunächst übergeordnete Grundsätze und Anforderungen festgehalten. Anschließend werden Mehrdeutigkeiten aufgelöst, die Architektur geplant und die Arbeit in einzelne Aufgaben zerlegt, bevor die Implementierung mit KI-Unterstützung erfolgt und das Ergebnis abschließend gegen die Spezifikation geprüft wird. Auf diese Weise sollen die ursprünglichen Anforderungen über alle Stationen der Entwicklung erhalten bleiben, statt auf dem Weg von den Bedürfnissen der Beteiligten über Anforderungen und Architektur bis zur Umsetzung mehrfach neu interpretiert zu werden.[3][6]
Üblicherweise werden drei aufeinander aufbauende Reifegrade unterschieden.[3][2][1] 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.[1][3][6][7]
Empirische Befunde
[Bearbeiten | Quelltext bearbeiten]Die empirische Evidenz zu Vor- und Nachteilen von Spec-driven Development ist bislang begrenzt. Eine 2026 veröffentlichte Studie untersuchte rund 88 Tausend 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.[8]
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.[9]
Weblinks
[Bearbeiten | Quelltext bearbeiten]- Awesome Spec-Driven Development (SDD) auf GitHub (englisch) – kuratierte Liste rund um Spec-driven Development
- Eberhard Wolff: Spec-Driven-Development mit Simon Martinelli auf YouTube, 16. Januar 2026, abgerufen am 13. Juli 2026 (Laufzeit: 1:04:54).
Einzelnachweise
[Bearbeiten | Quelltext bearbeiten]- 1 2 3 4 Anna Gutowska: What is spec-driven development? In: ibm.com. IBM, 19. Mai 2026, abgerufen am 30. Juni 2026 (englisch).
- 1 2 3 Jannis Mainczyk, Jan Oberhagemann: Fünf Tools für Spec-driven Development im Überblick. In: heise.de. Heise Medien GmbH & Co. KG, 8. Juni 2026, abgerufen am 30. Juni 2026.
- 1 2 3 4 5 Birgitta Böckeler: Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl. In: martinfowler.com. Martin Fowler, 15. Oktober 2025, abgerufen am 30. Juni 2026 (englisch).
- ↑ Jonathan S. Ostroff, David Makalsky, Richard F. Paige: Agile Specification-Driven Development. In: Extreme Programming and Agile Processes in Software Engineering (= Lecture Notes in Computer Science. Nr. 3092). Springer, Berlin, Heidelberg 2004, S. 104–112, doi:10.1007/978-3-540-24853-8_12 (englisch).
- ↑ Deepak Babu Piskala: Spec-Driven Development: From Code to Contract in the Age of AI Coding Assistants. 30. Januar 2026, arxiv:2602.00180 (englisch).
- 1 2 3 Apoorv Gupta: Spec-Driven Development: A Spec-First Approach to AI-Native Engineering. In: developer.microsoft.com. Microsoft, 10. Juni 2026, abgerufen am 30. Juni 2026 (englisch).
- ↑ Wolf Hosbach: Specs first: OpenSpec sortiert das KI-Chaos beim Entwickeln. In: heise.de. Heise Medien GmbH & Co. KG, 13. Juli 2026, abgerufen am 13. Juli 2026.
- ↑ Brenn Hill: Specification Artifacts in Open-Source Pull Request Workflows Do Not Reduce Defects: An Empirical Test of Spec-Driven Development Claims. In: LIPIcs, Volume 394, ESEM 2026. Band 394. Schloss Dagstuhl – Leibniz-Zentrum für Informatik, 2026, ISSN 1868-8969, S. 84:1–84:20, doi:10.4230/LIPICS.ESEM.2026.84 (dagstuhl.de [abgerufen am 8. Oktober 2026]).
- ↑ Hugo Villamizar, Jannik Fischbach, Mert Şahin, Julian Frattini, Alessio Ferrari, Alexander Korn, Andreas Vogelsang, Daniel Mendez: On the Impact of Requirement Smells in LLM-Based Code Generation. 25. September 2026, abgerufen am 8. Oktober 2026.