Vorgabe und Umfang

Vor jeder Runde steht ein Text: die Aufgabe. Wie viel darin steht, entscheidet jeder für sich, und die geläufige Annahme lautet, dass mehr Genauigkeit ein besseres Ergebnis ergibt.

Diese Annahme ist gemessen worden, von zwei Seiten, und beide Male fällt das Ergebnis anders aus als erwartet.

Die Form zählt, aber nicht bei jedem Modell

Ein kontrollierter Versuch vom August 2026 nimmt dieselbe Aufgabe und beschreibt sie fünfmal:

five informationally equivalent specification formats (externe Seite, arxiv.org)

Formloser Text, ein Diagramm mit Bedingungen, eine OpenAPI-Beschreibung, ein Architekturmodell und TypeScript-Verträge. Derselbe Inhalt, fünf Formen. Sechs Modelle aus drei Häusern bekommen jede davon.

Across 90 multi-turn agent trials, specification format shows a strong format x model interaction. (externe Seite, arxiv.org)

Der Befund hängt am Modell, und zwar umgekehrt zur Erwartung.

	Streuung der Qualität über die fünf Formen
stärkste Modelle (Sonnet 4.6, GPT-5)	0,17 bis 0,92
schwächere Modelle	0,83 bis 2,42

Quelle: der Versuch (externe Seite, arxiv.org), 90 Durchgänge, Stand 22.08.2026.

On the strongest models (Sonnet 4.6, GPT-5), format barely matters (quality spread 0.17-0.92) (externe Seite, arxiv.org)

Beim schwächsten Modell der Reihe verdreifacht eine der Formen die Abdeckung der Schnittstellenpfade, von einem Drittel auf alle:

TypeScript contracts triple API route coverage for the weakest model (33% to 100%). (externe Seite, arxiv.org)

Die Arbeit zieht daraus einen Schluss über die Kosten:

Structured architecture specifications serve as a capability equalizer, with value inversely proportional to model strength and the largest returns for cost-optimized deployments. (externe Seite, arxiv.org)

Wer am stärksten Modell arbeitet, gewinnt durch eine formalisierte Vorgabe also wenig. Wer aus Kostengründen ein kleineres fährt, gewinnt am meisten.

seitlich verschiebbar

eigene Darstellung nach dem Versuch zur Form von Architekturvorgaben, Stand 03.09.2026

Wo mehr Vorgabe kippt

Die zweite Messung geht die andere Richtung. Sie hält den Schnittstellenvertrag fest und häuft strukturelle Anforderungen an: Architekturmuster, Datenbank, Zuordnung von Objekten zu Tabellen. Hundert Aufgaben über acht Rahmenwerke.

as structural requirements accumulate, agent performance exhibits a substantial decline (externe Seite, arxiv.org)

Die Zahl dazu ist deutlich:

Evaluated configurations lose 27.28 points on average in assertion pass rates from baseline to fully specified tasks. (externe Seite, arxiv.org)

Gut 27 Punkte im Mittel über die elf bewerteten Paare aus Modell und Agentengerüst, gemessen an derselben Aufgabe mit und ohne die vollständige Vorgabe; in der Ergebnistabelle reicht der Verlust je Paar von 13,6 bis 45,5 Punkten. Die Arbeit selbst rät in Abschnitt 5.1, die genaue Größe des Effekts mit Vorsicht zu lesen, und hält die Richtung für belastbar. Kleinere Modelle und solche ohne Spezialisierung auf Code scheitern nach demselben Abschnitt schon ohne jede strukturelle Anforderung. Ausschlaggebend für den Verfall ist, was gleichzeitig erfüllt sein muss:

jointly satisfying functional and structural requirements remains a key open challenge for coding agents (externe Seite, arxiv.org)

Beide Messungen zusammen ergeben eine Kurve statt einer Geraden. Eine Vorgabe, die eine Form bekommt, hilft. Eine Vorgabe, die immer mehr Bedingungen gleichzeitig stellt, schadet.

Drei Handgriffe

Die Form richtet sich nach dem Modell. Am stärksten verfügbaren Modell kostet eine formalisierte Vorgabe Zeit und bringt gemessen wenig. Wo ein kleineres Modell arbeitet, ist sie das wirksamste Mittel, das die Erhebung kennt.

Bedingungen kommen nacheinander. Was in einem Durchgang gleichzeitig gelten muss, ist die Größe, an der die Leistung fällt. Eine Aufgabe in zwei Durchgängen mit je der Hälfte der Bedingungen ist etwas anderes als dieselbe Aufgabe mit allen.

Eine Vorgabe ersetzt keine Prüfung. Sie sagt, was entstehen soll, und entscheidet nichts darüber, ob es entstanden ist. Wie die Prüfung dazu aussieht, steht in Kapitel 07.

Die Ebene darunter nimmt die fünf Formen einzeln und zeigt, woran es liegt, dass die code-nahen davon vorne stehen.

Die fünf Formen aus der Ebene davor sind ausdrücklich gleichwertig: Jede enthält dieselbe Auskunft, nur anders aufgeschrieben. Wenn die Ergebnisse trotzdem auseinandergehen, liegt der Unterschied in der Form.

Was die fünf Formen unterscheidet

Form	Was daran festliegt
formloser Text	nichts, die Auslegung liegt beim Leser
Diagramm mit Bedingungen	die Beziehungen, in einer festen Notation
OpenAPI	jeder Pfad, jedes Feld, jeder Rückgabewert
Architekturmodell	die Bausteine und ihre erlaubten Verbindungen
TypeScript-Verträge	die Signaturen, prüfbar durch den Übersetzer

Von oben nach unten wächst, was eine Maschine daraus entscheiden kann. Genau entlang dieser Reihe fallen die Ergebnisse aus:

On weaker models, format produces spreads of 0.83-2.42 points, with code-proximate formats (OpenAPI, TypeScript contracts) recovering most of the capability gap (externe Seite, arxiv.org)

Der Grund dafür ist derselbe wie in Kapitel 07. Eine Signatur, die der Übersetzer ablehnt, meldet sich von selbst. Ein Absatz Prosa über dieselbe Signatur meldet sich nie.

Der Nebenbefund über die Kosten

Die Erhebung misst neben der Qualität den Verbrauch, und dort steht ein Satz, der die Rechnung umdreht:

Mid-tier models can consume more tokens than frontier models for worse output when they enter compilation debugging loops that stronger models avoid. (externe Seite, arxiv.org)

Ein kleineres Modell ist billiger je Token und kann teurer je Aufgabe werden, weil es in Übersetzungsfehlern kreist. Wer die Modellwahl über den Preis je Token entscheidet, rechnet an der falschen Größe. Woran sie sonst hängt, steht in Grundkurs, Kapitel 10.

Woran der Verfall hängt

Die zweite Erhebung nennt die Bedingung, unter der die Leistung fällt, und sie ist nicht die Länge der Vorgabe. Gemessen wurde an acht Rahmenwerken, und bei Modellen der Mittelklasse sind die Unterschiede zwischen ihnen groß:

mid-tier models succeed in minimal, explicit frameworks (e.g., Flask) but perform substantially worse on average in convention-heavy environments (e.g., FastAPI, Django) (externe Seite, arxiv.org)

Als Mittelklasse zählt die Arbeit GPT-5-mini und Qwen3-Coder-Next; bei ihnen liegen die schlanken Rahmenwerke im Mittel 26 bis 45 Punkte vor den konventionslastigen (Abschnitt 5.2). Bei den stärksten Modellen der Reihe, MiniMax-M2.5 und GPT-5.4, schließt sich die Lücke weitgehend, und die meisten Unterschiede zwischen den Rahmenwerken liegen dort innerhalb des Messfehlers. Ein konventionslastiges Rahmenwerk bringt eigene Regeln mit, die nirgends in der Aufgabe stehen. Die Vorgabe kommt zu diesen Regeln hinzu, und beide müssen gleichzeitig gelten. Was der Agent dabei am häufigsten verfehlt, benennt dieselbe Arbeit:

error analysis identifies data-layer defects (e.g., incorrect query composition and ORM runtime violations) as the leading root causes (externe Seite, arxiv.org)

Die Datenschicht ist die Stelle, an der die meisten stillschweigenden Regeln zusammenlaufen. Ein Fehler dort läuft zur Laufzeit auf und übersteht jede Prüfung, die nur den Text ansieht.

seitlich verschiebbar

eigene Darstellung nach der Erhebung zum Verfall bei strukturellen Anforderungen, Fassung vom 18.09.2026, Stand 21.09.2026

Warum die üblichen Prüfstände das übersehen

Die Arbeit beginnt mit einem Vorwurf an die Messlatten, an denen Agenten gewöhnlich gemessen werden:

Existing benchmarks often overlook these non-functional requirements, rewarding functionally correct but structurally arbitrary solutions (externe Seite, arxiv.org)

Eine Aufgabe gilt dort als gelöst, wenn der Test durchläuft. Ob die Lösung in den Bauplan des Projekts passt, misst niemand. Das ist dieselbe Lücke wie in Kapitel 11, eine Ebene früher: Dort ging es um das, was nach vielen Runden anwächst, hier um das, was in der einzelnen Runde nicht gefordert wird.

Die Vorgabe schreiben lassen

Eine formalisierte Vorgabe kostet Zeit, und das ist der Grund, aus dem sie meistens ausfällt. Claude Code kennt dafür einen eigenen Modus:

Plan mode tells Claude to research and propose changes without making them. (externe Seite, code.claude.com)

Claude reads files, runs shell commands to explore, and writes a plan, but does not edit your source. (externe Seite, code.claude.com)

Der Modus dreht die Reihenfolge um. Statt eine Vorgabe zu schreiben und dann prüfen zu lassen, ob sie zum Projekt passt, entsteht sie aus dem Projekt und wird danach gelesen. Eingeschaltet wird er mit Shift+Tab oder für eine einzelne Aufgabe mit /plan; wer ihn zur Voreinstellung machen will, setzt in .claude/settings.json:

{
  "defaultMode": "plan"
}

Was beim Zustimmen passiert, gehört mitgelesen:

Approving a plan exits plan mode and switches the session to the permission mode each approve option describes, so Claude starts editing. (externe Seite, code.claude.com)

Die Zustimmung zum Plan ist damit zugleich die Wahl eines Rechtemodus. Welche das sind und was sie erlauben, steht in Kapitel 08.

Wo der Plan-Modus aufhört

Eine Grenze steht in derselben Dokumentation, und sie betrifft genau die Umgebung, in der lange Läufe stattfinden:

Claude is still instructed to plan without editing, but a file edit or shell command it attempts during planning runs without prompting. (externe Seite, code.claude.com)

In einer Sitzung mit umgangenen Rückfragen ist der Plan-Modus also eine Anweisung an das Modell statt einer Sperre. Er sieht von außen gleich aus und hält nichts auf.

Die Ebene darunter nimmt die einzige Messung an einer ausgebauten Bauform und sieht sich an, was dort tatsächlich gewirkt hat.

Um die formalisierte Vorgabe ist ein Verfahren entstanden, mit Werkzeugen, Phasen und Rollen. Die Frage, wie viel es bringt, ist selten beantwortet. Gefunden wurde für diese Seite genau eine Messung.

Die eine Messung

Sie stammt vom April 2026 und untersucht eine Bauform mit vier Phasen und zwei Rollen:

We evaluate 128 runs covering 32 features across five repositories. (externe Seite, arxiv.org)

Das Ergebnis ist klein und sauber beziffert:

Context-grounding hooks improve judged quality by +0.15 on a 1-5 composite LLM-as-judge score (externe Seite, arxiv.org)

Ein Sechstel Punkt auf einer Skala von fünf, also drei Prozent der Skala. Dazu kommt, dass am Bestand nichts kaputtging:

while maintaining 99.7-100 percent repository-level test compatibility (externe Seite, arxiv.org)

Was dort gemessen wurde

Der Name der Messgröße sagt, worum es wirklich ging. Verglichen wurde dieselbe Bauform mit und ohne Hooks, die jede Phase an Belegen aus dem Projekt erden:

Read-only probing hooks ground each stage (Specify, Plan, Tasks, Implement) in repository evidence (externe Seite, arxiv.org)

Einen Lauf ganz ohne Vorgabe kennt der Versuch überhaupt nicht.

Das Problem, das damit angegangen wird, ist das aus Kapitel 06 bekannte:

leading to hallucinated APIs and architectural violations (externe Seite, arxiv.org)

Damit misst die Arbeit die Wirkung des Kontexts. Was die Vorgabe selbst beiträgt, bleibt offen: Die 0,15 Punkte gehören dem Erden an Projektbelegen, das innerhalb eines spec-getriebenen Verfahrens stattfand.

Der Maßstab hat eine zweite Eigenheit. Bewertet hat ein Modell, und die Arbeit sagt das im Namen der Kennzahl selbst. Eine Note aus dieser Quelle bleibt eine Einschätzung; dieselbe Grenze beschreibt Kapitel 07 für den Prüfer, der seine eigene Arbeit benotet.

seitlich verschiebbar

eigene Darstellung nach der Erhebung zu Spec Kit Agents, Stand 03.09.2026

Auf einem verbreiteten Prüfstand steht daneben eine zweite Zahl:

augmentation hooks improve baseline by 1.7 percent, achieving 58.2 percent Pass@1 (externe Seite, arxiv.org)

Sie misst etwas anderes als die Note, nämlich gelöste Aufgaben. Beide Zahlen zusammen sind der Bestand an Belegen für ein Verfahren, über das viel geschrieben wird.

Die Arbeit, die das zugibt

Ende August 2026 erschien eine Begriffsarbeit, die die spec-getriebene Entwicklung als Disziplin für Teams beschreibt. Ihr Ausgangspunkt ist ein Widerspruch aus der Praxis:

as individual productivity increases, team throughput, review capacity, and stability degrade because team-scale software engineering discipline is neglected (externe Seite, arxiv.org)

Das ist derselbe Befund, mit dem Kapitel 01 anfängt, hier auf die Teamebene gezogen. Der Vorschlag lautet, die Vorgabe zum Vertrag zwischen Mensch und Agent zu machen:

specifications act as the contract substrate between humans and agents (externe Seite, arxiv.org)

Die Arbeit ordnet ihre eigene Grundlage selbst ein. Sie stützt sich auf Vorträge, Berichte und Werkzeuge, und sie sagt warum:

because peer-reviewed evidence and a shared academic-industrial vocabulary are not yet established (externe Seite, arxiv.org)

Given the immaturity of the evidence base, this work is presented as a first step toward academic-industrial consensus rather than a validated theory (externe Seite, arxiv.org)

Ein Fachaufsatz, der seine eigene Beweislage für unfertig erklärt, ist ein brauchbarer Beleg für die Existenz eines Verfahrens. Für dessen Wirkung ist er keiner, und er behauptet das auch nicht.

Woher der Inhalt kommt

Beide Erhebungen dieses Kapitels halten den Inhalt der Vorgabe fest und verändern ihre Form oder ihre Menge. In der Praxis entsteht der Inhalt in einem Gespräch, und bei den ausgebauten Werkzeugen führt es ein Agent: Er fragt, hakt nach und schreibt daraus die Anforderungen. Ein Beratungshaus, das Domain-Driven Design lehrt und Altsysteme modernisiert, hat diesen Schritt im März 2026 untersucht und benennt seine Grenze:

the specification layer depends completely on the quality of domain knowledge the human brings to the interview (externe Seite, innoq.com)

But it cannot supply domain knowledge that isn’t in the room. (externe Seite, innoq.com)

Wer Domain-Driven Design kennt, erkennt die Stelle. Die Methode von Eric Evans verlangt seit 2004 die enge Zusammenarbeit von Entwicklern und Fachleuten an einem gemeinsamen Modell:

DDD requires sustained, genuine collaboration between developers and domain experts to build a shared ubiquitous language and a rich domain model. (externe Seite, innoq.com)

Woran Organisationen dabei scheitern, ist nach dieser Erfahrung der Zugang: Die Fachleute sitzen hinter einem Product Owner, und bei der Übersetzung geht etwas verloren.

Very often, they are buffered behind proxy product owners (externe Seite, innoq.com)

Der Unterschied zwischen beiden Verfahren liegt im Zeitpunkt. Domain-Driven Design hält die Fachleute während der ganzen Entwicklung verfügbar, weil das Modell beim Bauen an Stellen stößt, die vorher niemand gesehen hat:

DDD requires domain experts to be continuously available throughout development. (externe Seite, innoq.com)

Die spec-getriebene Entwicklung verlegt die Erkundung nach vorn, in das Interview vor dem ersten Plan. Was dabei verloren geht, benennt der Text:

A domain model that emerges through implementation and repeated collaboration will capture things no upfront interview process reliably surfaces. (externe Seite, innoq.com)

Ein Einsatzfeld bleibt, und nur dort hält der Text die Berichte über eine Planung in Stunden statt Wochen für wahrscheinlich: der technische Gründer, der Fachmann, Product Owner und Entwickler in einer Person ist.

There is no proxy problem. There are no organisational boundaries to cross. (externe Seite, innoq.com)

Das ist eine Einschätzung aus der Beratung, und der Verfasser verkauft die Methode, mit der er vergleicht. Gemessen ist daran nichts. Die Frage, die er daraus ableitet, kostet trotzdem nichts und steht vor der Wahl einer Form:

can your team get genuine access to domain experts when it needs them? (externe Seite, innoq.com)

Der Befund, der zu Kapitel 07 gehört

In der Erhebung zu den fünf Formen steht eine Zahl, die dort ein Nebenergebnis ist und hier die Klammer schließt:

Self-validation rates collapse from 100% (Sonnet) to 0% (Gemini Flash) across the capability spectrum. (externe Seite, arxiv.org)

Gemessen wurde, wie oft ein Modell sein eigenes Ergebnis überhaupt nachprüft. Beim stärksten Modell der Reihe geschieht das immer, beim schwächsten nie.

Damit hängen die beiden Befunde dieses Kapitels zusammen. Ein schwaches Modell gewinnt am meisten durch eine formalisierte Vorgabe und prüft am seltensten nach, ob es sie erfüllt hat. Genau dort entscheidet die Prüfung von außen darüber, ob die Vorgabe überhaupt etwas bewirkt.

Was sich daraus einrichten lässt

Die Form der Vorgabe wird zur Modellwahl dazugewählt. Beide Größen wirken gemeinsam, und die Erhebung misst genau diese Wechselwirkung. Ein starkes Modell mit formlosem Text und ein schwaches mit Verträgen liegen näher beieinander als die Modellnamen vermuten lassen.

Bedingungen werden gezählt, bevor sie geschrieben werden. Der Verfall setzt an der Zahl gleichzeitig geltender Anforderungen an. Wer eine Aufgabe zuschneidet, zählt sie und teilt bei Bedarf; das ist derselbe Schnitt wie beim Umbau in Kapitel 11.

Das Erden am Projekt kommt vor der Formalisierung. Die einzige gemessene Verbesserung stammt aus Hooks, die jede Phase an Belegen aus dem Projekt festmachen. Was ein Projekt über sich selbst bereitstellt, steht in Kapitel 03.

Vor der Form steht der Zugang. Eine Vorgabe enthält, was die befragte Person weiß. Wo die Fachleute hinter einem Product Owner sitzen, füllt kein Interview-Agent die Lücke, und die Frage danach kostet weniger als jede Formalisierung.

Offen bleibt, was die Erhebungen offen lassen. Beide Arbeiten benennen dieselbe Lücke, und die zweite formuliert daraus einen Auftrag:

outlines a research agenda for future empirical validation (externe Seite, arxiv.org)