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 (externe Seite, arxiv.org) vom August 2026 nimmt dieselbe Aufgabe und beschreibt sie in fünf Formen, die alle dieselbe Auskunft enthalten.

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. Über 90 Agentenläufe mit mehreren Runden zeigt sich laut Versuch (externe Seite, arxiv.org) eine starke Wechselwirkung zwischen Form und Modell.

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

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

Bei den stärksten Modellen (Sonnet 4.6, GPT-5) spielt die Form laut Versuch (externe Seite, arxiv.org) kaum eine Rolle, die Qualität streut dort zwischen 0,17 und 0,92 Punkten.

Beim schwächsten Modell der Reihe verdreifachen TypeScript-Verträge (externe Seite, arxiv.org) die Abdeckung der Schnitt­stel­len­pfade, von 33 auf 100 Prozent, also von einem Drittel auf alle.

Die Arbeit zieht daraus einen Schluss über die Kosten: Strukturierte Archi­tek­tur­vor­gaben gleichen laut Versuch (externe Seite, arxiv.org) Unterschiede in der Leis­tungs­fä­hig­keit der Modelle aus. Ihr Nutzen steht im umgekehrten Verhältnis zur Stärke des Modells, und am meisten bringen sie dort, wo aus Kostengründen kleinere Modelle eingesetzt werden.

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 Schnitt­stel­len­ver­trag fest und häuft strukturelle Anforderungen an: Architekturmuster, Datenbank, Zuordnung von Objekten zu Tabellen. Hundert Aufgaben über acht Rahmenwerke. Je mehr strukturelle Anforderungen sich ansammeln, desto deutlicher fällt laut Erhebung (externe Seite, arxiv.org) die Leistung des Agenten.

Die Zahl dazu ist deutlich: Die bewerteten Konfigurationen verlieren laut derselben Erhebung (externe Seite, arxiv.org) von der Grundaufgabe bis zur vollständig spezifizierten Aufgabe im Mittel 27,28 Punkte beim Anteil bestandener Testprüfungen.

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: Funktionale und strukturelle Anforderungen zugleich zu erfüllen, bleibt laut Erhebung (externe Seite, arxiv.org) eine zentrale offene Aufgabe für Agenten, die programmieren.

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

Von oben nach unten wächst, was eine Maschine daraus entscheiden kann. Genau entlang dieser Reihe fallen die Ergebnisse aus: Bei schwächeren Modellen streut die Qualität laut Versuch (externe Seite, arxiv.org) je nach Form um 0,83 bis 2,42 Punkte, und die code-nahen Formen (OpenAPI, TypeScript-Verträge) holen den größten Teil des Abstands zu den stärkeren Modellen auf.

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: Modelle der Mittelklasse können laut Versuch (externe Seite, arxiv.org) mehr Token verbrauchen als die Spitzenmodelle und dabei Schlechteres liefern, wenn sie in Schleifen aus Übersetzen und Fehlersuche geraten, die stärkere Modelle vermeiden.

Ein kleineres Modell ist billiger je Token und kann teurer je Aufgabe werden, weil es in Über­set­zungs­feh­lern 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ß: Laut Erhebung (externe Seite, arxiv.org) gelingen ihnen schlanke, ausdrückliche Rahmenwerke wie Flask, während sie in kon­ven­ti­ons­las­tigen Umgebungen wie FastAPI oder Django im Mittel deutlich schlechter abschneiden.

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 kon­ven­ti­ons­las­tigen (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 kon­ven­ti­ons­las­tiges 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 (externe Seite, arxiv.org): Ihre Fehleranalyse findet die häufigsten Ursachen in der Datenschicht, etwa falsch zusammengesetzte Abfragen und Verstöße gegen die Regeln der Zuordnung von Objekten zu Tabellen (ORM) zur Laufzeit.

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: Bestehende Prüfstände übersehen laut Erhebung (externe Seite, arxiv.org) häufig die nichtfunktionalen Anforderungen und belohnen Lösungen, die funktional richtig und im Aufbau beliebig sind.

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: Im Plan-Modus soll Claude laut Rechtemodi-Doku (externe Seite, code.claude.com) recherchieren und Änderungen vorschlagen, ohne sie vorzunehmen. Claude liest dabei Dateien, führt zur Erkundung Shell-Befehle aus und schreibt einen Plan; den Quelltext des Projekts bearbeitet es in diesem Modus nicht.

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:

{
  "permissions": {
    "defaultMode": "plan"
  }
}

Was beim Zustimmen passiert, gehört mitgelesen: Wer einem Plan zustimmt, beendet laut Rechtemodi-Doku (externe Seite, code.claude.com) den Plan-Modus und schaltet die Sitzung in den Rechtemodus, den die gewählte Zustimmungsoption beschreibt; danach beginnt Claude mit dem Bearbeiten.

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. In interaktiven Terminalsitzungen, in denen das Umgehen der Rückfragen verfügbar ist, setzt Claude Code die Sperren des Plan-Modus laut Rechtemodi-Doku (externe Seite, code.claude.com) nicht durch. Claude wird weiterhin angewiesen, ohne Bearbeitung zu planen, doch eine Dateiänderung oder ein Shell-Befehl, den es beim Planen versucht, läuft ohne Rückfrage durch.

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. Ausgewertet werden laut Messung (externe Seite, arxiv.org) 128 Läufe über 32 Funktionen in fünf Repositories.

Das Ergebnis ist klein und sauber beziffert: Hooks, die die Arbeit am Kontext des Projekts erden, heben die bewertete Qualität laut Messung (externe Seite, arxiv.org) um 0,15 Punkte, gemessen auf einer zusammengesetzten Skala von 1 bis 5, deren Note ein Sprachmodell als Bewerter vergibt.

Ein Sechstel Punkt auf einer Skala von fünf, also drei Prozent der Skala. Dazu kommt, dass am Bestand nichts kaputtging: Die Verträglichkeit mit den Tests der jeweiligen Repositories lag laut Messung (externe Seite, arxiv.org) dabei bei 99,7 bis 100 Prozent.

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. Diese Hooks greifen nur lesend auf das Repository zu und stützen laut Messung (externe Seite, arxiv.org) jede der vier Phasen (Specify, Plan, Tasks, Implement) auf Belege daraus.

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

Das Problem, das damit angegangen wird, ist das aus Kapitel 06 bekannte: Die Messung (externe Seite, arxiv.org) nennt als Folge erfundene APIs und Verstöße gegen die Architektur.

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: Die ergänzenden Hooks verbessern den Ausgangswert dort laut Messung (externe Seite, arxiv.org) um 1,7 Prozent und erreichen 58,2 Prozent Pass@1, also Aufgaben, die im ersten Versuch gelöst werden.

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: Während die Produktivität des Einzelnen steigt, lassen laut Begriffsarbeit (externe Seite, arxiv.org) Durchsatz, Kapazität für Reviews und Stabilität des Teams nach, weil die Disziplin der Softwaretechnik im Teammaßstab vernachlässigt wird.

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: Spezifikationen sollen laut Begriffsarbeit (externe Seite, arxiv.org) die vertragliche Grundlage bilden, auf der Menschen und Agenten zusammenarbeiten.

Die Arbeit ordnet ihre eigene Grundlage selbst ein. Sie stützt sich auf Vorträge, Berichte und Werkzeuge, und sie sagt warum: Begutachtete Belege und ein gemeinsames Vokabular von Forschung und Industrie gibt es laut Begriffsarbeit (externe Seite, arxiv.org) bisher nicht. Wegen dieser unreifen Beweislage versteht sie sich als ersten Schritt zu einem Konsens zwischen Forschung und Industrie; als bestätigte Theorie will sie ausdrücklich nicht gelten.

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: Die Spezifikation hängt laut Beitrag (externe Seite, innoq.com) vollständig davon ab, wie gut das Fachwissen ist, das der Mensch ins Interview mitbringt. Der Agent fragt hartnäckig nach, doch Fachwissen, das niemand im Raum hat, kann er nicht beisteuern.

Wer Domain-Driven Design kennt, erkennt die Stelle. Die Methode von Eric Evans gibt es seit 2004, und sie verlangt laut Beitrag (externe Seite, innoq.com) eine dauerhafte, echte Zusammenarbeit von Entwicklern und Fachleuten, aus der eine gemeinsame Fachsprache (Ubiquitous Language) und ein reichhaltiges Fachmodell entstehen.

Woran Organisationen dabei scheitern, ist nach dieser Erfahrung (externe Seite, innoq.com) der Zugang: Sehr oft sitzen die Fachleute abgeschirmt hinter einem Product Owner, der sie vertritt, und bei der Übersetzung geht etwas verloren.

Der Unterschied zwischen beiden Verfahren liegt im Zeitpunkt. Domain-Driven Design verlangt laut Beitrag (externe Seite, innoq.com), dass die Fachleute während der ganzen Entwicklung verfügbar sind, weil das Modell beim Bauen an Stellen stößt, die vorher niemand gesehen hat.

Die spec-getriebene Entwicklung verlegt die Erkundung nach vorn, in das Interview vor dem ersten Plan. Was dabei verloren geht, benennt der Text (externe Seite, innoq.com): Ein Fachmodell, das beim Umsetzen und in wiederholter Zusammenarbeit entsteht, erfasst Dinge, die kein Interview vorab zuverlässig zutage fördert.

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. Für ihn gibt es laut Beitrag (externe Seite, innoq.com) weder das Problem eines Stellvertreters noch Grenzen zwischen Abteilungen, die zu überwinden wären.

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: Der Beitrag (externe Seite, innoq.com) fragt, ob das Team echten Zugang zu den Fachleuten bekommt, wenn es sie braucht.

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: Der Anteil der Selbstprüfung bricht laut Versuch (externe Seite, arxiv.org) über die Bandbreite der Modelle von 100 Prozent (Sonnet) auf 0 Prozent (Gemini Flash) ein.

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: Sie skizziert laut Begriffsarbeit (externe Seite, arxiv.org) eine Forschungsagenda für die künftige empirische Prüfung.