Spec-driven Development: die zweite Schuld

Der Moment nach dem grünen Test

Es gibt einen Moment, den inzwischen viele kennen, und Amine Mastouri beschreibt ihn in seinem LinkedIn-Artikel Der Code war nie der schwierige Teil so: Der Agent liefert, die Tests sind grün, die Formatierung sitzt, das Diff ist länger, als man es an einem Vormittag lesen würde. Und trotzdem stimmt etwas nicht. Das System tut exakt das, was gebaut wurde, nur nicht das, was gemeint war.

Der erste Verdacht fällt dann auf das Werkzeug. Falsches Modell, zu kurzer Prompt, zu wenig Kontext. In der Praxis, schreibt Mastouri, liegt es fast immer woanders: Die Beschreibung dessen, was gebaut werden sollte, war nie präzise genug, um daran scheitern zu können. Sein Satz dazu bleibt hängen:

Die KI halluziniert nicht Form. Sie halluziniert Absicht.

Die These liegt in vielen Teams gerade halbfertig herum, deshalb haben wir sie uns genauer angesehen. Vieles daran trägt. An einer Stelle geht Mastouri weiter, als die Belege reichen, und dazu kommen wir weiter unten.

Warum ein besseres Werkzeug nicht hilft

Für die Erklärung holt Mastouri Fred Brooks heran, und der Text ist von 1986. In No Silver Bullet unterscheidet Brooks zwei Sorten Komplexität. Die akzidentelle steckt in der Umsetzung: Sprache, Bibliotheken, Werkzeugketten, Tippen. Die essenzielle steckt in der Sache selbst, nämlich darin, ein widerspruchsfreies Modell davon zu bauen, was ein System leisten soll. Seine Prognose damals war eng gefasst: Keine einzelne Entwicklung, weder bei der Technik noch bei den Managementmethoden, werde innerhalb eines Jahrzehnts eine Verbesserung um eine Größenordnung bei Produktivität, Zuverlässigkeit und Einfachheit bringen. Der Grund: Werkzeuge greifen nur die akzidentelle Hälfte an.

Mastouris Anschluss daran: KI-Assistenten haben diese Hälfte weiter abgetragen als jede Werkzeuggeneration davor, und damit steht die essenzielle zum ersten Mal ungeschützt im Raum. Das deckt sich mit dem, was wir sehen. Eine KI, die eine unpräzise Anforderung bekommt, scheitert nicht sichtbar. Sie liefert fehlerfreien Code für irgendeine Lesart der Aufgabe, sauber formatiert und mit Tests, die genau diese Lesart bestätigen. Der Fehler sieht nicht aus wie ein Fehler.

Das ist auch der Grund, warum das nächste Modell das Problem nicht mitlöst. Wer glaubt, dass es reicht, wenn die Maschine schneller Code produziert, verschiebt den Engpass nur. Wie dieser Engpass entstanden ist, steht in Von Vibe Coding zu Agentic Engineering.

Die Spezifikation, die niemand aufgeschrieben hat

Peter Naur hat 1985 in Programming as Theory Building beschrieben, was Programmieren eigentlich ist: nicht Textproduktion, sondern der Aufbau einer Theorie. Ein geteiltes Modell davon, wie das System die Welt abbildet und warum es so gebaut ist. Diese Theorie steht in keinem Dokument. Sie lebt in den Köpfen des Teams und verschwindet mit ihm. Wer ein System übernommen hat, dessen Erbauer längst woanders arbeiten, kennt das Ergebnis: Das Repository ist komplett, und trotzdem weiß niemand mehr, warum die Dinge so gebaut sind, wie sie gebaut sind.

Daraus folgt der Punkt, an dem Mastouris Argument scharf wird. Jedes System hat eine Spezifikation. Die Frage ist nur, in welchem Zustand.

Die agile Praxis hat die explizite Spezifikation nicht abgeschafft, sie hat sie implizit gemacht. Das funktionierte, solange Teams klein und stabil waren und aus Menschen bestanden. Alle drei Bedingungen bröckeln gerade, und die dritte am schnellsten: Ein Agent liest keine Köpfe. Für ihn existiert nur, was explizit dasteht. Wenn eine Konvention nur im Kopf des Senior-Entwicklers existiert, ist sie für die maschinelle Hälfte deines Teams nicht vorhanden.

Das ist der eigentliche Grund für die Rückkehr der Spezifikation, und es ist keine Nostalgie. Die implizite Variante verliert schlicht ihre Trägerschicht.

Gehirn, Muskulatur, Nervensystem

Mastouri beschreibt die Arbeitsteilung mit einem Bild aus der Physiologie. Der Mensch ist das Gehirn: Absicht, Urteil, Freigabe, also Verantwortung, die sich nicht generieren lässt. Die KI ist die Muskulatur: Code, Tests, Doku, Konsistenz, stark und schnell und ohne eigene Richtung. Die Spezifikation ist das Nervensystem, die Struktur, die Absicht in Signale übersetzt, auf die Muskulatur reagieren kann.

Der Befund, auf den das Bild zielt: Ein Organismus mit kräftiger Muskulatur und durchtrenntem Nervensystem produziert Bewegung, aber keine Handlung. Maximale Aktivität, minimale Steuerung. Das beschreibt codezentrierte KI-Entwicklung ziemlich genau.

Nebenbei beantwortet das Bild eine Frage, die viele Entwickler gerade beschäftigt. Wenn die Maschine den Code schreibt, was bleibt dann? Engineering war nie Programmieren, sondern Problemlösen, und dazu gehört vor allem, Probleme zu finden, bevor sie teuer werden. Genau das passiert in der Spezifikation: Dort sind Probleme noch Sätze und noch keine Systeme.

Der Kreislauf statt des Staffellaufs

Eine Metapher ist noch kein Prozess. Mastouri legt einen dazu, den er Closed Spec Loop nennt und nach eigener Aussage entwickelt und im Feld erprobt hat. Der Kern: Anforderungen, Architektur, Schnittstellen, Tests und Dokumentation sind ein zusammenhängendes, gepflegtes Artefakt, aus dem die KI alles Nachgelagerte ableitet.

flowchart TB
  SPEC["Spezifikation<br/>versioniert, lesbar"] --> REFINE["Refinement<br/>Fach, Technik, Betrieb"]
  REFINE --> GATE{"Ready?"}
  GATE -->|"nein"| REFINE
  GATE -->|"ja"| BUILD["Agenten bauen<br/>Code, Tests, Doku"]
  BUILD --> REVIEW["Review<br/>menschlich, Stichprobe"]
  REVIEW --> OPS["Betrieb<br/>Bugs, Erkenntnisse"]
  OPS -->|"als Spec-Änderung"| SPEC
  classDef decision fill:#1A3A4A,stroke:#F59E0B,color:#FDE68A
  classDef success fill:#14532D,stroke:#22C55E,color:#86EFAC
  class GATE decision
  class SPEC success

Das wichtigste Element ist dabei nicht die KI, sondern der Tisch in der Mitte. Im gemeinsamen Refinement schauen Fachbereich, Architektur, Entwicklung und Betrieb auf dieselbe Spezifikation und beantworten drei Fragen: Ist das fachlich das Gewollte? Ist es technisch tragfähig? Ist es betreibbar? Erst dann wechselt die Spec auf Ready, und nur eine Ready Spec darf gebaut werden. Dieses eine Tor ersetzt drei klassische Übergaben.

Drei Konstruktionsentscheidungen halten den Kreis geschlossen, und alle drei fühlen sich zunächst unbequem an.

Der Rückweg führt über die Spezifikation. Ein Produktionsfix darf schnell sein, aber abgeschlossen ist er erst mit der Spec-Änderung. Kein Fix ohne Spec-Update. Das wirkt langsamer und ist der Mechanismus, der das System nach der fünfzigsten Iteration noch beschreibbar hält.

Konsistenz ist ein Build-Kriterium. Die Spezifikation liegt versioniert, CI-Gates messen bei jedem Merge die Drift zwischen Spec und Code. Damit wechselt Dokumentationsverfall die Kategorie: vom schleichenden Schicksal zum sichtbaren Build-Fehler. Wie man solche Gates so aufhängt, dass niemand sie vergessen kann, steht in Quality-Gates gegen KI-Fehler.

Lesbarkeit für den Fachbereich ist eine Architekturanforderung. Der Wert einer Spezifikation entsteht in dem Moment, in dem ein Domänenexperte sie liest und sagt, dass das Beschriebene nicht das Gewollte ist. Im Refinement kostet dieser Befund ein Gespräch, nach der Implementierung kostet er Architektur.

Dazu kommt, was mit der Muskulatur passiert. Das Review bleibt menschlich und arbeitet mit Stichproben gegen Kopplung, Kohäsion und Testbarkeit. Ein generierter Pull Request ist ein Vorschlag, kein Beschluss. Und die Agenten bekommen ihrerseits eine Spezifikation: kanonische Templates plus die Regel, Widersprüche zu melden statt sie still zu glätten. Das deckt sich mit dem, was wir in Harness Engineering über Leitplanken und Messpunkte zusammengetragen haben.

Spezifikationsschuld

Der nützlichste Begriff des Artikels ist die Spezifikationsschuld: die wachsende Differenz zwischen dem, was ein System tut, und dem, was irgendwo beschrieben, geprüft und verantwortet ist.

Sie ist tückischer als technische Schuld, weil sie im Betrieb keine Symptome zeigt. Das System läuft, die Tests sind grün, die Pipeline ist schnell. Fällig wird sie erst bei Modernisierung, Audit oder Zulassung, und dann in voller Höhe, denn eine verlorene Theorie aus dem Code zu rekonstruieren gehört zum Teuersten, was in der Softwaretechnik anfällt.

Für den DACH-Raum ist das keine akademische Fußnote. Wer unter den EU AI Act fällt, muss Zweckbestimmung, Risiken und Verhalten seines Systems beschreiben können, und zwar aus Dokumenten, nicht aus dem Gedächtnis der Dienstältesten. Was da konkret verlangt wird, steht in EU AI Act: Fristen und was gilt wann. Ein System, dessen Sollverhalten niemand aufschreiben kann, ist nicht auditierbar. Der Closed Spec Loop ist unter dieser Perspektive ein Tilgungsplan.

Ein Punkt daraus reicht über Entwicklungsteams hinaus, nämlich die Beschaffung. Wenn Code generierbar wird, ist die lebende, verstandene Spezifikation das souveränste Artefakt, das ein Auftraggeber besitzen kann, weil die Theorie des Systems dann bei ihm liegt und nicht im Code eines Herstellers. Das ist derselbe Hebel, den wir in Digitale Souveränität für KI-Teams von der Infrastrukturseite betrachtet haben.

Was die Werkzeuge schon können

Der Markt ist der These vorausgelaufen. Die beiden Werkzeuge, die Mastouri nennt, Stand 16.08.2026:

Beide setzen dasselbe Prinzip um: erst Anforderungen und Akzeptanzkriterien, dann Design, dann Code. Die Formel dazu lautet, dass die Spec der Prompt ist. Eine dritte Variante haben wir uns in BMad-Methode: strukturiert mit KI-Agenten angesehen, die den Weg über definierte Agenten-Rollen geht.

Der Unterschied in der Praxis liegt weniger in den Kommandos als in der Bindung. Spec Kit kostet nichts und läuft auf dem Agenten, den ihr schon habt, taugt also für einen Versuch an einem echten Feature. Kiro nimmt euch mehr ab und bindet euch dafür an eine Umgebung.

Wo die These kippt

Jetzt der Teil, den der Originalartikel nur streift. Spec-driven Development landete im Technology Radar von Thoughtworks in der Ausgabe vom November 2025 im Ring "Assess", also anschauen und verstehen, nicht ausrollen. In der aktuellen Ausgabe steht der Eintrag nicht mehr, die Vorbehalte von damals decken sich aber mit dem, was uns im Alltag begegnet.

Die Abläufe sind aufwendig und meinungsstark. Die Werkzeuge verhalten sich je nach Größe und Art der Aufgabe sehr unterschiedlich. Manche erzeugen Spec-Dateien, die so lang sind, dass sie niemand mehr durchsieht, und dann hast du das Review-Problem nur eine Ebene nach oben verschoben. Bei generierten PRDs und User Stories ist außerdem oft unklar, für wen sie eigentlich geschrieben sind. Dazu kommt der grundsätzliche Einwand, den Thoughtworks als mögliche bittere Lektion formuliert: dass handgepflegte Detailregeln für KI langfristig nicht skalieren.

Der zweite Einwand kommt aus der Praxis und ist älter als die KI. Eine Spezifikation, die vor dem Bauen vollständig sein soll, kollidiert damit, dass man beim Bauen Dinge lernt, die man vorher nicht wissen konnte. Wer das Ready-Tor zu streng zieht, hat den Wasserfall zurück, nur mit besserem Tooling. Mastouri sieht das Risiko und beantwortet es mit dem geschlossenen Kreis: Der Rückweg über die Spezifikation ist genau der Mechanismus, der aus einem Vorab-Dokument ein lebendes Artefakt macht. Ob das im Alltag hält, entscheidet sich daran, wie leicht eine Spec-Änderung durchs Refinement kommt. Ist das Tor schwer, wird es umgangen.

Und drittens die Felderfahrung. Mastouri berichtet von einer Multi-Domain-Plattform für unbemannte Systeme mit über fünfzehn Diensten, die in acht Kalenderwochen von der Vision zur präsentationsreifen Lösung kam. Er schreibt selbst dazu, dass präsentationsreif nicht zulassungsreif heißt und ein Einzelfall keine Methode beweist. Diese Ehrlichkeit rechnen wir ihm an, sie ändert aber nichts daran, dass acht Wochen als Zahl hängen bleiben und in der nächsten Präsentation ohne die Einschränkung auftauchen werden. Der belastbare Teil des Berichts ist nicht das Tempo, sondern die Begründung: Mehrere Teams und mehrere Agenten konnten parallel arbeiten, weil die Wahrheit über das System nicht in Köpfen lag.

Unsere Einschätzung: Die Diagnose trägt, der volle Prozess nicht überall. Ein Zwei-Personen-Projekt mit stabiler Besetzung fährt mit einer impliziten Spezifikation weiterhin gut. Sobald mehrere Teams, wechselndes Personal, Agentenflotten oder eine Auditpflicht dazukommen, kippt die Rechnung, und zwar schneller, als es sich anfühlt.

Womit du anfängst

Drei Schritte, keiner braucht ein Budget.

Die Rekonstruktionsfrage, zehn Minuten. Mastouris Prüffrage lautet: Ginge morgen der gesamte Code verloren, aber alle Spezifikationen blieben, wie lange dauerte der Wiederaufbau? Und umgekehrt: Könntet ihr dann noch sagen, was das System tun soll, oder nur noch, was es tut? Stell die Frage im nächsten Team-Meeting und hör dir an, wie lange es still bleibt. Das ist deine Spezifikationsschuld.

Ein Feature spec-first, ein Sprint. Nimm das nächste Feature mittlerer Größe und schreib Anforderungen und Akzeptanzkriterien auf, bevor ein Agent etwas anfasst. Zwei Bedingungen: Der Fachbereich liest es gegen, und die Datei liegt im Repository neben dem Code, nicht im Wiki. Ob ihr dafür Spec Kit nehmt oder eine Markdown-Datei, ist zweitrangig.

Bevor gebaut wird, lohnt sich eine Runde, in der die KI nicht implementiert, sondern die Beschreibung angreift. Genau die Lücken, die sie hier meldet, füllt sie sonst still mit einer eigenen Lesart:

Die Bug-Regel umdrehen, ab sofort. Beim nächsten Bug, den ein Agent fixt: Bevor der Pull Request zugeht, eine Zeile beantworten. Was hätte in der Spezifikation stehen müssen, damit dieser Fehler nicht entsteht? Steht dort nichts, ist es ein Spec-Fehler, kein Code-Fehler. Das ist der günstigste Einstieg in den geschlossenen Kreis, und du merkst innerhalb von zwei Wochen, wie oft die Antwort nicht "nichts" lautet.

Der Rest folgt daraus. Was sich nicht beschreiben lässt, lässt sich auch nicht delegieren, und das gilt für Agenten genauso wie für den neuen Kollegen im dritten Sprint.