Spec-Driven Development erklärt

Spec-Driven Development dreht die Reihenfolge um: Zuerst entsteht eine präzise, überprüfbare Spezifikation – dann erst der Code. Die Spezifikation ist die zentrale Wahrheit, der Code ihre Umsetzung. Mit KI-Agenten, die Code in großer Menge erzeugen, gewinnt dieser alte Gedanke stark an Bedeutung: Wer dem Agenten nur einen vagen Wunsch mitgibt, bekommt schnell etwas, das gut aussieht, aber nicht das Richtige tut. Dieser Beitrag erklärt, was Spec-Driven Development ist, wo die Vor- und Nachteile liegen und wie Kunden und IT davon profitieren.

Inhaltsverzeichnis

• Was ist Spec-Driven Development? 📝
• Woraus besteht eine gute Spezifikation? 🧱
• Der Ablauf im Überblick 🔁
• Warum gerade jetzt? Spezifikation und KI-Agenten 🤖
• Vorteile ✅
• Nachteile und Grenzen ⚠️
• Wie Kunden profitieren 🤝
• Wie die IT profitiert 🛠️
• Abgrenzung: Spec-Driven, TDD und Vibe Coding 🔍
• Wann lohnt sich der Ansatz? 🧭
• Häufige Fragen (FAQ) ❓
• Fazit: Erst klären, dann bauen 🎯

Was ist Spec-Driven Development? 📝

Bei Spec-Driven Development (SDD) beschreibt man was ein System tun soll und woran man erkennt, dass es das tut, bevor man festlegt oder generiert, wie es gebaut wird. Die Spezifikation ist kein Dokument, das nach dem Kickoff in der Schublade verschwindet, sondern ein lebendiges Artefakt im Repository: versioniert, geprüft und bei jeder Änderung aktualisiert.

Der Kerngedanke:

Die Spezifikation ist die Quelle der Wahrheit. Code, Tests und Dokumentation werden daraus abgeleitet – von Menschen oder von KI-Agenten.

Das ist nicht neu. Lastenhefte, User Stories mit Akzeptanzkriterien und API-Beschreibungen wie OpenAPI verfolgen dasselbe Ziel. Neu ist, dass sich Spezifikationen heute so strukturieren lassen, dass Agenten sie direkt als Arbeitsgrundlage nutzen können.

Woraus besteht eine gute Spezifikation? 🧱

Eine Spezifikation muss nicht lang sein, aber eindeutig und prüfbar. Bewährt haben sich diese Bestandteile:

Ein einfaches Beispiel für ein prüfbares Akzeptanzkriterium im Given-When-Then-Stil:

## Rechnung herunterladen

Gegeben ein angemeldeter Kunde mit mindestens einer Rechnung
Wenn er die Rechnung "R-2026-001" anfordert
Dann erhält er die PDF-Datei mit Status 200

Gegeben ein angemeldeter Kunde
Wenn er die Rechnung eines anderen Kunden anfordert
Dann erhält er Status 403 und der Zugriff wird protokolliert

Schwammige Aussagen wie „soll schnell und benutzerfreundlich sein“ sind keine Spezifikation – sie lassen sich weder testen noch streitfrei abnehmen.

Der Ablauf im Überblick 🔁

Der Prozess besteht aus aufeinander aufbauenden Stufen, wobei nach jeder Stufe ein Mensch prüft, bevor die nächste beginnt:

Wichtig ist die Rückkopplung: Stellt sich bei der Umsetzung heraus, dass die Spezifikation lückenhaft oder falsch war, wird zuerst die Spezifikation korrigiert – nicht nur der Code. Sonst driften beide auseinander, und der Vorteil ist verloren.

Warum gerade jetzt? Spezifikation und KI-Agenten 🤖

Ein KI-Agent arbeitet so gut, wie seine Aufgabe beschrieben ist. Er kann Code in Minuten erzeugen – aber er kann nicht erraten, was man meint. Fehlt die Information, füllt er die Lücke mit einer plausiblen Annahme. Manchmal passt sie, oft nicht, und man merkt es erst spät.

Eine gute Spezifikation löst dieses Problem an der Wurzel:

• Eindeutiger Auftrag: Der Agent weiß, was gewollt ist und was nicht
• Objektive Fertig-Definition: Akzeptanzkriterien werden zu Tests, an denen der Agent seine Arbeit selbst überprüfen kann
• Kleine Pakete: Aus der Spezifikation entstehen Aufgaben, die sich einzeln delegieren und prüfen lassen
• Reproduzierbarkeit: Bei einem Modellwechsel oder einem Neustart lässt sich dieselbe Spezifikation erneut umsetzen

Damit ist Spec-Driven Development die natürliche Grundlage für Agentic Development: Der Mensch konzentriert sich auf das Was, der Agent übernimmt große Teile des Wie, und die Spezifikation verbindet beides. Es ist zugleich das Gegenmodell zum reinen Vibe Coding, bei dem der Wunsch vage bleibt und das Ergebnis dem Zufall überlassen wird.

Vorteile ✅

• Gemeinsames Verständnis vor dem ersten Code. Missverständnisse fallen auf, solange sie noch nichts kosten
• Prüfbare Abnahme. „Fertig“ ist kein Bauchgefühl, sondern ein Testergebnis
• Bessere Ergebnisse mit KI. Präzise Vorgaben senken Nacharbeit, Tokenverbrauch und Rückfragen
• Nachvollziehbarkeit. Zu jeder Funktion gibt es eine dokumentierte Begründung – hilfreich für Audits, NIS2 und Compliance
• Wissen bleibt im Unternehmen. Neue Teammitglieder und neue Dienstleister verstehen das System anhand der Spezifikation, nicht nur anhand des Codes
• Leichtere Änderungen. Man ändert die Spezifikation, leitet Anpassungen daraus ab und erkennt Auswirkungen früher
• Unabhängigkeit von Werkzeugen. Die Spezifikation überlebt den Wechsel von Programmiersprache, Framework oder KI-Modell
• Parallele Arbeit. Frontend, Backend und Tests können gleichzeitig auf Basis derselben Schnittstellenbeschreibung entstehen

Nachteile und Grenzen ⚠️

• Höherer Aufwand am Anfang. Wer klärt, bevor er baut, startet langsamer. Der Gewinn zeigt sich erst später
• Gute Spezifikationen sind schwer. Eindeutig, vollständig und trotzdem knapp zu schreiben, ist eine Fähigkeit, die man üben muss
• Gefahr von Papierbergen. Zu detaillierte Dokumente werden nicht gelesen und veralten – im schlimmsten Fall entsteht ein neues „Wasserfall-Modell“
• Spezifikation und Code driften auseinander. Wird die Spezifikation nicht mitgepflegt, wird sie zur Fehlinformation
• Nicht alles lässt sich vorab festlegen. Bei echter Unsicherheit – neue Produkte, unklare Nutzerbedürfnisse – lernt man erst durch Ausprobieren
• Scheinsicherheit. Eine Spezifikation, die erfüllt ist, garantiert nicht, dass sie das Richtige beschreibt. Auch sie kann falsch sein
• KI bleibt nicht deterministisch. Dieselbe Spezifikation kann zu unterschiedlichem Code führen. Tests und Reviews bleiben Pflicht
• Werkzeuge sind noch jung. Methoden und Tools entwickeln sich schnell; eine feste Standardlösung gibt es nicht

Gegenmittel: Spezifikationen klein halten, pro Feature statt pro Gesamtsystem schreiben, sie im selben Repository wie den Code ablegen und Änderungen nur über Reviews zulassen. Für unklare Vorhaben zuerst einen kurzen Prototyp bauen und danach spezifizieren.

Wie Kunden profitieren 🤝

Für Auftraggeber und Fachbereiche ist die Spezifikation das Stück, das sie wirklich verstehen und beeinflussen können – anders als den Code:

• Mitsprache an der richtigen Stelle. Man diskutiert Verhalten in verständlicher Sprache, bevor Geld in Programmierung fließt
• Planbarkeit. Umfang, Abgrenzung und Abnahmekriterien stehen vorab fest; das reduziert Nachträge und Streit über „war so nicht gemeint“
• Transparente Abnahme. Jedes Kriterium ist belegbar erfüllt oder nicht
• Weniger Abhängigkeit. Die Spezifikation gehört dem Kunden. Ein Dienstleisterwechsel ist leichter, weil das Wissen dokumentiert ist
• Schnellere Lieferung bei Änderungen. Wer die Vorgaben anpasst, bekommt gezielte Änderungen statt langer Rückfragerunden
• Nachweise für Audits. Anforderungen, Umsetzung und Tests sind miteinander verknüpft

Wie die IT profitiert 🛠️

Für Entwicklung, Betrieb und Security bringt der Ansatz handfeste Erleichterungen:

• Weniger Rätselraten. Entwickler und Agenten bekommen eindeutige Aufträge statt Halbsätze im Ticket
• Tests aus Akzeptanzkriterien. Automatisierte Tests entstehen direkt aus der Spezifikation und laufen in der CI-Pipeline mit
• Bessere Reviews. Man prüft den Code gegen eine Vorgabe – nicht gegen eine unausgesprochene Erwartung
• Sicherheit von Anfang an. Sicherheits- und Betriebsanforderungen (Protokollierung, Rechte, Performance) stehen in der Spezifikation und gehen nicht unter
• Kleinere, prüfbare Änderungen. Aufgaben werden zerlegt; Merge Requests bleiben überschaubar
• Skalierbare Delegation an Agenten. Mehrere Agenten können parallel auf Basis klarer Teilaufgaben arbeiten
• Weniger Altlasten. Dokumentation entsteht vor dem Code und nicht als lästige Pflicht danach

Abgrenzung: Spec-Driven, TDD und Vibe Coding 🔍

Die Ansätze schließen sich nicht aus. Eine Spezifikation legt fest, was gewollt ist, Tests (auch aus dem Test-Driven-Ansatz) prüfen es automatisch, und der Code wird von Menschen oder Agenten dazu geschrieben.

Wann lohnt sich der Ansatz? 🧭

Häufige Fragen (FAQ) ❓

Ist Spec-Driven Development das alte Wasserfall-Modell? Nein. Wasserfall spezifiziert das gesamte Projekt vorab. Spec-Driven Development arbeitet in kleinen Schritten, pro Feature, mit schneller Rückkopplung und lebendigen Spezifikationen.

Wie lang sollte eine Spezifikation sein? So kurz wie möglich, so genau wie nötig. Oft genügen ein bis zwei Seiten pro Feature. Entscheidend ist die Prüfbarkeit, nicht der Umfang.

Wer schreibt die Spezifikation? Am besten gemeinsam: Fachbereich bringt Ziel und Regeln ein, die IT Randfälle und technische Leitplanken. KI kann Entwürfe erstellen, die Verantwortung bleibt beim Menschen.

Kann KI die Spezifikation auch selbst schreiben? Als Entwurf ja – etwa durch Rückfragen und Strukturierung. Die inhaltliche Prüfung muss ein Mensch übernehmen, denn die KI kennt weder Geschäftsziele noch Randbedingungen vollständig.

Wo legt man Spezifikationen ab? Im selben Git-Repository wie den Code, als Markdown-Dateien oder in maschinenlesbaren Formaten. So werden sie versioniert und im Review mitgeprüft.

Braucht man dafür besondere Software? Nicht zwingend. Ein Repository, Markdown, eine CI-Pipeline und Disziplin genügen für den Anfang. Spezialisierte Werkzeuge können später unterstützen.

Fazit: Erst klären, dann bauen 🎯

Spec-Driven Development verlagert Mühe an die Stelle, an der sie am wenigsten kostet: vor den Code. Kunden erhalten Planbarkeit und echte Mitsprache, die IT bekommt eindeutige Aufträge und prüfbare Ergebnisse. Besonders im Zusammenspiel mit KI-Agenten ist die Spezifikation das, was aus einem schnellen Textgenerator einen verlässlichen Mitarbeiter macht. Entscheidend ist das richtige Maß: kleine, lebendige, prüfbare Spezifikationen statt schwerer Papierberge.

Wer Spec-Driven Development im eigenen Unternehmen einführen oder Anforderungen für ein Projekt sauber aufbereiten möchte, findet in einem unverbindlichen Gespräch den passenden Einstieg – hier Kontakt aufnehmen.