Spec-Driven Development: Gute KI-Software beginnt mit der Spezifikation

„Bau mir ein Werkzeug, mit dem wir Reklamationen erfassen." Das ist ein vollständiger Auftrag für einen KI-Agenten, und er wird ihn ausführen. Nach einer Stunde gibt es ein Formular, eine Liste und ein Statusfeld. Was es nicht gibt, sind Antworten auf die Fragen, die in deinem Betrieb eigentlich entscheiden. Wer bekommt die Reklamation auf den Tisch? Ab wann muss die Qualitätsleitung draufschauen? Was passiert, wenn derselbe Kunde zum dritten Mal wegen desselben Teils anruft?

Der Agent hat das alles nicht gefragt, sondern geraten. Genau dagegen gibt es eine Methode, die seit 2025 unter dem Namen Spec-Driven Development Karriere macht: Erst wird aufgeschrieben, was gebaut werden soll, dann baut die KI. Die Spezifikation ist die Quelle der Wahrheit, nicht der Chatverlauf und nicht der Code.

Dieser Beitrag erklärt, was hinter dem Begriff steckt, woher er kommt, welche Werkzeuge es gibt und wie eine gute Spezifikation aussieht. Und er zeigt, warum der wertvollste Teil davon nicht vom Entwickler kommt, sondern von dir.

Was Spec-Driven Development ist

Spec-Driven Development, auf Deutsch spezifikationsgetriebene Entwicklung, heißt: Bevor ein KI-Agent eine Zeile Code schreibt, gibt es ein Dokument, das festlegt, was die Software tun soll. Dieses Dokument ist die Grundlage für Mensch und KI gleichermaßen. Die Arbeit läuft in vier Schritten:

1. Spezifikation. Was soll die Software tun, für wen, und woran erkennt man, dass sie es richtig tut? In normaler Sprache, ohne Technik.
2. Plan. Wie wird das technisch umgesetzt: Aufbau, Datenbank, Anbindungen. Der Agent schlägt vor, ein Entwickler entscheidet.
3. Aufgaben. Der Plan wird in kleine Arbeitspakete zerlegt, die sich einzeln umsetzen und prüfen lassen.
4. Umsetzung. Der KI-Agent arbeitet die Aufgaben ab. Jedes Ergebnis wird gegen die Spezifikation geprüft.

Zwischen den Schritten steht jeweils ein Mensch, der liest und freigibt, bevor es weitergeht. Fehler in der Spezifikation fallen so auf, bevor sie in hundert Dateien stecken.

Entscheidend ist, was danach passiert. Birgitta Böckeler von der Beratung Thoughtworks unterscheidet in einer viel beachteten Analyse drei Stufen. Bei „Spec-first" wird die Spezifikation für eine Aufgabe geschrieben und danach vergessen. Bei „Spec-anchored" bleibt sie erhalten und wird bei jeder Weiterentwicklung mitgepflegt. Bei „Spec-as-source" bearbeitet der Mensch nur noch die Spezifikation und nie mehr den Code. Für ein internes Werkzeug im Mittelstand ist die mittlere Stufe die richtige: Die Spezifikation bleibt, und jede spätere Änderung beginnt dort, nicht im Chat mit dem Agenten.

Woher der Begriff kommt

Die Idee ist alt. Lastenhefte, Anforderungsdokumente, testgetriebene Entwicklung: Dass man vor dem Bauen festlegt, was gebaut wird, gehört seit Jahrzehnten zum Handwerk. Neu ist, wer die Spezifikation liest. Früher war es ein Entwickler, der Lücken bemerkt und nachgefragt hat. Heute ist es ein KI-Agent, der sich an das hält, was dasteht, und den Rest ergänzt.

Im KI-Zusammenhang ist der Begriff eine direkte Antwort auf Vibe Coding, das Andrej Karpathy im Februar 2025 benannt hatte: bauen lassen, ausprobieren, den Code gar nicht erst ansehen. Die Gegenbewegung kam schnell:

• Juni 2025: Sean Grove von OpenAI vertrat auf einer großen Entwicklerkonferenz in San Francisco die These, dass Code nur 10 bis 20 Prozent dessen ausmacht, was Programmierer eigentlich liefern. Der Rest sei strukturierte Kommunikation, und die schriftliche Spezifikation sei das eigentliche Arbeitsergebnis.
• Juli 2025: Amazon stellte Kiro als Vorschau vor, eine Entwicklungsumgebung, die aus einer Anfrage zuerst Anforderungen, einen Entwurf und eine Aufgabenliste macht und erst dann Code schreibt.
• September 2025: GitHub veröffentlichte das quelloffene Spec Kit und benannte das Problem ausdrücklich: Vage Anweisungen zwingen das Modell, unausgesprochene Anforderungen zu erraten.

Seitdem ist Spec-Driven Development der Sammelbegriff für alle Arbeitsweisen, bei denen die KI nicht aus einem Satz, sondern aus einer Spezifikation baut.

Welche Werkzeuge es gibt

Stand: September 2026 sind drei Werkzeuge besonders verbreitet. Dazu kommt der Weg ganz ohne Spezialwerkzeug.

Spec Kit legt vor der ersten Spezifikation eine Datei mit Grundsätzen an, die GitHub „Constitution" nennt: Regeln, die für jedes Vorhaben im Projekt gelten, etwa dass zuerst Tests geschrieben werden. Am Ende steht inzwischen ein Abgleichschritt, der prüft, ob das Ergebnis der Spezifikation entspricht. Umsetzung und Abgleich wiederholen sich, bis beides übereinstimmt.

Kiro erzeugt aus jeder Anfrage drei Dateien für Anforderungen, Design und Aufgaben. Die Anforderungen schreibt Kiro in einem festen Satzmuster: „WENN ein Ereignis eintritt, DANN SOLL DAS SYSTEM Folgendes tun." Dieses Muster ist auch ohne Kiro nützlich, du findest es unten im Beispiel wieder. Kiro hat eine kostenlose Stufe mit begrenztem Guthaben, die bezahlten Tarife beginnen bei 20 US-Dollar pro Nutzer und Monat (Stand: September 2026).

Das Werkzeug ist allerdings zweitrangig. Alle genannten Ansätze arbeiten mit einfachen Textdateien im Projektordner, die zusammen mit dem Code in der Versionskontrolle landen. Wer heute schon mit Claude Code oder Codex arbeitet, kann ohne zusätzliche Installation anfangen: Spezifikation als Datei anlegen, den Agenten im Planungsmodus einen Plan dazu erstellen lassen, den Plan lesen, dann bauen lassen.

Warum Spec-Driven Development das Gegenmittel zu Vibe Coding ist

Vibe Coding scheitert selten am ersten Tag. Es scheitert an vier Stellen, die sich mit der Zeit bemerkbar machen, und für jede hat Spec-Driven Development eine Antwort:

• Die KI rät, was du nicht gesagt hast. Die Spezifikation stellt die Fragen vorher: Randfälle, Rollen, Nicht-Ziele. Was entschieden ist, muss nicht geraten werden.
• Entscheidungen stehen nur im Chatverlauf. In der Spezifikation stehen sie in einer Datei, die bleibt, die jeder lesen kann und die nicht mit dem nächsten Chatfenster verschwindet.
• Niemand weiß, was „richtig" ist. Akzeptanzkriterien legen vorher fest, woran man ein korrektes Ergebnis erkennt. Aus ihnen werden Tests, und die Abnahme wird zur Prüfung statt zur Geschmacksfrage.
• Jede Änderung ist ein neuer Würfelwurf. Änderungen beginnen in der Spezifikation. Der Agent baut dann gegen einen festen Rahmen, statt einen neuen Wunsch auf einen unklaren Bestand zu setzen.

Den grundsätzlichen Unterschied zwischen beiden Arbeitsweisen habe ich an einem durchgehenden Beispiel in Vibe Coding oder KI-gestützte Softwareentwicklung beschrieben. Spec-Driven Development ist die Methode, mit der die zweite Variante im Alltag funktioniert. Und wer schon eine App per Vibe Coding gebaut hat, findet in der Prüfliste vor dem Livegang, was vor dem Einsatz geklärt sein sollte.

Wie eine gute Spezifikation aussieht

Eine gute Spezifikation für ein internes Werkzeug hat sieben Teile. Keiner davon erfordert technisches Wissen.

1. Ziel. Ein bis zwei Sätze: Welches Problem wird gelöst, und woran merkst du in drei Monaten, dass es gelöst ist? Ohne messbares Ziel lässt sich später nicht sagen, ob sich das Werkzeug gelohnt hat.

2. Nutzer und Rollen. Wer arbeitet damit, und wer darf was sehen, ändern, freigeben? Das ist der Teil, den eine KI am zuverlässigsten falsch rät, weil sie im Zweifel allen alles erlaubt.

3. Abläufe. Schritt für Schritt aus Sicht der Nutzer, der Normalfall zuerst. Wenn der Ablauf heute nur in Köpfen existiert, hilft ein Prozessdiagramm, bevor du ihn aufschreibst.

4. Akzeptanzkriterien. Prüfbare Sätze, am besten im Muster „WENN ..., DANN ...". Das ist der wichtigste Teil, denn daraus werden die Tests, und daran wird am Ende abgenommen.

5. Bewusste Nicht-Ziele. Was die Software ausdrücklich nicht tut. Das schützt vor einem Agenten, der hilfsbereit Funktionen dazubaut, die niemand bestellt hat und die trotzdem gepflegt werden müssen.

6. Daten. Welche Informationen erfasst werden, woher sie kommen, welche Angaben zwingend sind und wer was davon sehen darf.

7. Randfälle. Was passiert, wenn etwas fehlt, doppelt kommt, zu spät kommt oder jemand im Urlaub ist? Hier entscheidet sich, ob das Werkzeug den Alltag aushält.

Was nicht hineingehört: Programmiersprache, Datenbank, Server. Das kommt im Plan. Eine Spezifikation beschreibt das Was, der Plan das Wie. Für ein überschaubares internes Werkzeug reichen zwei bis vier Seiten. Wenn es nicht um eigene Software geht, sondern um einen KI-gestützten Ablauf, genügt oft die kürzere Form aus Anforderungen für ein KI-Projekt aufschreiben.

Ein Beispiel: Spezifikation für ein Reklamations-Werkzeug

So könnte die Spezifikation für das Werkzeug vom Anfang aussehen, verkürzt auf das Wesentliche. Der Betrieb ist ein angenommenes Beispiel: ein Zulieferer mit drei Produktlinien und einem Innendienst, der Reklamationen heute per Mail und Excel verfolgt.

Ziel. Jede Kundenreklamation ist an einem Ort erfasst, hat einen Zuständigen und einen Status. Die Qualitätsleitung sieht jederzeit, was offen ist und was sich wiederholt. Nach drei Monaten gibt es keine Reklamation mehr ohne Zuständigen.

Nutzer und Rollen.

• Innendienst: erfasst Reklamationen, sieht alle, bearbeitet eigene.
• Qualitätsleitung: weist zu, schließt ab, sieht die Auswertung.
• Fertigungsleitung: sieht Reklamationen der eigenen Produktlinie, trägt Ursache und Maßnahme ein.
• Geschäftsführung: sieht die Auswertung, ändert nichts.

Ablauf im Normalfall.

1. Der Innendienst erfasst Kunde, Auftragsnummer, Teil, Menge, Fehlerbeschreibung und Fotos.
2. Das Werkzeug schlägt anhand der Produktlinie einen Zuständigen vor, die Qualitätsleitung bestätigt.
3. Der Zuständige trägt Ursache und Maßnahme ein.
4. Die Qualitätsleitung schließt ab, der Innendienst bekommt einen Hinweis, dem Kunden Bescheid zu geben.

Akzeptanzkriterien.

• WENN Auftragsnummer oder Fehlerbeschreibung fehlen, DANN wird die Reklamation nicht angelegt und das fehlende Feld markiert.
• WENN eine Reklamation zwei Werktage ohne Zuständigen ist, DANN bekommt die Qualitätsleitung eine Erinnerung.
• WENN derselbe Kunde dasselbe Teil innerhalb von 90 Tagen zum dritten Mal reklamiert, DANN wird der Fall als Wiederholung markiert.
• WENN eine abgeschlossene Reklamation wieder geöffnet wird, DANN darf das nur die Qualitätsleitung, und Name und Datum werden festgehalten.

Nicht-Ziele.

• Keine Gutschriften oder Rechnungskorrekturen, das bleibt in der Buchhaltung.
• Kein Zugang für Kunden, sie melden sich weiter per Mail und Telefon.
• Keine Anbindung an das ERP in der ersten Version, die Auftragsnummer wird von Hand eingetragen.

Daten. Kunde, Auftragsnummer, Teil, Menge, Fehlerbeschreibung, bis zu zehn Fotos, Ursache, Maßnahme, Status, Verlauf mit Namen und Datum. Fotos und Beschreibungen sehen nur Innendienst, Qualität und Fertigung.

Randfälle.

• Eine Reklamation betrifft mehrere Aufträge.
• Der Kunde meldet denselben Fall zweimal, per Mail und am Telefon.
• Der Zuständige ist im Urlaub: Die Qualitätsleitung kann neu zuweisen.
• Das Teil lässt sich keiner Produktlinie zuordnen: Status „in Klärung", Zuweisung durch die Qualitätsleitung.

Das ist gut eine Seite, und es steht kein Wort über Datenbank, Programmiersprache oder Server darin. Aus dieser Seite kann ein Agent einen Plan ableiten, aus den vier Akzeptanzkriterien werden vier automatische Tests, und die Nicht-Ziele verhindern, dass nebenbei ein Kundenportal entsteht.

Den wertvollsten Teil schreibst du selbst

Das ist die wichtigste Botschaft dieses Beitrags für alle, die nicht selbst entwickeln: Die Spezifikation ist kein technisches Dokument. Ihr wertvollster Teil ist Wissen über deinen Betrieb, und das haben nur du und deine Fachabteilung.

Kein Entwickler weiß, dass bei euch die Fertigungsleitung Ursachen einträgt und nicht die Qualität. Keine KI weiß, dass Wiederholfälle ab dem dritten Mal eskaliert werden. Das weiß die Qualitätsleiterin, und sie kann es aufschreiben, ohne eine Zeile Code zu verstehen.

Drei Wege machen den Einstieg leichter:

• Von einer Arbeitsanweisung ausgehen. Eine gute Arbeitsanweisung enthält schon Abläufe, Zuständigkeiten und Sonderfälle, also die halbe Spezifikation. Wie so eine aussieht, steht in Was ist ein SOP.
• Sich von der KI befragen lassen. Gib der KI deinen Entwurf und bitte sie, so lange Fragen zu stellen, bis keine Lücke mehr offen ist. Darin ist sie gut. Spec Kit bietet dafür sogar einen eigenen Klärungsschritt an.
• Wiederkehrende Regeln nicht in jede Spezifikation schreiben. Was für jedes Vorhaben gilt, etwa Schreibweisen, Prüfschritte oder Vorgaben zum Umgang mit Daten, gehört einmal in die Grundsätze des Projekts oder in Agent Skills, die der Agent bei jeder Aufgabe mitliest.

Wenn du so vorbereitet in ein Softwareprojekt gehst, verschiebt sich das erste Gespräch mit dem Entwickler. Statt eine Stunde lang zu erklären, was ihr eigentlich braucht, redet ihr über die Stellen, an denen die Spezifikation noch unklar ist. Genau dort ist die Zeit gut angelegt.

Wo die Methode an Grenzen stößt

Spec-Driven Development ist kein Allheilmittel, und die ehrlichste Kritik kommt von Leuten, die es ausprobiert haben. Birgitta Böckeler hat Kiro, Spec Kit und ein drittes Werkzeug getestet und drei Einwände formuliert. Erstens erzeugen die Werkzeuge so viele Textdateien, dass das Prüfen mühsam wird; sie selbst würde lieber Code lesen als all diese Dokumente. Zweitens hat sich der Agent trotz ausführlicher Spezifikation immer wieder nicht an alle Vorgaben gehalten. Drittens passt ein fester Ablauf nicht zu jeder Aufgabengröße.

Daraus folgen vier praktische Regeln:

• Die Spezifikation wächst mit der Aufgabe. Ein neues Werkzeug verdient zwei bis vier Seiten, eine kleine Korrektur drei Sätze. Wer für jeden Tippfehler den vollen Ablauf startet, verliert die Geduld und irgendwann die Methode.
• Die Spezifikation ersetzt keine Prüfung. Sie sagt, was geprüft wird, aber nicht, dass es stimmt. Code-Review und Tests bleiben unverzichtbar, gerade weil der Agent nicht jede Vorgabe einhält.
• Eine veraltete Spezifikation ist schlimmer als keine. Wer den Code ändert und die Spezifikation nicht, hat zwei Wahrheiten und irgendwann gar keine. Das gilt für Firmenwissen generell, wie ich in Business OS aufbauen beschrieben habe.
• Klein anfangen, nicht alles vorab. Eine Spezifikation pro Funktion oder Ausbaustufe, nicht ein Gesamtdokument für die nächsten zwei Jahre. Sonst wird aus der Methode ein Wasserfall.

Häufige Fragen

Was ist Spec-Driven Development einfach erklärt?

Du schreibst zuerst auf, was eine Software tun soll und woran man erkennt, dass sie es richtig tut. Erst dann baut ein KI-Agent sie, Schritt für Schritt und gegen diese Beschreibung geprüft. Die Spezifikation bleibt die maßgebliche Quelle, auch für spätere Änderungen.

Brauche ich GitHub Spec Kit oder Kiro dafür?

Nein. Die Werkzeuge geben einen festen Ablauf und Vorlagen vor, was beim Einstieg hilft. Das Prinzip funktioniert aber auch mit einer einfachen Textdatei im Projekt und einem Agenten wie Claude Code oder Codex, der zuerst einen Plan erstellt und ihn dir zur Freigabe vorlegt.

Wie lang sollte eine Spezifikation sein?

So kurz wie möglich und so lang wie nötig. Für ein internes Werkzeug reichen meist zwei bis vier Seiten. Entscheidend ist nicht die Länge, sondern dass Ziel, Rollen, Abläufe, Akzeptanzkriterien, Nicht-Ziele, Daten und Randfälle abgedeckt sind.

Ist Spec-Driven Development nicht einfach Wasserfall mit neuem Namen?

Nur wenn man es falsch macht. Beim klassischen Wasserfall wird alles vorab für Monate festgelegt. Hier entsteht eine Spezifikation pro Funktion oder Ausbaustufe, die Umsetzung dauert Stunden bis Tage statt Monate, und die Spezifikation wird mit jeder Erkenntnis angepasst.

Was ist der Unterschied zwischen Spezifikation und Lastenheft?

Ein Lastenheft beschreibt meist das ganze Vorhaben auf einmal, oft als Grundlage für eine Ausschreibung, und wird danach selten angefasst. Eine Spezifikation im Sinne von Spec-Driven Development ist kleiner, liegt direkt im Projekt, enthält prüfbare Kriterien und wird bei jeder Änderung weitergepflegt.

Fazit

Spec-Driven Development dreht die Reihenfolge um, die Vibe Coding so verlockend macht: erst beschreiben, dann bauen. Die Spezifikation legt fest, was die Software tun soll, der Plan, wie, und der KI-Agent setzt Aufgabe für Aufgabe um. Werkzeuge wie Spec Kit, Kiro oder OpenSpec helfen dabei, nötig sind sie nicht.

Der wichtigste Punkt für dich als Entscheider: Ziel, Rollen, Abläufe, Akzeptanzkriterien, Nicht-Ziele und Randfälle kannst du mit deiner Fachabteilung selbst aufschreiben. Das ist der Teil, den weder ein Entwickler noch eine KI ersetzen kann, und er bestimmt mehr über das Ergebnis als jede Technikentscheidung.

Wenn du ein Werkzeug wie das Reklamations-Beispiel bauen lassen willst, schau dir an, wie ich KI-gestützte Softwareentwicklung mit Discovery, Prototyp und Etappen umsetze. Oder wir gehen deinen Ablauf in einer kostenlosen Prozessanalyse durch und schauen, wie weit deine Spezifikation schon ist.