In den letzten zwei Jahren hat sich im Software-Engineering etwas leise umgekehrt. Die längste Zeit der Branchengeschichte war der Code das Artefakt und die Spezifikation das Wegwerfgerüst darum herum — ein Dokument, einmal geschrieben, zweimal überflogen und im dritten Sprint aufgegeben. Jetzt schreiben KI-Agenten einen wachsenden Anteil des Codes, und die Ökonomie hat sich gedreht. Code wurde billig zu produzieren und billig zu regenerieren. Knapp ist eine präzise Aussage darüber, was der Code tun muss. Die Spezifikation ist kein Gerüst mehr. Sie ist das Engineering-Artefakt.
Teams, die sie so behandeln, holen aus Agenten einen Hebel, der sich aufzinst: Sie übergeben klar definierte Arbeit, verifizieren das Ergebnis mechanisch und mergen mit Zuversicht. Teams, die es nicht tun, bekommen eine neue Art technischer Schulden — plausibel aussehenden Code, den niemand bestellt hat, schneller generiert, als ihn irgendjemand reviewen kann. Der Unterschied zwischen beiden ist nicht das Modell oder das Tooling. Es ist die Frage, ob die Spec ein Vertrag ist.
Ein Prompt ist keine Spec
Der häufigste Fehler ist, das Chatfenster als Spec zu behandeln. Ein Prompt ist ein Gesprächseinstieg: Er beschreibt die Absicht in Prosa, überlässt die Randfälle dem Wohlwollen des Lesers und verschwindet in dem Moment im Scrollback, in dem er abgeschickt ist. Niemand kann ihn reviewen, diffen oder drei Wochen später darauf zeigen, wenn das Verhalten strittig ist. Ein Agent mit einem Prompt tut, was ein Handwerker mit einem Flurgespräch tut: Er füllt jede Lücke mit seinen eigenen Annahmen — selbstbewusst.
Eine Spec ist ein anderes Objekt. Sie lebt im Repository, direkt neben dem Code, den sie regelt. Sie ist versioniert, sodass man sehen kann, was vereinbart wurde und wann es sich geändert hat. Sie ist reviewbar, sodass eine Kollegin der Anforderung widersprechen kann statt der Implementierung. Und sie ist prüfbar — die entscheidende Eigenschaft —, was bedeutet: Für jedes gelieferte Stück Arbeit gibt es einen mechanischen Weg zu fragen: Erfüllt das die Spec, ja oder nein? In dem Moment, in dem diese Frage eine Ermessensentscheidung erfordert, haben Sie Prosa, keinen Vertrag.
Was eine Spec zum Vertrag macht
Vier Zutaten trennen einen Vertrag von einem Wunsch. Abnahmekriterienkommen zuerst: beobachtbare, binäre Aussagen über Verhalten. „Schnell“ ist ein Wunsch; „p95 unter 200 ms bei 50 Anfragen pro Sekunde“ ist ein Kriterium. „Kommt mit fehlerhaften Eingaben zurecht“ ist ein Wunsch; „weist fehlerhafte Payloads mit einem 422 und einem maschinenlesbaren Fehlercode ab“ ist ein Kriterium. Wenn Sie Bestanden oder Durchgefallen nicht von außerhalb der Implementierung entscheiden können, schreiben Sie um, bis Sie es können.
Durchgerechnete Beispiele kommen als Zweites, und sie leisten mehr als jeder andere Abschnitt. Konkrete Eingabe-Ausgabe-Paare — einschließlich der hässlichen: die leere Liste, die doppelte Übermittlung, der Zeitzonen-Randfall, der Nutzer, der ein Emoji ins Betragsfeld einfügt. In den Beispielen kommen die versteckten Annahmen an die Oberfläche. Sie sind außerdem, nicht zufällig, Testfälle, die nur darauf warten, abgeschrieben zu werden.
Invarianten kommen als Drittes: Eigenschaften, die gelten müssen, egal welchen Weg die Implementierung nimmt. Salden werden nie negativ. Jeder Zustandsübergang wird protokolliert. Löschungen sind soft. Kein Aufruf des Zahlungsanbieters ohne Idempotenzschlüssel. Invarianten sind die Leitplanken, die Refactorings überleben — was doppelt zählt, wenn das Refactoring ein Agent durchführt, der nie in dem Meeting saß, in dem die Regel erklärt wurde.
Nicht-Zielekommen zuletzt und werden am meisten vernachlässigt. Der Fehlermodus eines Agenten ist selten, zu wenig zu tun; es ist, zu viel zu tun — Konfigurationsoptionen zu erfinden, Caching hinzuzufügen, das niemand bestellt hat, angrenzenden Code zu „verbessern“. Eine kurze Liste dessen, was diese Änderung nicht anfassen und welche Probleme sie nicht lösen darf, ist die billigste Scope-Kontrolle, die Sie je schreiben werden.
Ein Agent füllt jede Lücke in der Spec mit seinen eigenen Annahmen — selbstbewusst. Der Vertrag existiert, damit es keine Lücken gibt, die sich zu füllen lohnen.
Verträge brauchen Durchsetzung
Ein Vertrag, den niemand durchsetzt, ist Dekoration. Die Durchsetzungsschicht macht Spec-Driven Development zur Engineering-Praxis statt zur Dokumentationsgewohnheit, und sie hat drei Teile. Erstens: Tests als die ausführbare Form des Vertrags. Abnahmekriterien und durchgerechnete Beispiele werden in eine Testsuite überführt, bevor der Agent Implementierungscode schreibt. Die Suite ist die Spec, kompiliert in etwas, das eine Maschine prüfen kann; die Aufgabe des Agenten ist, sie zum Bestehen zu bringen, ohne sie zu verwässern. Schützen Sie die Tests selbst im Review — ein Agent, der eine Assertion ändert, damit sie durchläuft, hat den Vertrag einseitig neu verhandelt.
Zweitens: typisierte Grenzen. Schemas, Typen und API-Verträge nageln jede Schnittstelle fest, die der Code des Agenten berührt. Ein striktes Schema an der Grenze verwandelt eine ganze Klasse von plausibel-aber-falschem Output in Compile-Fehler und Validierungsfehlschläge — Feedback, das der Agent in Sekunden bekommt, in der Schleife, statt Feedback, das ein Reviewer Tage später liefert. Je strikter die Grenze, desto weniger Raum bleibt für selbstbewussten Müll, um hindurchzusickern.
Drittens: Review-Gates, die das Diff mit dem Vertrag vergleichen. Menschliches Review verschwindet nicht; es wechselt das Ziel. Agenten-Output Zeile für Zeile in Agentengeschwindigkeit zu reviewen ist ein verlorenes Spiel — es gibt schlicht mehr Code als Aufmerksamkeit. Das Diff gegen den Vertrag zu reviewen ist machbar: Erfüllt die Änderung jedes Abnahmekriterium, respektiert sie jede Invariante, bleibt sie innerhalb der Nicht-Ziele? Alles im Diff, was der Vertrag nicht erklärt, ist die erste Frage des Reviews, kein Bonus.
Die drei Arten, wie es schiefgeht
Vage Spec, selbstbewusster Müll.Das Team schreibt drei Stichpunkte, der Agent produziert achthundert Zeilen, und die Lücke zwischen Absicht und Verhalten wird in der Produktion entdeckt. Das Erkennungszeichen sind Review-Gespräche, die mit „das habe ich nicht gemeint“ beginnen — ein Satz, der die Spec anklagt, nicht den Agenten. Die Lösung ist unspektakulär: mehr Beispiele, schärfere Kriterien, geschrieben vor der Generierung statt danach.
Überspezifikation, kein Hebel. Der Graben auf der anderen Seite. Wenn die Spec die Implementierung diktiert — Datei für Datei, Funktion für Funktion —, haben Sie den Code zweimal geschrieben, einmal auf Deutsch und einmal in der Sprache, in der er läuft, und der Agent ist auf eine Schreibkraft reduziert. Spezifizieren Sie Verhalten an der Grenze und die Invarianten darin; überlassen Sie die Implementierung der Partei, die sie schreibt. Wenn das Spezifizieren einer Aufgabe länger dauert als das Erledigen, brauchte diese Aufgabe keinen Agenten.
Spec-Drift. Der leiseste Fehlschlag. Der Vertrag sagte das eine, die Produktion entwickelte sich zum anderen, und nach drei Monaten kleiner Neuverhandlungen im Vorbeigehen beschreibt die Spec ein System, das nicht mehr existiert. Drift ist unvermeidlich; unprotokollierter Drift ist eine Entscheidung. Die Regel, die ihn verhindert, kostet einen Satz: Verhaltensänderungen landen zuerst als Spec-Änderungen, im selben Pull Request — oder sie landen gar nicht.
Der Workflow, von Anfang bis Ende
In der Praxis sieht das wie eine kurze Schleife aus. Schreiben Sie den Vertrag — Kriterien, Beispiele, Invarianten, Nicht-Ziele — und lassen Sie ihn von den Menschen reviewen, die mit dem Verhalten leben werden; hier ist Widerspruch billig. Überführen Sie die prüfbaren Teile in Tests, die fehlschlagen. Übergeben Sie den Vertrag an den Agenten und lassen Sie ihn gegen die fehlschlagende Suite entwerfen, iterierend, bis die mechanischen Prüfungen — Tests, Typen, Schemas, Linter — bestehen, ohne dass die Prüfungen selbst angetastet wurden. Reviewen Sie dann das Diff gegen den Vertrag, nicht gegen Ihre Geduld: Kriterien erfüllt, Invarianten gehalten, nichts außerhalb der Nicht-Ziele. Der Merge protokolliert den Vertrag und seine Erfüllung in einer atomaren Einheit, und die nächste Aufgabe startet von einer ehrlichen Basislinie.
Die Schleife hat einen Effekt zweiter Ordnung, der Teams überrascht: Verträge machen Agentenarbeit parallelisierbar. Zwei Agenten auf einem vagen Briefing kollidieren; fünf Agenten auf fünf Verträgen mit typisierten Grenzen dazwischen mergen sauber, weil jeder Vertrag festhält, was sein Teil tun muss und wo er endet. Dieselbe Eigenschaft, die eine Spec prüfbar macht, macht sie komponierbar — und so beaufsichtigt ein kleines Senior-Team eine Menge gleichzeitiger Implementierung, die vor fünf Jahren eine Abteilung gebraucht hätte.
Eine weitere mechanische Regel hält die Schleife ehrlich: Die Prüfungen laufen in der CI, nicht auf Zuruf des Agenten. Ein Agent, der „alle Tests bestehen“ meldet, ist eine Behauptung; eine grüne Pipeline auf einer unveränderten Testsuite ist ein Fakt. Der Vertrag, seine Tests und die Pipeline bilden zusammen einen neutralen Schiedsrichter, dem egal ist, ob der Code von einem Menschen mit einem schlechten Tag oder einem Modell mit einem selbstbewussten geschrieben wurde — und genau diese Gleichgültigkeit macht den Output vertrauenswürdig.
Teams, die das einführen, entdecken, dass der Engpass gewandert ist. Die knappe Fähigkeit ist nicht mehr, Code zu produzieren — sie ist, präzise zu entscheiden, was der Code tun soll, und es prüfbar auszudrücken. Das war schon immer der schwierige Teil von Software; Agenten haben das Problem nicht geschaffen, sie haben nur den Ort beseitigt, an dem es sich früher verstecken konnte.
Wann es sich auszahlt — und wann es Overhead ist
Spec-Driven Development ist nicht gratis, und das Gegenteil zu behaupten tötet die Einführung. Der Vertrag zahlt sich aus, wenn die Arbeit folgenreich ist und die Kosten eines Fehlers real sind: Systeme, die Geld bewegen, Kundendaten berühren, auf Teamgrenzen sitzen oder von Menschen — und Agenten — gewartet werden, die nicht dabei waren, als die Entscheidungen fielen. Am schnellsten rechnet er sich genau dort, wo Agenten-Output mit bloßem Auge am schwersten zu reviewen ist.
Er ist Overhead für Spikes, Prototypen und Einwegskripte — Code, dessen ganzer Zweck ist, weggeworfen zu werden, sobald er eine Frage beantwortet hat. Schreiben Sie einen Satz Absicht, lassen Sie den Agenten laufen, behalten Sie die Erkenntnis und löschen Sie den Code. Die Disziplin besteht darin zu wissen, in welchem Modus man sich befindet — und ehrlich zu sein in dem Moment, in dem ein Prototyp leise anfängt, ein System zu werden. Dieser Moment — nicht der Rewrite sechs Monate später — ist der, in dem der Vertrag geschrieben wird.
Die Branche hat zwei Jahrzehnte gebraucht, um zu lernen, dass Tests keine Bürokratie sind, sondern das, was einen schnell bewegen lässt, ohne das Wichtige zu zerbrechen. Specs machen jetzt dieselbe Reise, aus demselben Grund. Wenn die Grenzkosten des Codeschreibens gegen null gehen, konzentriert sich der Wert in der Aussage darüber, was der Code tun muss — und die Teams, die diese Aussage als Vertrag schreiben, sind die, bei denen sich die Agenten tatsächlich aufzinsen.