Spec-Driven-Development

Die Verlockung von Large Language Models (LLMs) im Entwicklungsalltag ist riesig: Ein kurzer Prompt im Chat, und Sekunden später steht eine lauffähige Ad-hoc-Lösung bereit. Doch dieser Fokus auf die schnelle Umsetzung hat seinen Preis. Was kurzfristig wie ein massiver Produktivitätsschub aussieht, rächt sich schnell durch mangelnde Wartbarkeit, fehlende Stabilität und das Fehlen einer klaren architektonischen Richtung.

An dieser Stelle setzt das Paradigma des Spec-Driven Developments (SDD) an. Specs waren schon immer mehr als nur staubige Dokumentation: Sie definieren die Anforderungen. Im Zeitalter der KI-gestützten Entwicklung werden sie nun zu einer dynamischen Denkschicht und dem zentralen, geteilten Kontext zwischen Entwickler und Modell.

Die drei typischen Fallstricke der chat-basierten Entwicklung

Wer komplexe Features ausschließlich über interaktive Prompts in einer spontanen Chat-Session entwickelt, baut unbewusst technische Schulden auf. Das liegt nicht an einer generellen Schwäche der LLMs – mit dem passenden Kontext arbeiten diese extrem präzise. Das Problem ist vielmehr das unstrukturierte „Vibe Coding“ ohne festen Rahmen. Ohne ein klares, konsistentes Gerüst wird das Modell mit zersplitterten Informationen gefüttert, wodurch der Blick für das große Ganze und die langfristige Stabilität des Gesamtsystems verloren geht.

Beim intuitiven „Vibe Coding“ im Chat stolpert man meist über drei typische Probleme:

• Fragmentierte Architekturentscheidungen (Fragmented Design Decisions): Da ein Feature meist über mehrere Chat-Sessions hinweg entwickelt wird, werden Entscheidungen. Wichtige Weichenstellungen fließen zwar implizit in den generierten Code ein, sind aber nirgends als explizite Anforderung festgehalten oder versioniert.
• Abweichung vom Pfad (Prompt Drift): Im Eifer des Gefechts neigt man dazu, nur noch reaktiv auf die Code-Vorschläge der KI einzugehen. Statt das eigentliche Architekturziel konsequent zu verfolgen, lässt man sich vom Fluss des Chats treiben und verliert die ursprüngliche Richtung aus den Augen.
• Ungesagte Annahmen (Hidden Assumptions): Lücken in den Anforderungen (Underspecified Gaps) füllt das LLM eigenständig mit impliziten Annahmen auf. Diese unaufgelösten Widersprüche und Fehlinterpretationen bemerkt man oft erst viel zu spät – meistens erst bei der Systemintegration.

Die Spec als aktiver „Shared Context“

Spec-Driven Development löst dieses Problem, indem es die Spezifikation der Anforderungen zeitlich vor die eigentliche Code-Generierung stellt. Sie dient als expliziter, versionierter und geteilter Kontext (Shared Context) zwischen dem Software Engineer und dem LLM, bevor auch nur eine Zeile Code geschrieben wird.

Was zeichnet eine effektive Spec im SDD-Umfeld aus?

• Das Was steht vor dem Wie: Sie beschreibt präzise die fachlichen Anforderungen und die Geschäftslogik. Die KI kümmert sich um die technische Umsetzung, anstatt die Logik selbst erraten zu müssen.
• Nachvollziehbarkeit der Entscheidungen (Rationale): Sie dokumentiert, warum bestimmte Pfade gewählt und andere verworfen wurden (ähnlich wie klassische Architecture Decision Records).
• Umgang mit Unbekannten: Offene Fragen (Unknowns) werden explizit festgehalten, anstatt sie von der KI blind wegdiskutieren zu lassen.
• Klare Grenzen (Out-of-Scope): Die Spec definiert haargenau, wo das Feature endet. Das hindert das LLM daran, eigenmächtig über das Ziel hinauszuschießen.

Die Evolution der Spec: Von Martin Fowler bis zur Praxis

Wie tief die Anforderungen in den KI-gestützten Entwicklungszyklus integriert werden, lässt sich hervorragend anhand der Taxonomie von Martin Fowler (2025) verdeutlichen:

• Spec-First: Die Anforderungen werden vor der Implementierung sauber aufgeschrieben und dienen der KI als präziser Input. Nach der Code-Generierung wird die Spec oft nicht weiter gepflegt.
• Spec-Anchored: Die Anforderungen liegen als Markdown-Dateien direkt im Git-Repository. Sie entwickeln sich im Laufe des Projekts weiter und dienen über verschiedene Sessions hinweg als fester Anker für Refactorings und Erweiterungen.
• Spec-as-Source: Die ultimative Stufe. Die Spezifikation ist das einzige Artefakt, das noch aktiv vom Menschen editiert wird, während der Code direkt daraus generiert wird (oftmals ohne manuelles Review).

Von der Theorie zur Praxis: SpecKit

Die methodischen Ansätze sind das eine, doch wie sieht das Ganze in der Praxis aus? Für die Umsetzung des Spec-Driven Development Workflows existieren mittlerweile mehrere Frameworks – etwa OpenSpec oder SpecKit – die jeweils eigene Schwerpunkte setzen. Ich greife hier exemplarisch SpecKit heraus, ein Command-Line-Tool, das genau diesen Workflow über strukturierte Befehle für deinen KI-Coding-Assistenten erzwingt. Die vorgestellten Prinzipien lassen sich aber genauso auf die anderen Tools übertragen.

Der Workflow von SpecKit gliedert sich in fünf aufeinander aufbauende Phasen, die den Entwicklungsprozess leiten und jeweils reviewbare Artefakte erzeugen:

1. Specify (speckit.specify)

Hier werden High-Level-User-Stories in eine standardisierte und maschinenlesbare Anforderungsliste (spec.md) überführt.

2. Clarify (speckit.clarify)

Lücken in den User Stories werden nicht stillschweigend von der KI interpretiert. Stattdessen triggert dieser Befehl eine strukturierte Q&A-Runde, um ungesagte Annahmen und Edge-Cases vorab zu klären.

3. Plan (speckit.plan)

Es wird ein detaillierter technischer Umsetzungsplan generiert. Das Ergebnis sind zwei wesentliche Dokumente:

• research.md: Eine strukturierte Analyse komplexerer Probleme (z. B. Chunking-Strategien bei langen osTicket-Verläufen).
• contracts/: Festgelegte Daten- und API-Schnittstellenspezifikationen, die im Vorfeld wie ein starres Schema definiert werden.

4. Tasks (speckit.tasks)

Der Plan wird in eine konkrete, schrittweise Task-Liste (tasks.md) überführt. Aufgaben, die parallel gelöst werden können, erhalten einen Marker ([P]), was die Arbeitsteilung unter verschiedenen Sub-Agenten ermöglicht.

5. Implement (speckit.implement)

Erst nach dieser lückenlosen Vorbereitung wird der eigentliche Code generiert. Das LLM arbeitet nun nicht mehr im luftleeren Raum, sondern baut den Code entlang der exakt definierten Tasks und Verträge.

Abwägung: Was bringt uns das?

Der Mehrwert (Value)	Die Investition (Investment)
Klare Trennung der Absichten (Separated Intent): Logik und Anforderungen (Was) werden sauber von der reinen Code-Syntax (Wie) getrennt.	Standardisierungs-Hürden: Es gibt noch keinen allgemeingültigen Industriestandard für KI-Spezifikationen.
Lebendige Dokumentation: Da Anforderungen und Schnittstellen-Spezifikationen im Repository leben, spiegeln sie immer den echten Systemzustand wider.	Initialer Mehraufwand (Setup Overhead): Das Einrichten strukturierter Prozesse und das Formulieren der Specs benötigt anfangs mehr Zeit als ein schneller Chat-Prompt.
Konsistenter Kontext: Prompt Drift und das Verzetteln in langen, unübersichtlichen Chat-Verläufen gehören der Vergangenheit an.	Pflegeaufwand (Maintenance Debt): Nimmt man Abkürzungen und ändert Code direkt, veraltet die Spec und verliert ihren Wert.
Perfekt für die Kommunikation: Da die fachliche Logik textbasiert festgehalten ist, lässt sie sich hervorragend mit nicht-technischen Stakeholdern besprechen.	Höherer Token-Verbrauch: Das ständige Übergeben des gesamten Spec-Kontexts an das LLM sowie die Generierung der Specs erhöht die API-Kosten.

Fazit: Welches Tooling-Level ist das richtige für dich?

Spec-Driven Development bedeutet nicht, dass man für jede kleine Änderung ein riesiges Framework anwerfen muss. Wichtig ist, die Tiefe des Toolings an die Komplexität anzupassen:

• Level 0 (Keine Spec): Perfekt für schnelle, isolierte Ad-hoc-Bugs, bei denen Stabilität und Richtung keine Rolle spielen.
• Level 1 (LLM-Planung nutzen): Gut für mittlere Aufgaben, bei denen man die KI vorab um einen strukturierten Plan bittet, ohne diesen zwingend abzuspeichern.
• Level 2 (Markdown Templates): Ideal für Solo-Entwickler, die ihre Anforderungen in standardisierten Markdown-Dateien im Git pflegen wollen.
• Level 3 (Dedizierte Spec-Tools): Der Goldstandard für komplexe Features und die Arbeit im Team. Tools wie SpecKit oder OpenSpec garantieren, dass alle Agenten und Entwickler an derselben Wahrheit arbeiten.

Am Ende des Tages ist das exakte Format zweitrangig. Wichtig ist nur der mentale Shift: Erst explizit denken und spezifizieren, dann generieren lassen.