Spec-Driven Development: die kurze Antwort

84 Prozent der Entwicklerinnen und Entwickler nutzen KI-Werkzeuge oder planen es, aber nur 33 Prozent vertrauen der Genauigkeit der Ergebnisse, 46 Prozent misstrauen ihr ausdrücklich. Das zeigt der Stack Overflow Developer Survey 2025 mit über 49.000 Teilnehmenden. Spec-Driven Development lässt sich als Antwort der Werkzeughersteller auf diese Lücke lesen, und in diesem Artikel siehst du, was dahinter steckt, wo die Methode an Grenzen stößt und was du davon hast, wenn du Software bauen lässt.

Bei Spec-Driven Development schreibt niemand zuerst Code. Zuerst steht eine prüfbare Spezifikation, und der KI-Agent baut gegen sie, nicht gegen einen losen Chat-Verlauf.

Spec-Driven Development, auf Deutsch etwa spezifikationsgetriebene Entwicklung, heißt: Bevor ein KI-Agent eine Zeile Code erzeugt, wird schriftlich festgelegt, was gebaut werden soll, wie es technisch aussehen soll und in welchen Schritten es entsteht. Diese Spezifikation ist dann die gemeinsame Quelle der Wahrheit für den Menschen und für die KI. GitHub beschreibt sie in der Vorstellung seines Open-Source-Werkzeugs Spec Kit (September 2025) als lebendes Dokument, an dem Umsetzung, Tests und Prüfung hängen.

Warum das Thema gerade jetzt kommt

Bis vor kurzem lief KI-gestützte Programmierung meist so: Jemand beschreibt im Chat, was er will, der Assistent liefert Code, man korrigiert per Zuruf. Das hat inzwischen einen Namen, „Vibe Coding“, und für einen Prototyp am Nachmittag funktioniert es gut. Für Software, die in einem Unternehmen laufen soll, funktioniert es schlecht. Die Belege dafür kommen nicht von Kritikern, sondern aus Erhebungen und Studien.

  • Fast richtig ist das häufigste Problem. 66 Prozent der Befragten im Stack Overflow Survey 2025 nennen als größten Frust KI-Lösungen, die „fast richtig, aber eben nicht ganz“ sind.
  • Mehr Tempo, weniger Stabilität. Der DORA-Bericht „State of AI-assisted Software Development“ (2025) von Google Cloud mit knapp 5.000 Befragten findet, dass KI-Nutzung mit höherem Durchsatz einhergeht, die Stabilität der ausgelieferten Software aber nachlässt. KI wirkt dort als Verstärker: Sie verstärkt, was in einer Organisation gut läuft, und genauso, was schlecht läuft.
  • Gefühlt schneller ist nicht gemessen schneller. In einer randomisierten Studie von METR (Juli 2025) brauchten 16 erfahrene Open-Source-Entwickler für 246 echte Aufgaben mit KI-Werkzeugen 19 Prozent länger als ohne. Hinterher schätzten sie, die KI habe sie um 20 Prozent beschleunigt. Die Autoren betonen, dass das nur für ihr Setting gilt: erfahrene Leute in großen, gepflegten Codebasen.

Gemeinsam ist den drei Befunden: Die KI schreibt Code schnell, aber sie weiß nicht von selbst, was gemeint war. Die Lücke zwischen Absicht und Ergebnis schließt man nicht mit noch mehr Prompts, sondern mit einer Absicht, die vorher sauber aufgeschrieben ist. Genau da setzt Spec-Driven Development an.

Wie Spec-Driven Development funktioniert

Die Werkzeuge unterscheiden sich im Detail, der Ablauf ist überall ähnlich. GitHub teilt ihn in Spec Kit in vier Phasen:

  1. Specify (Was soll es tun?). Du beschreibst das Problem und die Abläufe aus Sicht der Nutzer: wer was auslöst und was dann passieren muss. Noch kein Wort über Technik.
  2. Plan (Wie wird es gebaut?). Technik, Architektur, Schnittstellen und Vorgaben kommen dazu, etwa „läuft in unserem Rechenzentrum“ oder „liest aus dem bestehenden ERP“.
  3. Tasks (In welchen Schritten?). Die Spezifikation wird in kleine, einzeln prüfbare Arbeitspakete zerlegt.
  4. Implement (Bauen). Erst jetzt erzeugt der KI-Agent Code, Paket für Paket, und jedes Paket lässt sich gegen die Spezifikation prüfen.

Amazon Web Services hat im Juli 2025 die Entwicklungsumgebung Kiro vorgestellt, die denselben Gedanken in drei Dateien gießt: Anforderungen, Entwurf und Aufgaben. Die Anforderungen schreibt Kiro als Nutzergeschichten mit Abnahmekriterien in der Notation EARS (Easy Approach to Requirements Syntax). Das ist eine Satzschablone aus dem Anforderungsmanagement, die jede Anforderung in die Form „Wenn X passiert, soll das System Y tun“ zwingt. Jede Aufgabe verweist zurück auf die Anforderung, aus der sie stammt.

Ein drittes Werkzeug, das Tessl Framework, geht weiter und behandelt die Spezifikation als das eigentliche Produkt: Gepflegt wird die Spezifikation, der Code wird daraus erzeugt.

Drei Stufen: wie ernst die Spezifikation genommen wird

Birgitta Böckeler, Distinguished Engineer bei Thoughtworks, hat in einer Analyse der drei Werkzeuge auf martinfowler.com (Oktober 2025) drei Stufen unterschieden. Die Einteilung hilft, wenn dir ein Anbieter erzählt, er arbeite „spec-driven“:

  • Spec-first. Die Spezifikation wird vor dem Code geschrieben und für die aktuelle Aufgabe genutzt. Danach liegt sie herum.
  • Spec-anchored. Die Spezifikation bleibt nach dem Bau erhalten und wird bei jeder Änderung mitgepflegt. Wer in einem Jahr eine Funktion ergänzt, ändert zuerst die Spezifikation.
  • Spec-as-source. Die Spezifikation ist das einzige Dokument, das Menschen bearbeiten. Der Code wird erzeugt und nicht mehr von Hand angefasst.

Für ein Unternehmen, das Software nicht nur einmal bauen, sondern jahrelang betreiben will, ist die zweite Stufe die interessante. Eine Spezifikation, die nach dem Go-live verwaist, hilft beim nächsten Änderungswunsch nicht mehr.

Was an Spec-Driven Development neu ist und was nicht

Wer im Mittelstand schon einmal Software hat bauen lassen, denkt beim Lesen sofort an Lastenheft und Pflichtenheft. Der Gedanke ist richtig: Auch dort wird vor dem Bau aufgeschrieben, was die Software leisten soll. Drei Dinge sind trotzdem anders.

Erstens der Leser. Ein Lastenheft lesen Menschen, und Menschen füllen Lücken mit gesundem Menschenverstand. Eine Spezifikation für Spec-Driven Development liest ein KI-Agent, und der füllt Lücken mit Annahmen, die plausibel klingen und trotzdem falsch sein können. Deshalb muss sie genauer sein: jede Bedingung, jede Ausnahme, jedes Abnahmekriterium.

Zweitens die Laufzeit. Ein klassisches Lastenheft entsteht über Wochen und ist oft veraltet, wenn der Bau beginnt. Bei Spec-Driven Development werden Spezifikation, Plan und Aufgaben in Stunden erzeugt, weil die KI auch beim Schreiben der Spezifikation hilft. Der Mensch prüft und gibt frei, statt alles selbst zu formulieren.

Drittens die Rückverfolgbarkeit. Weil jede Aufgabe auf eine Anforderung zeigt und jeder Test auf eine Aufgabe, lässt sich später nachvollziehen, warum ein Stück Code existiert. Das ist für jede Firma praktisch, die nach einem Jahr noch wissen will, warum etwas so gebaut wurde, und für regulierte Branchen wie Banken und Versicherungen fast schon Pflicht.

Spec-Driven Development ist kein neues Lastenheft. Es ist ein Lastenheft, das eine Maschine lesen kann und das nach dem Bau weiterlebt.

Wo die Grenzen liegen

Spec-Driven Development ist jung, und die ernsthaften Stimmen dazu sind vorsichtig. Thoughtworks führt die Methode im Technology Radar (November 2025) im Ring „Assess“, also: ansehen, noch nicht breit einsetzen. Die Kritikpunkte lohnen einen genauen Blick, weil sie zeigen, worauf du bei einem Anbieter achten solltest.

  • Zu viel Papier. Böckeler beschreibt, dass Spec Kit sehr viel Markdown erzeugt, das jemand prüfen muss. Wenn die Prüfung länger dauert als der Bau, ist nichts gewonnen.
  • Eine Größe für alles. Weder Kiro noch Spec Kit passen den Ablauf an die Größe des Problems an. Für einen kleinen Fehler einen kompletten Spezifikationszyklus zu starten, ist Overkill.
  • Agenten halten sich nicht immer dran. Auch mit ausführlicher Spezifikation ignorieren KI-Agenten Teile davon oder deuten sie anders. Die Spezifikation verringert das Problem, sie beseitigt es nicht.
  • Viel Spezifikation vorab. Böckeler ist skeptisch gegenüber umfangreicher Spezifikation vor dem Bau und rät zu kleinen Schritten. Sie erinnert an Model-Driven Development, das mit einer ähnlichen Idee bei Business-Anwendungen nie angekommen ist, weil es zu aufwendig und zu unflexibel war.

Im Technology Radar vom April 2026 ordnet Thoughtworks Spec-Driven Development als vorgelagerte Steuerung für Coding-Agenten ein und warnt zugleich vor „kognitiver Schuld“: Je mehr Code eine KI erzeugt, desto weniger verstehen die Menschen das System, das sie betreiben. Die Pressemitteilung zum Radar fasst das als Rückkehr zu Engineering-Grundlagen zusammen. Eine gute Spezifikation ist eine solche Grundlage, weil sie festhält, was das System tun soll, auch wenn kein Mensch jede Zeile Code gelesen hat.

So nutzt du Spec-Driven Development, wenn du Software bauen lässt

Du musst Spec Kit oder Kiro nicht selbst bedienen, um von der Methode zu profitieren. Wenn du als Geschäftsführer oder IT-Leiter Software bei einem Dienstleister bauen lässt, der mit KI-Agenten arbeitet, helfen dir diese Schritte:

  1. Frag nach der Spezifikation, bevor gebaut wird. Lass dir zeigen, was der Agent bauen soll, in Sätzen, die du verstehst. Wenn es diese Unterlage nicht gibt, baut der Agent gegen einen Chat-Verlauf.
  2. Prüf die Abnahmekriterien, nicht die Technik. Dein Beitrag sind die Wenn-dann-Sätze: Was passiert bei einer Bestellung über dem Limit, was bei einem fehlenden Feld, wer wird benachrichtigt. Die Technik prüft der Dienstleister.
  3. Bestehe auf Rückverfolgbarkeit. Jede Funktion sollte auf eine Anforderung zeigen und jeder Test auf eine Funktion. Dann kannst du bei der Abnahme gezielt fragen: Welche Anforderung deckt dieser Test ab?
  4. Kläre, wer die Spezifikation nach dem Go-live pflegt. Spec-first reicht für ein Wegwerf-Werkzeug. Für Software, die du drei Jahre betreibst, willst du die zweite Stufe: Änderungen beginnen in der Spezifikation.
  5. Passe den Aufwand an die Größe an. Ein Formular braucht keine zehn Seiten Spezifikation. Ein guter Dienstleister erklärt dir, warum er für welches Paket wie viel aufschreibt.

Beispiel: Freigabe von Bestellanforderungen in einem Maschinenbau-Betrieb

Ein Maschinenbauer mit 120 Mitarbeitenden will Bestellanforderungen nicht mehr per E-Mail und Excel freigeben. Das Beispiel ist ausgedacht und zeigt, wie ein Ausschnitt aus der Anforderungs-Spezifikation in EARS-Form aussieht. So kann ein Geschäftsführer ihn lesen und abhaken, ohne eine Zeile Code zu kennen.

Spezifikation: Freigabe Bestellanforderungen (Ausschnitt)

Anforderung A1: Bestellanforderung anlegen

Wenn eine Mitarbeiterin eine Bestellanforderung absendet, soll das System Lieferant, Betrag, Kostenstelle und Begründung als Pflichtfelder prüfen.

Abnahme:

  • Fehlt ein Pflichtfeld, wird die Anforderung nicht gespeichert und das fehlende Feld wird benannt.

Anforderung A2: Freigabe nach Betrag

Wenn der Betrag 5.000 Euro oder weniger beträgt, soll das System die Anforderung an die Kostenstellen-Leitung senden. Wenn der Betrag über 5.000 Euro liegt, soll das System zusätzlich die Geschäftsführung einbinden.

Abnahme:

  • 4.999 Euro: nur Kostenstellen-Leitung
  • 5.001 Euro: Kostenstellen-Leitung und Geschäftsführung

Anforderung A3: Erinnerung

Solange eine Anforderung länger als zwei Werktage offen ist, soll das System den Freigebenden einmal täglich erinnern.

Aufgaben (vom Agenten abgeleitet, je mit Verweis auf die Anforderung)

  • T1: Formular mit Pflichtfeldprüfung (zu A1)
  • T2: Freigaberegel nach Betragsgrenze (zu A2)
  • T3: Tägliche Erinnerung (zu A3)
  • T4: Tests für alle Abnahmekriterien (zu A1, A2, A3)

Die Grenze von 5.000 Euro ist eine Entscheidung des Unternehmens, keine der KI. Genau das ist der Punkt: In der Spezifikation stehen die Entscheidungen, die nur du treffen kannst, und der Agent baut dagegen.

Wo AthenaRun hier steht

Unsere Plattform arbeitet nach diesem Prinzip: als End-to-End Software Development Lifecycle mit KI-Agenten, also ein durchgängiger Ablauf von der Anforderung über Spezifikation, Bau und Tests bis zur Dokumentation und zum Betrieb. Die Kette beginnt mit der Anforderungsaufnahme. Aus einem Gespräch oder vorhandenen Unterlagen entsteht eine Spezifikation, gegen die die Agenten bauen und testen, und ein Mensch gibt die Ergebnisse frei. Vault, das Gedächtnis der Plattform, bewahrt das Wissen aus jedem Projekt, sodass spätere Projekte davon profitieren. Die Spezifikation soll nach dem Go-live nicht liegen bleiben, sondern der Ausgangspunkt für die nächste Änderung sein.

Wenn du sehen willst, wie aus einer Anforderung eine Spezifikation und daraus eine laufende Anwendung wird: In einem 30-Minuten-Gespräch zeigen wir dir an einem Beispiel, wie das bei uns aussieht.

Weiterlesen im Wissen-Hub

Wie du die Anforderungen für einen KI-Agenten aufschreibst, steht in Lastenheft für einen KI-Agenten. Warum viele KI-Projekte zwischen Prototyp und Betrieb stecken bleiben, liest du in Warum KI-Piloten nicht in den Produktivbetrieb kommen. Und wie ein KI-Agent Entscheidungen über Wochen behält, beschreibt der Werkstattbericht KI-Agenten mit Gedächtnis.