Technik · 30.09.2026

Spec-driven Development: Der Plan, der dem Code vorausgeht

Vibe Coding lässt Sprachmodelle drauflos programmieren. Spec-driven Development gibt ihnen vorher einen Fahrplan. Warum die Idee ein Jahr nach ihrem Auftauchen schon ein eigenes Paradigma ist — und welche Werkzeuge es dafür gibt.

Wer KI-Coding-Agenten freie Hand lässt, kennt das Muster: plausibler Code auf Basis erfundener APIs und falscher Annahmen. Anfang 2025 wuchs deshalb eine Gegenbewegung: Statt dem Modell zu erlauben, zu raten, schreibt man vor dem Programmieren eine maschinenlesbare Spezifikation — die Spec wird zur einzigen Wahrheit (Single Source of Truth) für Code, Tests und Dokumentation. Der Codier-Agent bekommt die Anweisung, das Team die Doku, die Tests die Grundlage. Ein Planungsartefakt, vier Aufgaben gleichzeitig.

Von der Idee zum Reifegrad

Der kreative Kern dieser „Specs" liegt im Detail: Anstatt das System in Technologie-Jargon zu beschreiben, formulieren sie Regeln in domänennaher Sprache — welche Bedingungen gelten müssen, was vorher und nachher erlaubt ist, welche Grenzen der Agent nie überschreiten darf. Je nach Werkzeug reift der Ansatz über drei Stufen: einmalig vor der Entwicklung notiert (Spec-first), im Entwicklungsprozess fortgeschrieben (Spec-anchored) oder als einziges bearbeitbares Artefakt, während Code nur noch generiert wird (Spec-as-Source).

Fünf Werkzeuge, eine Idee

Bei aller Gemeinsamkeit unterscheiden sich die Umsetzungen deutlich. Vom ursprünglichen Microsoft-Framework SpecKit bis zum kompakten OpenSpec mit seinen „Delta Specs" für laufende Änderungen reichen die Eckpfeiler. BMAD simuliert ein ganzes agiles Team aus neun Agenten und deckt den kompletten Produktlebenszyklus ab, während GSD (Get Shit Done) bewusst das Gegenteil tut: schlank, ohne agile Zeremonien, für Solo-Entwickler. Kiro wählt einen dritten Weg und verpackt die Methodik komplett in eine eigene IDE.

Die Auswahl ist also weniger eine Frage von „richtig oder falsch" als von Arbeitsweise: Wer umfangreiche Produkte plant, findet bei BMAD die Struktur; wer kontinuierlich bestehende Software weiterentwickelt, bei OpenSpec; wer schnell pragmatisch umsetzen will, bei GSD; wer eine fertige Umgebung bevorzugt, bei Kiro.

Was in der Praxis bleibt

Alle Werkzeuge haben einen gemeinsamen blinden Fleck: Die Spec ist kein Schutz vor schleichendem Auseinanderdriften von Plan und Code (Spec Drift) und auch nicht vor Halluzinationen. Deterministische Tests und CI/CD bleiben deshalb Pflicht. Richtig eingesetzt, verwandeln SDD-Werkzeuge den Codier-Vorgang aber von einem Würfelspiel in einen gelenkten Prozess — mit einem Papierstapel als Kompass.