Spec-driven Development

Spec-driven Development (auch Specification-driven Development, kurz SDD) ist eine Arbeitsweise der KI-gestützten Softwareentwicklung, bei der eine maschinell auswertbare 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 Dokumentation werden aus der Spezifikation abgeleitet oder auf ihre Übereinstimmung mit der Spezifikation geprüft. Der Ansatz verbreitete sich ab etwa 2025 als strukturierte Alternative zum sogenannten Vibe-Coding.[1][2]

Begriff

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

Spec-driven Development entstand als Reaktion auf das Vibe-Coding, bei dem Code weitgehend unstrukturiert aus einzelnen Prompts hervorgeht und Anforderungen, Randbedingungen sowie Sonderfälle ausschließlich in diesen Eingaben festgehalten werden. Diese Informationen werden beim Spec-driven Development stattdessen vor Beginn der Implementierung in einer Spezifikation gebündelt, die das gewünschte Verhalten der Software in strukturierter natürlicher Sprache beschreibt, häufig in Form von Anforderungen mit Akzeptanzkriterien. Sie liefert einem KI-Agenten den aufbereiteten Kontext, aus dem er Quellcode, Tests und weitere Artefakte erzeugt. Das Verfahren wird daher dem Context Engineering zugerechnet, das sich damit befasst, welche Informationen ein Sprachmodell in welcher Form für eine Aufgabe erhalten sollte.[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 wird sie parallel zur Softwareentwicklung fortgeschrieben, wobei automatisierte Tests Spezifikation und Umsetzung synchron halten. Bei Spec-as-source dient die Spezifikation als primäres Artefakt, aus dessen Änderungen der Quellcode automatisch erzeugt oder aktualisiert wird. Werkzeuge wie Kiro, das GitHub Spec Kit, das Tessl Framework oder OpenSpec setzen unterschiedliche Ausprägungen des Ansatzes mit vordefinierten Arbeitsabläufen um.[1][3][6][7]

Einzelnachweise

  1. ↑ a b c d Anna Gutowska: What is spec-driven development? In: ibm.com. IBM, 19. Mai 2026, abgerufen am 30. Juni 2026 (englisch).
  2. ↑ a b c 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.
  3. ↑ a b c d e 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).
  4. ↑ 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).
  5. ↑ Deepak Babu Piskala: Spec-Driven Development: From Code to Contract in the Age of AI Coding Assistants. 30. Januar 2026, arxiv:2602.00180 (englisch).
  6. ↑ a b c 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).
  7. ↑ 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.

Content Disclaimer

Informasi ini disarikan dari Wikipedia dan disajikan kembali untuk tujuan edukasi. Konten tersedia di bawah lisensi CC BY-SA 3.0. Kami tidak bertanggung jawab atas ketidakakuratan data yang bersumber dari kontribusi publik tersebut.

  1. The information displayed on this website is sourced in part or in whole from Wikipedia and has been adapted for the purpose of restating it. We strive to provide accurate and relevant information, however:
  2. There is no guarantee of absolute accuracy. Wikipedia is an open, collaborative project that can be edited by anyone, so information is subject to change.
  3. It is not intended to constitute professional advice. The content displayed is for informational and educational purposes only. For important decisions (e.g., medical, legal, or financial), please consult a professional.
  4. Content copyright. Wikipedia is licensed under the Creative Commons Attribution-ShareAlike License (CC BY-SA). This means that content may be reused with appropriate attribution and shared under a similar license.
  5. Responsible use. Any risk arising from the use of information from this website is entirely the responsibility of the user.