Spec-Driven Development: Wenn der Engineer die Spezifikation schreibt und die AI den Code

Spec-Driven Development war in unseren Gesprächen mit 92 Tech Leads und Engineering Leads das am häufigsten genannte Ziel für 2026. Die Idee dahinter ist ein Rollenwechsel: Nicht mehr der Mensch tippt den Code, sondern er beschreibt so präzise, was gebaut werden soll, dass ein AI-Agent es zuverlässig umsetzt.

Wie das in der Praxis wirklich funktioniert, beschreiben zwei Kollegen von uns, die bereits täglich so arbeiten: Michael Pehl und Marcel Schiffel, beide Senior Software Entwickler bei DevBoost. Michael plant heute mehr, als er programmiert. Marcel erschließt Spec-Driven Development gerade für Bestandssysteme. Wie weit das gehen kann, zeigt ein Satz von Michael: Seit Anfang des Jahres hat er kaum noch selbst Code geschrieben.

Wie wichtig dieser Wechsel in ihrer Arbeitsweise den Teams damit ist, zeigen die Zahlen. Rund 27 Prozent der Befragten in unseren AI-Report Interviews nannten einen Workflow in diese Richtung konkret als Ziel für 2026. Gleichzeitig haben weniger als 5 Prozent ihn bislang strukturiert umgesetzt. Der Wunsch ist groß, doch nur wenige Teams arbeiten bereits effizient nach dem spec-driven Ansatz. Aus unseren Interviews stammen Aussagen wie diese:

Spec-driven Development so weit treiben wie es geht. Code wird nur noch reviewed, nicht mehr angefasst.

Der größte Hebel: die Dokumentation der Software und die Roadmap sauber pflegen. Das wäre die perfekte Grundlage für AI, um kleinteilige Features selbst zu bauen.

Dass sich der Aufwand lohnt, berichten die, die schon so arbeiten:

Features können wir damit doppelt bis fünffach so schnell durchbringen, bei gleicher Code-Qualität.

Warum es trotzdem so wenige schaffen, zeigt der Blick auf die typischen Stolperfallen.

Die meisten Teams, die AI für Feature-Entwicklung einsetzen, erleben dasselbe Muster: Es funktioniert bei isolierten Tasks und sauberem Scope. Sobald Features komplexer werden, wächst der Nacharbeitsaufwand.

Wir haben keine gute Erfahrung mit Agenten in der regulären Feature-Entwicklung gemacht. Zu viel Kontextwissen nötig, zu viel implizites Wissen, um Features zu bauen.

Der Grund lässt sich auf drei Punkte eindampfen:

• Die Anforderung ist nicht spezifisch genug. Was einem erfahrenen Entwickler als Ausgangspunkt reicht, reicht einem Agenten nicht. Ein Mensch füllt Lücken aus Erfahrung, ein Agent mit plausiblen Defaults.
• Implizites Wissen steckt in Köpfen, nicht im System. Architekturentscheidungen und Konventionen, die seit Jahren selbstverständlich sind, stehen nirgends. Der Agent kennt sie nicht.
• Der Einstieg ist zu komplex gewählt. Statt mit klar abgegrenzten Features anzufangen, wird AI direkt auf einen abhängigkeitsreichen Core-Flow losgelassen.

Dazu kommt: Shit in, shit out gilt für Mensch und Agent gleichermaßen, aber der Agent handelt viel schneller auf schlechten Input, und eine schlechte Vorgabe wirkt stärker als ein schlechtes Ticket.

Die Antwort auf all das ist, die Anforderung so explizit zu machen, dass nichts mehr geraten werden muss. Genau das ist Spec-Driven Development.

Spec-Driven Development (SDD) ist eine Entwicklungsmethode, bei der eine strukturierte Spezifikation die primäre Quelle der Wahrheit ist, nicht der Code. Wer ein Feature ändern will, ändert zuerst die Spec, und der Code folgt daraus.

Konkret ist die Spec kein Jira-Ticket und kein Confluence-Artikel, sondern eine oder mehrere strukturierte Dateien, in der Praxis meist Markdown, die in einem eigenen Ordner (zum Beispiel specs/) direkt im Repository liegen, versioniert neben dem Code. Der Agent liest sie, setzt sie um und prüft seinen Output gegen sie.

Das entscheidende Merkmal, das SDD von bloßem Coding mit Plan und AI unterscheidet: Die Spec wird nicht nach der Umsetzung weggeworfen. Sie bleibt im Repository und wächst mit dem Produkt. Ändert sich das Feature, ändert sich zuerst die Spec, dann der Code. So entsteht eine lebende Dokumentation, die jederzeit erklärt, was das System tun soll und warum.

Weil alles Wichtige in der Spec steht, ist sie zugleich ein stabiler Übergabepunkt zwischen Planung, Implementierung, Review und Test, ohne dass der gesamte vorherige Chatverlauf mitgeschleppt werden muss.

Ist das nun ein Tool oder eine Methode? Eine Methode. Kaufen oder einführen musst du nichts. Im Kern sind eine Handvoll Dateien im Repository alles, was es braucht: ein Regelwerk und die Specs. Es gibt Tools, die den Ablauf bequemer machen, aber Voraussetzung sind sie nicht. Wer anfangen will, legt eine Datei an.

Und nur um sicherzugehen, was SDD nicht ist:

• Vibe Coding ("Cursor, bau mal ein Login") lässt AI frei assoziieren. Das funktioniert für Prototypen, nicht für Produktivsysteme.
• Code Completion ist ein Hilfswerkzeug für einen einzelnen Entwickler. SDD ist ein Workflow für das ganze Team.
• Waterfall definiert Specs einmalig zu Beginn eines Projekts. In SDD entwickelt sich die Spec kontinuierlich mit, wie jede andere Codedatei auch.
• Klassisches Anforderungsmanagement produziert Dokumente, die in Jira oder Confluence veralten. In SDD ist die Spec klar strukturiert, für Menschen genauso lesbar wie für Agenten, lebt im Repo und ist direkt der Input für die Implementierung.

Der eigentliche Kern ist nicht neu: Klare Anforderungen waren schon immer die Grundlage guter Softwareentwicklung. Was sich geändert hat: Früher konnte ein erfahrener Entwickler Lücken aus Domänenwissen füllen. Ein Agent kann das nicht. Was nicht explizit steht, wird geraten, und manchmal eben falsch. Das wird als Halluzination bezeichnet. SDD ist die pragmatische Konsequenz daraus.

Bevor der erste Plan entsteht, braucht SDD genauso wie agentisches Arbeiten generell ein Fundament: die Constitution. Das ist ein Dokument mit den dauerhaften, projektweiten Regeln, typischerweise eine AGENTS.md im Repository-Root.

Sie enthält, was für alle Features gilt:

• Welche Sprache, welches Framework, welche Testing-Strategie
• Welche Libraries verboten oder bevorzugt sind
• Welche Security-Anforderungen immer gelten
• Was nie ohne Architecture Decision Record eingeführt werden darf

Ohne Constitution verhandelt jede Spec dieselben Grundfragen neu. Mit ihr hat der Agent einen stabilen Rahmen.

Eine Sache lohnt es besonders, explizit zu machen: gute Tests. Sie sollten die fachlichen Fälle abdecken und nicht nur die Coverage hochtreiben. Steht das nicht in den Regeln, schreibt der Agent Tests, die zwar grün sind, aber nichts beweisen.

Steht die Constitution, beginnt der eigentliche Zyklus. Er läuft in zwei Phasen, und der Schwerpunkt liegt klar auf der ersten. Das Verhältnis kippt gegenüber früher: Der Großteil der Zeit fließt ins Planen, nicht ins Tippen. Michael etwa plant den überwiegenden Teil seiner Zeit.

Aus Ticket, Kontext und eigenen Überlegungen entsteht im Dialog mit der AI ein Plandokument. Das schärft ihr iterativ nach, wie eine Hausarbeit, die ein Lehrer mit dem Rotstift durchgeht: Das müssen wir nachschärfen, das anders formulieren. Diesen Loop wiederholt ihr, bis der Plan solide steht. Diese Phase ist die eigentliche Denkarbeit. Erst danach geht es in die Umsetzung.

Der fertige Plan geht an die Entwicklungs-KI, bei Michael ist das OpenCode mit verschiedenen KI-Modellen. Der Agent arbeitet ihn ab, führt Tests aus und prüft das Ergebnis gegen die Anforderungen. Bei kleinen, klar abgegrenzten Features geht das direkt. Bei größeren wird der Plan vorher in kleine, teils parallel abarbeitbare Schritte zerlegt, die ein günstigeres Modell wie ein Juniorentwickler nacheinander umsetzt.

Diese Zerlegung ist in der Praxis sehr hilfreich, und sie hat vier Gründe:

1. Kontext sauber halten. Kippt man eine ganze Spec auf einmal in ein großes Modell, verwässert der Kontext, und die Qualität sinkt. Kleine Häppchen halten den Fokus scharf.
2. Kosten senken. Das teure Flaggschiffmodell nutzt man für den Plan, die einzelnen Schritte erledigt ein günstigeres Modell.
3. Ausfallsicherheit. Stürzt bei einem riesigen Ein-Schritt-Lauf etwas mittendrin ab, muss der ganze Kontext neu zusammengesucht werden. Stirbt in einer Taskliste ein kleiner Schritt, macht der nächste einfach weiter.
4. Klare Kanten. Jeder Schritt ist bewusst ausführlich beschrieben, damit es definierte Ankerpunkte gibt, falls zwischendrin etwas holpert.

Ein eigenes Produkt braucht SDD nicht, im Kern sind es Dateien im Repository. Es gibt aber strukturierte Ansätze, die den ganzen Ablauf rahmen, der bekannteste ist das frei nutzbare GitHub Spec Kit, dazu unten mehr. Trotzdem hilft es zu sehen, welches Werkzeug welchen Abschnitt des Weges übernimmt. Die folgende Aufstellung ist Michaels Setup. Für jede Station gibt es Alternativen, und gerade rund um Spec Kit entsteht laufend Neues.

• Anforderung und Kontext: Jira. Ticket, Epic und benachbarte Stories sind der Ausgangspunkt. Andere Issue-Tracker wie Linear oder Azure DevOps erfüllen denselben Zweck.
• Kontext konsolidieren: Product Copilot. Ein KI-Tool für Jira und Confluence, das über MCP an die Entwicklungs-KI angebunden wird, das Ticket aufnimmt und relevanten Kontext heraussucht. Ähnliches leisten andere MCP-Anbindungen an Jira und Confluence.
• Plan schreiben und schärfen: das Plannotator-Plugin. Ein kostenloses Open-Source-Tool, das sich in den Plan-Modus des Agenten einklinkt. Statt den vorgeschlagenen Plan im Terminal zu überfliegen, geht man ihn auf einer übersichtlichen Oberfläche durch: Textstellen markieren, kommentieren, streichen. Das Feedback geht lokal direkt zurück an den Agenten. Wer es schlichter mag, nutzt einfach den eingebauten Plan-Modus des Agenten.
• Umsetzen: die Entwicklungs-KI. Michael ist das OpenCode mit verschiedenen KI-Modellen, es geht aber genauso mit Claude Code, Cursor, GitHub Copilot oder einem anderen agentischen Coding-Tool.
• Den ganzen Loop als Framework: GitHub Spec Kit. Bündelt Constitution, Specs und Tasks und legt alle Dokumente, die zur Entstehung eines Features geführt haben, dauerhaft im Repository ab. Genau hier wird die Spec zur lebenden Dokumentation, die mit dem Produkt mitwächst. Ehrlich dazugesagt: Spec Kit ist gründlich, aber token-hungrig und läuft lange, es lohnt sich eher für große, neue Konzepte als für einen kleinen Bugfix. Daneben gibt es viele weitere, ähnliche Frameworks.

Tipp: Spec-Driven Development im Brownfield

Viele SDD-Beispiele zeigen die grüne Wiese. Die meisten Engineering Teams haben jedoch keine grüne Wiese, sondern Legacy-Code vor sich und fragen zurecht: Wie funktioniert das mit einem gewachsenen Bestandssystem? Unser Kollege Marcel Schiffel ist genau dem nachgegangen. Das Ergebnis: Mit ein paar Erweiterungen lässt sich Spec Kit nutzen, um aus einer bestehenden Codebasis erst einmal Specs zurückzugewinnen (Reverse Engineering) und von dort in den normalen Spec-Driven-Loop einzusteigen. An einem internen Testrepo hat das erstaunlich gut funktioniert, nun nutzen sie den Ansatz in ersten Kundenprojekten. Den Einstieg findet ihr über die Brownfield-Erweiterung der Spec-Kit-Community. Einen zweiten Ansatz, den es sich anzuschauen lohnt, bietet die BMAD-Methode. Weitere Tipps für agentisches Arbeiten und wie ihr KI auch in Legacy-Code-Projekten erfolgreich einsetzen könnt, haben wir in einem anderen Blogartikel beschrieben.

Bleiben die Fragen, die beim Einbau in den Alltag am häufigsten aufkommen.

Viele Teams haben über Jahre einen Arbeitsmodus fürs agile Arbeiten entwickelt. Wer nach Scrum arbeitet, hat oft ein Backlog und ein Sprint Board, Refinements und Plannings, um Anforderungen zu definieren. Jetzt kommt Spec-Driven Development um die Ecke, und viele fragen sich, wie das zusammenpasst und ob die bestehenden Arbeitsweisen ersetzt werden müssen. Die Antwort ist: nein.

Gut geführte User Stories in Jira haben bereits eine Beschreibung der Anforderung, Akzeptanzkriterien, Out-of-Scope-Definitionen. Das ist deine gute Grundlage für SDD.

Der Unterschied liegt nicht im Was, sondern im Wo und Wie. Ein Jira-Ticket lebt im Backlog, wird diskutiert, verfeinert, priorisiert und dient Teams als Planungsinstrument. Die Spec dagegen ist ein Implementierungsartefakt. Sie lebt im Repository, versioniert neben dem Code, und ist direkt der Input für den Agenten.

So sieht das bei Michael konkret aus: Ausgangspunkt ist das Jira-Ticket. Product Copilot, das er über MCP mit seiner Coding-KI verbunden hat, nimmt es auf und sucht relevanten Kontext aus Confluence oder zugehörigen Epics und anderen Stories heraus. Aus diesem konsolidierten Kontext entsteht im Gespräch mit OpenCode der Plan.

Je besser das Ticket, desto weniger Klärungsaufwand in der Plan-Phase. Teams, die bereits in gute Anforderungsarbeit investieren, spüren das direkt.

Was sich ändert, ist also nicht die Anforderungsarbeit an sich, sondern wo das Ergebnis landet: nicht als Ticket, das beim Merge Request schon niemand mehr liest, sondern als Spec, die der Agent versteht und gegen die er seinen Output prüft.

Eine häufige Sorge ist: "Das klingt nach sehr viel Schreibarbeit." Das stimmt so nicht. So sieht die tatsächliche Aufgabenverteilung aus:

Der Engineer oder PM:

• Beschreibt in natürlicher Sprache, was das Feature tun soll, also das, was ohnehin im Ticket steht (das auch über einen MCP-Server als Basis für den Agenten dienen kann)
• Beantwortet gezielte Klärungsfragen des Agenten
• Reviewt die generierte Spec und gibt sie frei
• Reviewt den technischen Plan vor der Implementierung
• Reviewt den generierten Code

Der Agent:

• Leitet aus dem Ticket bzw. dem Input des Engineers die strukturierte Spec ab
• Formuliert die Akzeptanzkriterien aus
• Stellt Klärungsfragen bei unklarem Input
• Erstellt den technischen Plan (Datenmodell, API-Kontrakte, Architektur)
• Implementiert, führt Tests aus, iteriert

Der Mensch denkt und entscheidet. Der Agent strukturiert, schreibt und implementiert. Es ist aber definitiv eine andere Art von Softwareentwicklung, als die meisten Teams sie bisher gewohnt sind und bedeutet für Engineers, dass sie jetzt mehr Anforderungen schreiben als Code. Das fällt nicht jedem leicht, und das muss man auch dazu sagen.

Über-Spezifikation: Implementierungsdetails in die Spec schreiben. Die Spec beschreibt Verhalten, Fehlerfälle und Constraints, die Implementierung ist Aufgabe des Plans.

Unter-Spezifikation: "Es soll gut performen" ist keine testbare Anforderung. Ohne klare, prüfbare Kriterien hat der Agent keinen Anker. Ein bewährter Weg, Kriterien testbar zu formulieren, ist die EARS-Notation, eine einfache Schablone für Anforderungssätze.

Constitution überspringen: Ohne Constitution verhandelt jede Spec dieselben Grundregeln neu.

Spec außerhalb des Repos: Specs in Notion oder Confluence veralten innerhalb eines Sprints. Sie gehören ins Repository, versioniert mit dem Code.

Keinen Menschen an Phasenübergängen: Spec reviewen, Plan reviewen, Code reviewen. Wer das überspringt, bekommt Vibe Coding mit Spec-Maske.

Engineers verbringen weniger Zeit mit Implementierungsdetails, die AI zuverlässig abdeckt: Boilerplate, Standard-Endpoints, Unit Tests für klar beschriebene Funktionen. Sie verbringen mehr Zeit mit dem, was AI nicht alleine kann: Architekturentscheidungen mit Systemverständnis treffen, Specs so schreiben, dass kein Interpretationsspielraum bleibt, AI-Output gegen fachliche Korrektheit prüfen.

Für Michael ist diese Verschiebung radikal.

Seit Anfang des Jahres habe ich keine Zeile Code mehr selbst geschrieben, vielleicht zwei. – Michael Pehl

Dahinter steckt keine Bequemlichkeit, sondern eine nüchterne Selbsteinschätzung.

Ich gehöre zu der Fraktion, die nicht Code entwickelt, um Code zu schreiben, sondern die Software entwickelt, damit Dinge funktionieren. Die KI bildet meine Anforderung inzwischen besser ab, als ich es tippen würde. Was mir wichtig ist, steht drin, und der Rest ist oft besser als das, was ich geschrieben hätte. – Michael Pehl

Das ist keine Verschiebung weg vom Engineering, sondern hin zu dem, was ohnehin die schwierigere und wertvollere Arbeit ist und bisher oft zu kurz kam, weil die Implementierung so viel Zeit gefressen hat. Michael bringt es auf einen Punkt: Das Planen ist das neue Tun.

Ein Risiko bleibt, das Tech Leads ernst nehmen sollten: Entwickler, die nicht genau hinschauen, laufen Gefahr, von der AI geführt zu werden statt andersrum. Genau deshalb ist der Aufbau von SDD-Kompetenz eine Führungsaufgabe, keine, die man einfach laufen lässt.

Bei DevBoost haben wir schon viele Softwareteams bei ihrer AI Adoption und dem Aufbau von funktionierenden KI Setups begleitet. In unseren AI Bootcamps führen wir Teams systematisch in die effiziente Nutzung von AI im Engineering ein. Für Tech Leads und alle, die Verantwortung für die Engineering Prozesse ihres Teams oder Unternehmens übernehmen, haben wir ein 6-monatiges AI Enablement Programm entwickelt, das euch nachhaltig dabei unterstützt, agentisches Arbeiten zum Default in euren Teams zu machen. Meldet euch, wenn ihr bereit seid, AI effizient und nachhaltig in eure Arbeitsweise zu integrieren. Wir schauen gemeinsam mit euch, wo ihr steht, was die größten Hebel sind und ob wir euch dabei helfen können.