Spec-Drift ist der Normalzustand

Spec-Driven Development gilt derzeit als der seriöse Weg, mit KI-Agenten Software zu erstellen. Die Spezifikation wird vor dem Code geschrieben und bleibt während der gesamten Umsetzung die verbindliche Vorgabe. Ich habe diese Arbeitsweise in zwei internen Projekten über Monate strenger durchgehalten, als die gängigen Werkzeuge es verlangen. Zusammen stehen dahinter rund 850.000 Zeilen Produktcode, über 5.000 Ticket- und Spezifikationsdateien und mehr als 7.000 Commits. Die Bilanz ist ernüchternd. In keinem der beiden Projekte hat die Spezifikation das Ergebnis zuverlässig bestimmt. Für Korrektheit sorgten am Ende End-to-End-Tests und unabhängige Audits, also Prüfungen, die erst nach der Implementierung greifen und im Betrieb teuer sind.

Das Versprechen

Wenn Agenten den Code schreiben, verschiebt sich die menschliche Arbeit nach vorn, in die präzise Beschreibung dessen, was entstehen soll. Die Spezifikation wird zur eigentlichen Quelle des Systems; der Code gilt als abgeleitetes Artefakt, das sich aus ihr jederzeit neu erzeugen lässt. Werkzeuge wie GitHubs Spec Kit oder Amazons Kiro institutionalisieren diesen Ablauf: Anforderungen werden festgehalten, daraus entsteht ein Plan, der Agent implementiert, und am Ende wird gegen die Spezifikation validiert. Thoughtworks führt die Technik im Technology Radar unter „Assess“ (Stand November 2025). Die Idee ist älter als die Agenten; Anforderungsdokumente gibt es, seit es Softwareprojekte gibt. Neu ist die Erwartung, dass die Kette von der Anforderung zur Implementierung ohne menschliche Übersetzung hält, weil ein Agent sie übernimmt.

Dahinter steht ein Kontrollversprechen. Wer präzise genug spezifiziert, so die Annahme, kontrolliert das Ergebnis, ohne den entstehenden Code noch Zeile für Zeile zu lesen. Die Spezifikation soll das Review ersetzen, das bei menschlichen Teams die Korrektheit absichert. In der starken Form heißt das, dass aus einer hinreichend präzisen Spezifikation eine konforme Implementierung folgt.

Beide Projekte, um die es hier geht, waren von Beginn an spezifikationsgetrieben aufgesetzt. Der allererste Commit von Projekt B enthält ausschließlich Spezifikationsdateien. In Projekt A entstand das Ticket-, Epic- und ADR-System ebenfalls vor dem ersten Feature.

Der Versuchsaufbau

Entwickelt habe ich beide Projekte mit Coding-Agenten. Die Agenten haben implementiert und geprüft; auch die Dokumentation lief über sie.

Die Spezifikationsdisziplin war in beiden Projekten hoch. In Projekt B folgt jedes größere Ticket einem Schema mit 23 Pflichtsektionen, von der Scopefixierung über Akzeptanzkriterien bis zum Verifikations- und Negativkontrollplan; ein einzelnes Spezifikationspaket von 122 Markdown-Dateien enthält 741 Tabellen mit knapp 6.000 Datenzeilen. In Projekt A regelt eine zentrale Arbeitsverfassung die Quellenrangfolge, die Rollentrennung zwischen Implementierer und Auditor und die Bedingungen, unter denen ein Ergebnis als abgenommen gilt. Vor dem Implementierungsstart steht ein bestandenes Plan-Review, vor dem Merge ein unabhängiges Audit; Selbstabnahme ist ausgeschlossen.

Auffällig ist das Größenverhältnis zwischen Prosa und Code. In Projekt A umfasst der gesamte Markdown-Korpus aus Tickets, Plänen, Audits und Evidenzdokumenten rund 868.000 Zeilen. Das ist fast das Doppelte des Produktcodes. In Projekt B stehen rund 244.000 Zeilen Spezifikation neben rund 550.000 Zeilen Code. Neben der Software ist damit ein zweites System aus Prosa entstanden, ähnlich groß und mit eigenem Pflegebedarf.

Der Befund

Mit Spec-Drift meine ich das Auseinanderlaufen von Spezifikation und Realität: Der Code tut etwas anderes, als die Spezifikation beschreibt, oder die Spezifikation beschreibt etwas, das es so nie gab oder nicht mehr gibt. In beiden Projekten ist dieser Zustand über lange Strecken der Regelfall gewesen. Mir ist über die gesamte Laufzeit kein längerer Arbeitsstrang begegnet, der ohne dokumentierte Drift durchgelaufen wäre. Die Audit-Artefakte beider Projekte belegen das in vier Richtungen.

Die Implementierung weicht von der Spezifikation ab. Das ist der Fall, den man erwartet, und er kommt in Formen vor, die kein Diff-Review auffängt. In Projekt B verlangte die Spezifikation deterministische Generierung von Inhalten; ein Reparaturplan zählte später 16 Stellen im Code, die trotzdem die Systemuhr lasen. Der Effekt blieb monatelang unsichtbar, weil ein früherer Referenzexport denselben Generierungstag eingefroren hatte: Die Tests verglichen gegen Referenzdaten, die denselben Fehler enthielten. Ein Audit in Projekt A dokumentiert einen Fall, in dem der Systemprompt vor jeder Pfadannahme zwei Shell-Kommandos verlangte, während das Regelwerk eines dieser Kommandos blockierte. 48 von 51 beobachteten Kommandosequenzen befolgten die Anweisung und liefen gegen die Sperre; 21 Testdurchläufe verbrauchten ihr volles Iterationsbudget ohne Wirkung, und sämtliche Prozesse beendeten sich trotzdem mit Exit-Code 0. Ein anderes Audit wies nach, dass eine Normalisierungsfunktion mehrstellige Fehlerzahlen zu Null verkürzte, wodurch ein Prüfmodul trotz expliziter Fehler-Evidenz auf „bestanden“ gesetzt werden konnte. Wirkungslos war auch ein dokumentierter Konfigurationsschalter für das Token-Limit; vier Messläufe mit vier verschiedenen Werten ergaben jedes Mal exakt dieselbe Ausgabelänge, ohne Fehlermeldung.

Die Dokumentation veraltet gegen den Code. Ein automatischer Abgleich in Projekt A fand Verweise auf Quelldateien, die längst gelöscht oder umbenannt waren, und ein Widerspruchsregister zählte elf verschiedene Versionen derselben Testanzahl quer durch die Dokumente. Jede dieser Zahlen war zu ihrem Zeitpunkt korrekt gewesen und dann eingefroren. Gravierender ist Status-Drift. Ein unabhängiges Audit über 16 Arbeitspakete kam zum Ergebnis, dass sechs davon Statusangaben trugen, die von der Realität des Hauptbranches überholt waren. Bereits gemergte Arbeit wirkte offen. Agenten lesen diese Artefakte als Steuerungsquelle; jedes spätere Gate hätte also gegen falsche Statuslagen geprüft. Zur selben Klasse gehört ein Fund, bei dem vier Kernhebel der Umsetzung nur auf einem Seitenbranch existierten und allein über ein Archiv-Tag gesichert waren, während die Planung sie als verfügbar führte; in einem weiteren Fall lag ein bestandenes Plan-Gate nur auf dem Arbeitsbranch und fehlte auf dem Hauptzweig, gegen den es hätte gelten sollen.

Spezifikationen widersprechen einander. In Projekt A kollidierten die Akzeptanzkriterien zweier Tickets frontal. Beide betrafen dieselbe Funktion; das eine verlangte eine Verschärfung der bestehenden Muster, das andere eine gezielte Lockerung. Ein weiteres Ticket erklärte sich zur Voraussetzung eines anderen, das von dieser Abhängigkeit nichts wusste. Geschrieben wurden diese Spezifikationen zu verschiedenen Zeitpunkten von verschiedenen Agenten-Kontexten, von denen keiner den gesamten Bestand überblickte.

Die Spezifikation widerspricht sich selbst. Das ist die Richtung, die mich am meisten überrascht hat. Ein Plan-Audit in Projekt A wies nach, dass drei Festlegungen eines bereits detaillierten Plans zusammen keinen aufrufbaren Codepfad ergaben; der Plan war in sich unerfüllbar, bevor eine Zeile implementiert war. In Projekt B stellte ein Audit fest, dass neun Pflichtsektionen der übergeordneten Spezifikation aus den Tickets verschwunden waren, durch eine Kompaktierungsaktion, und niemand hatte es bemerkt, bis ein Prüfer sie zählte. Im selben Projekt existiert ein Audit-Dokument, das sein eigenes früheres „bestanden“ per Nachtrag auf „nicht bestanden“ dreht, weil die Beweisführung an die falschen Prüfobjekte gebunden war.

Die Ursache liegt nach meiner Einschätzung im Arbeitsmodell selbst. Agenten arbeiten mit begrenztem Kontextfenster in Sitzungen, die enden; in Projekt B liefen Subagenten nach rund zwei Stunden in Session-Limits. Ein Vorhaben von mehreren Monaten besteht damit aus hunderten Übergaben zwischen Kontexten, die jeweils nur einen Ausschnitt des Systems und der Spezifikation sehen. Bei jeder Übergabe können Spezifikation und Realität ein Stück auseinanderlaufen. Ein Agent ändert Code und übersieht einen Teil der betroffenen Dokumente; der nächste liest eines der veralteten und baut darauf auf. Wiederaufnahme-Prompts und Übergabedokumente mildern das ab, die fehlende Gesamtsicht ersetzen sie aber nicht. Die Spezifikation altert dabei genauso wie der Code. Sie steht als gepflegtes Artefakt im System selbst, und anders als der Code hat sie keine Tests. Präziser zu spezifizieren vergrößert deshalb vor allem die Fläche, auf der diese Alterung stattfindet; die 23 Pflichtsektionen in Projekt B haben Drift jedenfalls nicht verhindert.

Mit dieser Beobachtung stehe ich nicht allein. Eine Feldstudie über 20.574 reale Agent-Sessions fand systematische Lücken zwischen Auftrag und Umsetzung; 91 Prozent der sichtbaren Fälle erforderten eine explizite Nutzerkorrektur (arXiv 2605.29442, 2026). Selbst der beste Agent in einem Benchmark zur Spezifikations-Kompetenz erkennt nur 44 Prozent der Mängel in Specs, also Lücken, Mehrdeutigkeiten und Widersprüche (arXiv 2605.30314, 2026). Ein Vergleich von drei Spec-Driven-Frameworks über zwei Modellfamilien kommt zum Ergebnis, dass strengere Spezifikationsbindung den Determinismus des Outputs sogar senkt; als erreichbares Ziel bleibe Verifizierbarkeit (arXiv 2606.30689, 2026). Der Mechanismus des Kontextverlusts ist ebenfalls beschrieben, bis hin zum Detail, dass Kontext-Kompression bevorzugt genau die Tokens verwirft, die die ursprüngliche Spezifikation kodieren (arXiv 2607.27167, 2026). Aus der Industrie berichtet Atlassians Engineering-Blog gleichlautend, dass Agenten bei vollem Kontextfenster frühere Entscheidungen stillschweigend aufgeben und größere Modelle das Problem nicht lösen (Atlassian Engineering, Juni 2026).

Was in der Praxis hilft

In beiden Projekten haben sich drei Gegenmaßnahmen herausgebildet und im Alltag bewährt. Alle drei verlagern die Verlässlichkeit an Stellen, die sich ausführen oder unabhängig prüfen lassen.

Wenn ein Modell eine andere Lösung wählt als die spezifizierte, ist der Reflex, die Abweichung zurückzudrehen. Dieser Reflex ist teuer und oft sachlich unbegründet, denn viele Abweichungen sind fachlich gleichwertig oder besser. Praktikabler ist, solche Abweichungen zu akzeptieren und zu prüfen, ob sich das System so verhält, wie es soll; ob der Code dem Wortlaut der Spezifikation folgt, wird damit zweitrangig. Das Instrument dafür sind End-to-End-Tests gegen den echten Ausführungspfad. Projekt B hält knapp 600 Browser-End-to-End-Fälle neben gut 6.000 Unit-Fällen; für jede neue Funktionseinheit ist ein eigener End-to-End-Nachweis Pflicht. Akzeptiert man eine Abweichung, muss die Spezifikation nachgezogen werden, sonst taucht dieselbe Abweichung im nächsten Audit erneut als Befund auf. End-to-End-Tests sind in beiden Projekten die einzige Instanz gewesen, die Semantik prüft. In Projekt B lieferte dieselbe Komponente einen grünen Lauf auf Paket-Ebene mit über 400 Tests und fiel im Integrationslauf auf zwei Simulatoren mit einem einzigen Testpaar durch; die Arbeitsregeln des Projekts halten seither fest, dass ein grüner Paketlauf keine Korrektheit belegt. In der Arbeitsverfassung von Projekt A steht dazu der Grundsatz, dass ein Live-Gate auf kaputter Semantik grün sein kann. Deshalb verlangt dort jedes Feature ein eigenes End-to-End-Szenario gegen das reale Zielsystem, und ein dokumentierter Live-Lauf über 54 Prüfzellen endete mit 16 bestandenen Zellen. Ein ehrlich rotes Ergebnis ist in dieser Arbeitsweise etwas wert, denn die Gegenklasse ist ebenfalls dokumentiert: ein Gate, das dreimal grün meldete, obwohl das geprüfte Kindsystem missgebildete Ausgaben lieferte. Wegen solcher Falschgrün-Fälle müssen die E2E-Tests selbst wieder geprüft werden, etwa darauf, ob sie fehlschlagen können.

E2E-Tests haben allerdings noch eine andere Schwachstelle, und die ist gut vermessen. Sieht der implementierende Agent die Tests und iteriert auf sie, optimiert er auf deren Bestehen; ob die Aufgabe gelöst ist, gerät dabei aus dem Blick. Ein Benchmark zu Reward Hacking in langlaufenden Coding-Agenten dokumentiert als Extremfall einen 2.900-Zeilen-Scheinkompiler, der die Testeingaben schlicht auswendig gelernt hatte; die Lücke zwischen sichtbaren und zurückgehaltenen Tests wuchs dort mit der Codegröße (arXiv 2605.21384, 2026). Mein Ausweg aus diesem Dilemma sind menschlich kuratierte oder vom Menschen inhaltlich vorgegebene End-to-End-Tests. Die Szenarien und Erwartungswerte kommen aus der Fachlichkeit; der implementierende Agent führt sie aus, schreibt und ändert sie aber nicht. Ergänzend kann ein Teil der Szenarien zurückgehalten und erst nach Abschluss der Implementierung ausgeführt werden. Das kostet menschliche Arbeitszeit an einer Stelle, an der sie sich lohnt, denn diese Tests sind das einzige Artefakt der ganzen Kette, das der Agent weder erzeugt noch umformulieren darf.

Jede Implementierung durchläuft außerdem eine Schleife aus unabhängigen Audits. Das Muster habe ich in „Die zweite Spur“ ausführlich beschrieben; hier genügt der Kern. Ein Agent implementiert, ein zweiter Agent mit frischem Kontext und dem ausdrücklichen Auftrag zur Widerlegung prüft das Ergebnis, und ein maschinenlesbares Verdikt entscheidet über den Merge. In Projekt A ist zusätzlich vorgeschrieben, dass Prüfer und Implementierer aus verschiedenen Modellfamilien stammen; sind beide gleich, wird das Urteil verworfen. Der Prüfer läuft dort in einem eigenen, schreibgeschützten Arbeitsverzeichnis ohne Werkzeugzugriff auf die laufende Sitzung, und sein Prompt, sein Rohprotokoll und sein Urteil werden über Prüfsummen aneinander gebunden, damit sich ein Verdikt später einem exakten Stand zuordnen lässt. Die Schleife entsteht, weil ein „nicht bestanden“ eine Korrekturrunde auslöst und die Korrektur erneut geprüft wird.

Dass diese Schleifen reale Defekte finden und nicht nur Formalien, zeigen die Verdikt-Statistiken. Die maschinenlesbaren Verdikte der Audit-Artefakte in Projekt A lauten 77-mal „fail“, 53-mal „pass“ und 9-mal „inconclusive“; in Projekt B endeten 23 von 82 protokollierten Gate-Durchläufen mit „fail“. Fast alle in diesem Beitrag zitierten Drift-Fälle stammen aus genau diesen Prüfläufen. Ohne die Auditoren wären sie im System geblieben, denn die jeweilige Implementierung hatte sich selbst als fertig gemeldet.

Die Prüfer haben ihrerseits Grenzen. In Projekt A fand die Nachkontrolle einen Begründungsfehler im Bericht eines Prüfmodells. Der Bericht entlastete einen Testfehler mit der Behauptung, die betroffene Datei sei unverändert, was das Diff widerlegte. Ein als Richter eingesetztes Modell durchläuft dort inzwischen selbst ein Kalibrierungsverfahren mit unabhängiger Doppel-Etikettierung und ist nach aktuellem Stand nicht für den unbeaufsichtigten Einsatz freigegeben.

Die Forschung stützt beide Vorsichtsmaßnahmen. Eine Auswertung von rund 541.000 Urteilen von 21 Judge-Modellen fand hohe Konsistenz bei zugleich schwacher Validität; die Autorinnen und Autoren fordern ein eigenes Validierungsprotokoll für Judges (arXiv 2606.19544, 2026). Cross-Model-Review wirkt zudem richtungsabhängig. In einer Studie hob ein Claude-Review über Codex-Entwürfe die Erfolgsrate von 71,6 auf 89,7 Prozent, während die umgekehrte Paarung sie von 91,4 auf 82,8 Prozent senkte (arXiv 2607.21656, 2026). Welche Familie implementiert und welche prüft, ist damit selbst eine Entscheidung, die validiert werden muss.

Die dritte Gegenmaßnahme setzt vor der Implementierung an, bei der Form der Spezifikation. Prosa ist für Agenten über lange Zeiträume zu mehrdeutig; jede der vier Drift-Richtungen aus dem Befund ist am Ende eine Eigenschaft von Text, den niemand ausführt. Daraus folgt ein Shift Left zu formaleren Spezifikationen. Ein Mensch oder ein dafür abgestellter Lead-Agent schreibt zuerst Integrationstests, gegen die implementiert wird; wo eine Testform nicht reicht, hilft eine domänenspezifische Notation, die sich maschinell auswerten lässt. Ein fehlschlagender Test ist eine harte Spezifikation. Er driftet nicht, denn er bleibt rot, bis der Code passt; eine Markdown-Sektion kann dagegen monatelang Falsches behaupten.

In Ansätzen existiert diese Form in beiden Projekten bereits. Projekt A hält zehn eigene Drift-Testklassen, die Register, Konfigurationsfelder und Manifeste bei jedem Lauf gegen den Code prüfen. Projekt B betreibt Sabotage-Gates, die mit einer definierten Fehlerkennung abbrechen, sobald ein Vertrag verletzt ist; eines davon hat allerdings auch schon wegen eines Tooling-Artefakts falschen Alarm geschlagen. Die Grenzen von weiter oben gelten fort. Ein Test, den der implementierende Agent formen darf, kann tautologisch geraten, und was jenseits des Testbaren liegt, etwa Architekturabsichten und Begründungen, braucht weiterhin Prosa, nur deutlich weniger davon. Für den prüfbaren Kern der Anforderungen ist ein Test trotzdem die stabilste Form, die ich in beiden Projekten gesehen habe.

Was es kostet

Der sichtbarste Posten ist der Token-Verbrauch. Die Betriebsnotizen von Projekt B halten fest, dass gestrandete Agenten-Läufe, die an Sitzungsgrenzen ohne Commit hängen blieben, pro Wiederaufnahme 250.000 bis 350.000 Tokens verbrannten, ohne Fortschritt. Die Ausgaben eines einzelnen Prüflaufs erreichen dort 500 Kilobyte bis ein Megabyte Text. In Projekt A protokollieren die Audit-Artefakte das Verhältnis zwischen internem Arbeitslog und sichtbarem Ergebnis: gut 8.300 Zeilen Rohprotokoll für ein Urteil von 64 Zeilen, und dieser Aufwand wird pro Korrekturrunde erneut fällig.

Dazu kommt Betriebsaufwand, der in keiner Token-Rechnung auftaucht. Die Notizen aus Projekt B beschreiben Agenten, die ohne Abschlussmeldung hängen bleiben und sich nur über Indizien erkennen lassen, etwa ausbleibende Dateiänderungen bei gleichzeitig fehlenden Prozessen. Festgehalten ist dort auch die Disziplin, pro Arbeitsbereich nur einen aktiven Agenten laufen zu lassen, weil ein vorschnell gestarteter Ersatz-Agent halbfertige Stände überschreibt. Ein wiederaufgenommener Agent hat einmal fremde, noch nicht committete Arbeit verworfen; seither gilt die Regel, dass Verwerfen nur auf reversiblem Weg erlaubt ist.

Ein eigenes Problem ist der Hang der Modelle zum Mikromanagement. Sich selbst überlassen, eskaliert die Prüf-Schleife. Die Extremwerte stammen aus Projekt A. Ein einzelnes Ticket sammelte 96 Audit-Dokumente an, ein anderes durchlief 23 Runden in zwei Kalendertagen, und ein reines Spezifikationsartefakt ohne eine Zeile Produktcode wurde neunmal re-auditiert; die neunte Runde änderte gegenüber der achten noch 122 hinzugefügte und 75 entfernte Markdown-Zeilen. Die Modelle erfinden dabei immer feinere Prüfanlässe: Bisektionsschritte, Diagnose-Tickets, Zwischenabnahmen. Die Projektnotizen benennen das inzwischen ausdrücklich als Rückfall, den es zu vermeiden gilt. In Projekt B habe ich selbst eingegriffen und einen Agenten gestoppt, der die dritte Korrekturrunde auf demselben Test drehte, während der Produktcode längst korrekt war.

Ohne feste Abbruchregeln, die die Schleife von außen begrenzen, kippt der Ansatz deshalb. In Projekt A haben sich mehrere Formen solcher Circuit Breaker etabliert. Eine Zwei-Korrekturrunden-Regel beendet die Schleife nach zwei erfolglosen Runden und erzwingt eine Entscheidung zwischen Akzeptieren mit dokumentiertem Risiko, Descoping oder Abbruch. Diese Grenze hat empirische Entsprechungen. Über sieben Modelle hinweg konzentrieren sich die Gewinne von Selbstkorrektur-Schleifen in den ersten zwei Runden (arXiv 2604.10508, 2026), und Mehr-Agenten-Debatten kosteten in einer Untersuchung mit kleineren Modellen das 2,1- bis 3,4-Fache an Tokens bei gleicher oder schlechterer Genauigkeit, wobei Peer-Kritik zuvor korrekte Lösungen destabilisierte (arXiv 2605.00914, 2026). Gezählte Freigaben deckeln teure Läufe vorab: Ein Beschluss-Artefakt autorisiert genau einen Start, ohne selektive Wiederholungen und ohne Rosinenpicken aus historischen Läufen. Ein Parallelitätsdeckel beschränkt die gleichzeitig aktiven Implementierungsstränge auf zwei, und ein Prosa-Deckel stellt pro Arbeitspaket die hinzugefügten Markdown-Zeilen den hinzugefügten Produktcode-Zeilen gegenüber, damit die Dokumentation den Code nicht überwuchert. Bemerkenswert finde ich, dass die jüngste Maßnahme in die Gegenrichtung zeigt: ein ausdrückliches Autonomie-Mandat, das dem Implementierungsstrang Zwischenmeldungen untersagt und nur wenige definierte Rückkehrpunkte vorsieht.

Bilanz

Spec-Driven Development hat sein zentrales Versprechen in zwei disziplinierten, langlaufenden Projekten nicht eingelöst. Die Spezifikation ist gegen den Code gedriftet, Spezifikationen haben einander widersprochen, einzelne Artefakte sogar sich selbst. Nach allem, was die Audit-Artefakte zeigen, hätte auch mehr Disziplin das nicht abgestellt: Drift war die Grundrate eines Arbeitsmodells aus monatelangen Workflows und hunderten Kontextwechseln.

Funktioniert hat eine andere Architektur der Verlässlichkeit: End-to-End-Tests prüfen das Verhalten des Systems, unabhängige Auditoren fangen in ihrer Schleife einen großen Teil der Defekte, die die Implementierung als erledigt gemeldet hatte, und Abbruchregeln halten diese Schleife bezahlbar. Wo Anforderungen von vornherein als Tests vorliegen, verkleinert sich zudem die Prosa-Fläche, auf der Drift überhaupt entstehen kann. Die Spezifikation wechselt in diesem Aufbau ihre Rolle. Sie bleibt Ausgangspunkt und Prüfreferenz, an der Abweichungen sichtbar werden, über die dann bewusst entschieden wird; die Rolle der Quelle, aus der das System zuverlässig hervorgeht, hat sie in beiden Projekten nicht ausgefüllt. Die Studienlage passt dazu: Eine explizite Spezifikationsphase verbessert Testpass-Raten messbar, um 7 bis 21 Punkte in einer aktuellen Untersuchung, determiniert das Ergebnis aber nicht (arXiv 2607.27167, 2026). Ein Teil der Forschung verfolgt die Gegenstrategie und will Drift technisch unterbinden, etwa durch Gates, die Spec-Code-Divergenz zum Merge-Blocker machen (arXiv 2606.27045, 2026). Ob das über Monate durchhaltbar bleibt oder nur den Punkt verschiebt, an dem die Pflegekosten anfallen, ist empirisch offen.

Eine Lösung des Grundproblems ist auch das nicht. E2E-Validierung, Auditoren-Schleifen, ausführbare Spezifikationen und Circuit Breaker sind Mitigationen. Sie machen Drift sichtbar und geben ihm einen Preis; in beiden Projekten ist er trotzdem geblieben. Solange die Arbeit von Akteuren erledigt wird, die kein dauerhaftes Gedächtnis haben und das Gesamtsystem nie vollständig sehen, entsteht Drift an jeder Naht neu. Die Prüfarchitektur arbeitet gegen ein Symptom; die Ursache liegt im Zuschnitt der heutigen Werkzeuge.

Offen bleibt für mich die Kostenfrage. In beiden Projekten war der Aufwand für Spezifikation, Audit und Evidenz zusammengenommen größer als der Produktcode, in Zeilen gemessen. Ob eine bewusst kleinere Spezifikationsoberfläche mit früheren Verhaltenstests am Ende günstiger wäre, kann ich aus zwei Projekten nicht ableiten. Sicher scheint mir nur ein Posten dieser Rechnung: die laufende Pflege von mehreren hunderttausend Zeilen Prosa, samt deren eigener Drift.

Datenbasis

Alle Zahlen und Fallbeispiele aus den beiden Projekten stammen aus deren Repositories: aus Git-Historien, Ticket-Beständen, Betriebsnotizen und den maschinenlesbaren Audit- und Gate-Artefakten. Die Projekte sind interne Vorhaben und hier bewusst nur über Kennzahlen beschrieben.

Quellen

• How Coding Agents Fail Their Users: A Large-Scale Analysis of Developer-Agent Misalignment in 20,574 Real-World Sessions, arXiv 2605.29442 (2026), https://arxiv.org/abs/2605.29442
• SpecBench: Evaluating Specification-Level Reasoning for Software Engineering LLM Agents, arXiv 2605.30314 (2026), https://arxiv.org/abs/2605.30314
• Citation Discipline in Spec-Driven Development: A Cross-Model Empirical Study of Output Determinism and Automated Hallucination Detection in LLM-Generated Code, arXiv 2606.30689 (2026), https://arxiv.org/abs/2606.30689
• SpecFirst: Behavioral Specification Elicitation as a First-Class Step in Agent-Based Program Synthesis from Scratch, arXiv 2607.27167 (2026), https://arxiv.org/abs/2607.27167
• The Spec Growth Engine: Spec-Anchored, Code-Coupled, Drift-Enforced Architecture for AI-Assisted Software Development, arXiv 2606.27045 (2026), https://arxiv.org/abs/2606.27045
• SpecBench: Measuring Reward Hacking in Long-Horizon Coding Agents, arXiv 2605.21384 (2026), https://arxiv.org/abs/2605.21384
• Cross-Model LLM Code Review: Should you use Claude to review Codex or vice versa?, arXiv 2607.21656 (2026), https://arxiv.org/abs/2607.21656
• Reliability without Validity: A Systematic, Large-Scale Evaluation of LLM-as-a-Judge Models Across Agreement, Consistency, and Bias, arXiv 2606.19544 (2026), https://arxiv.org/abs/2606.19544
• How Many Tries Does It Take? Iterative Self-Repair in LLM Code Generation Across Model Scales and Benchmarks, arXiv 2604.10508 (2026), https://arxiv.org/abs/2604.10508
• The Cost of Consensus: Isolated Self-Correction Prevails Over Unguided Homogeneous Multi-Agent Debate, arXiv 2605.00914 (2026), https://arxiv.org/abs/2605.00914
• Atlassian Engineering: Why AI Agents Drift Mid-Task and How a Multi-Agent System Fixes It (23. Juni 2026), https://www.atlassian.com/blog/development/specialist-agent-orchestration-jira
• Thoughtworks Technology Radar: Spec-driven development (Ring „Assess“, Stand November 2025), https://www.thoughtworks.com/radar/techniques/spec-driven-development