In den letzten zwei Jahren hat sich im Software-Engineering etwas leise umgekehrt. Fast die gesamte Branchengeschichte hindurch war der Code das Artefakt und die Spezifikation das Wegwerfgerüst darum herum: ein Dokument, einmal geschrieben, zweimal überflogen und im dritten Sprint aufgegeben. Inzwischen schreiben KI-Agenten einen wachsenden Anteil des Codes, und die Ökonomie hat sich gedreht. Code ist billig geworden, in der Herstellung wie in der Neuerzeugung; knapp ist die präzise Aussage darüber, was der Code leisten muss. Die Spezifikation ist kein Gerüst mehr. Sie ist das Engineering-Artefakt.
Teams, die sie so behandeln, gewinnen aus Agenten einen Hebel, der sich verzinst: Sie übergeben klar definierte Arbeit, verifizieren das Ergebnis mechanisch und mergen mit Zuversicht. Teams, die es nicht tun, bekommen eine neue Art technischer Schulden, nämlich plausibel aussehenden Code, den niemand bestellt hat, schneller erzeugt, als ihn irgendjemand reviewen kann. Der Unterschied zwischen beiden liegt weder am Modell noch am Tooling. Er liegt daran, ob die Spec ein Vertrag ist.
Ein Prompt ist keine Spec
Der häufigste Fehler besteht darin, das Chatfenster für die Spec zu halten. Ein Prompt ist ein Gesprächseinstieg: Er beschreibt die Absicht in Prosa, überlässt die Randfälle dem Wohlwollen des Lesers und verschwindet im Scrollback, sobald er abgeschickt ist. Niemand kann ihn reviewen, diffen oder drei Wochen später darauf zeigen, wenn das Verhalten strittig wird. Ein Agent mit einem Prompt verhält sich wie ein Handwerker, der seinen Auftrag im Flur bekommen hat: Er füllt jede Lücke mit eigenen Annahmen, und zwar ohne zu zögern.
Eine Spec ist ein anderes Objekt. Sie liegt im Repository, direkt neben dem Code, den sie regelt. Sie ist versioniert, sodass sichtbar bleibt, 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, was die entscheidende Eigenschaft ist: Für jedes gelieferte Stück Arbeit gibt es einen mechanischen Weg, die Frage zu stellen, ob es die Spec erfüllt, ja oder nein. Sobald diese Frage eine Ermessensentscheidung verlangt, haben Sie Prosa und keinen Vertrag.
Was eine Spec zum Vertrag macht
Vier Zutaten trennen einen Vertrag von einem Wunsch. Abnahmekriterien kommen 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 so lange um, bis Sie es können.
Durchgerechnete Beispiele kommen als Zweites, und sie leisten mehr als jeder andere Abschnitt: konkrete Paare aus Eingabe und Ausgabe, einschließlich der hässlichen Fälle wie der leeren Liste, der doppelten Übermittlung, dem Zeitzonen-Randfall und dem 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 noch abgeschrieben werden müssen.
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 beim Zahlungsanbieter ohne Idempotenzschlüssel. Invarianten sind die Leitplanken, die ein Refactoring überstehen, und das zählt doppelt, wenn das Refactoring ein Agent durchführt, der nie in dem Meeting saß, in dem die Regel erklärt wurde.
Nicht-Ziele kommen zuletzt und werden am häufigsten vergessen. Der Fehlermodus eines Agenten ist selten, zu wenig zu tun; er tut zu viel, erfindet Konfigurationsoptionen, ergänzt Caching, das niemand bestellt hat, und „verbessert“ angrenzenden Code. 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 eigenen Annahmen, und zwar ohne zu zögern. Der Vertrag existiert, damit es keine Lücke gibt, die sich zu füllen lohnt.
Verträge brauchen Durchsetzung
Ein Vertrag, den niemand durchsetzt, ist Dekoration. Erst die Durchsetzungsschicht macht Spec-Driven Development zur Engineering-Praxis statt zur Dokumentationsgewohnheit, und sie besteht aus drei Teilen. Erstens: Tests als die ausführbare Form des Vertrags. Abnahmekriterien und durchgerechnete Beispiele werden in eine Testsuite überführt, bevor der Agent die erste Zeile Implementierung schreibt. Die Suite ist die Spec, kompiliert in etwas, das eine Maschine prüfen kann; die Aufgabe des Agenten besteht darin, sie zum Bestehen zu bringen, ohne sie zu verwässern. Schützen Sie die Tests im Review, denn 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 aussehendem, aber falschem Output in Compile-Fehler und Validierungsfehlschläge. Dieses Feedback bekommt der Agent in Sekunden und mitten in der Schleife, während ein Reviewer es erst Tage später liefern würde. Je strikter die Grenze, desto weniger Raum bleibt, durch den selbstsicherer Unsinn sickern kann.
Drittens: Review-Gates, die das Diff am Vertrag messen. Menschliches Review verschwindet nicht, es wechselt das Ziel. Agenten-Output Zeile für Zeile in Agentengeschwindigkeit zu prüfen ist ein verlorenes Spiel, weil es schlicht mehr Code gibt als Aufmerksamkeit. Das Diff am Vertrag zu prüfen ist dagegen 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 und kein Bonus.
Drei Muster des Scheiterns
Vage Spec, selbstsicherer Unsinn. Das Team schreibt drei Stichpunkte, der Agent produziert 800 Zeilen, und die Lücke zwischen Absicht und Verhalten fällt erst in der Produktion auf. Woran Sie es erkennen: an Review-Gesprächen, die mit „so war das nicht gemeint“ beginnen - einem Satz, der die Spec anklagt und nicht den Agenten. Die Lösung ist unspektakulär: mehr Beispiele, schärfere Kriterien, und zwar geschrieben vor der Generierung statt danach.
Überspezifikation, kein Hebel. Das ist der Graben auf der anderen Seite. Wenn die Spec die Implementierung Datei für Datei und Funktion für Funktion diktiert, haben Sie den Code zweimal geschrieben, einmal in Prosa und einmal in der Sprache, in der er läuft, und der Agent ist auf eine Schreibkraft reduziert. Spezifizieren Sie das Verhalten an der Grenze und die Invarianten dahinter, und überlassen Sie die Implementierung der Partei, die sie schreibt. Wenn das Spezifizieren einer Aufgabe länger dauert als ihre Erledigung, 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 dagegen 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 ist das eine kurze Schleife. Schreiben Sie den Vertrag aus Kriterien, Beispielen, Invarianten und Nicht-Zielen, und lassen Sie ihn von den Menschen prüfen, die später mit dem Verhalten leben; an dieser Stelle 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 auf die fehlschlagende Suite hin entwickeln, so lange, bis die mechanischen Prüfungen aus Tests, Typen, Schemas und Lintern bestehen, ohne dass die Prüfungen selbst angetastet wurden. Messen Sie das Diff anschließend am Vertrag und nicht an Ihrer Geduld: Kriterien erfüllt, Invarianten gehalten, nichts außerhalb der Nicht-Ziele. Der Merge hält Vertrag und Erfüllung in einer atomaren Einheit fest, 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 leisten muss und wo er endet. Dieselbe Eigenschaft, die eine Spec prüfbar macht, macht sie komponierbar, und genau deshalb beaufsichtigt ein kleines Senior-Team heute eine Menge gleichzeitiger Implementierung, für die es 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 und nicht auf Zuruf des Agenten. Ein Agent, der „alle Tests bestehen“ meldet, liefert eine Behauptung; eine grüne Pipeline auf einer unveränderten Testsuite liefert einen Fakt. Vertrag, Tests und Pipeline bilden zusammen einen neutralen Schiedsrichter, dem gleichgültig ist, ob der Code von einem Menschen mit einem schlechten Tag oder von einem Modell mit einem selbstsicheren Tag stammt. Genau diese Gleichgültigkeit macht den Output vertrauenswürdig.
Teams, die das einführen, stellen fest, dass der Engpass gewandert ist. Die knappe Fähigkeit ist nicht mehr, Code zu produzieren, sondern präzise zu entscheiden, was der Code leisten soll, und das 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 wer etwas anderes behauptet, verhindert die Einführung. Der Vertrag zahlt sich aus, wenn die Arbeit folgenreich ist und ein Fehler echte Kosten hat: bei Systemen, die Geld bewegen, Kundendaten berühren, an Teamgrenzen liegen oder von Menschen und Agenten gewartet werden, die nicht dabei waren, als die Entscheidungen fielen. Am schnellsten rechnet er sich genau dort, wo sich Agenten-Output mit bloßem Auge am schwersten prüfen lässt.
Overhead ist er für Spikes, Prototypen und Einwegskripte, also für Code, dessen ganzer Zweck darin besteht, 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 Sie gerade arbeiten, und ehrlich zu sein, sobald ein Prototyp leise anfängt, ein System zu werden. In diesem Moment wird der Vertrag geschrieben, nicht beim Rewrite sechs Monate später.
Die Branche hat zwei Jahrzehnte gebraucht, um zu lernen, dass Tests keine Bürokratie sind, sondern das, was schnelles Arbeiten erlaubt, 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 leisten muss - und die Teams, die diese Aussage als Vertrag schreiben, sind die, bei denen sich die Agenten tatsächlich verzinsen.