Zum Inhalt springen

Wissensbasis

Creator- und Verifier-Rollen

Patterns, die Bauen und Prüfen trennen: warum Self-Grading scheitert und wie ihr einen Verifier in den Loop einbaut, für Teams mit mehr als einem Agenten.

Verfasst von

Aktualisiert:

Software Factories 5

Unsere Position. Wir trennen Bauen und Prüfen: Die prüfende Station darf nicht an die bauende Station berichten. Review läuft auf spezialisierten Agenten mit anderen Modellen, sodass das Modell eines zweiten Vendors den Code des ersten reviewt (Bauen und Prüfen trennen (öffnet in einem neuen Tab)). Ein Reviewer als eigener Subagent reviewt mit frischem Blick, statt den Bias der geprüften Arbeit zu übernehmen (Skills oder Subagents (öffnet in einem neuen Tab)).

Ein separater Agent allein reicht nicht. In einem gemessenen Loop akzeptierte ein Judge, der nur Artefakt und Diff las, trotzdem Regressionen. Die Unabhängigkeit muss deshalb bis zum Signal aus der realen Welt reichen.

Welche Patterns trennen Bauen und Prüfen?

Self-Grading

Anti-Pattern.

Kontext. Ein Agent schließt eine Änderung ab und soll sie selbst beurteilen. Oder ein Loop-Gate vertraut dem Fortschrittsbericht des Agenten.

Problem. Der Agent lobt mittelmäßige Arbeit und redet sich die echten Probleme klein, die er selbst gemeldet hat. In einem gemessenen Loop behauptete er in jedem Zyklus eine Verbesserung, die meisten Zyklen ergaben gemessen null oder schlechter.

Ausweg. Übergebt das Urteil einem separaten Verifier, der gegen einen Validation Contract bewertet und das Signal aus der realen Welt erreicht.

Achtung. Ein Loop-Gate, das die Fortschrittsbehauptungen des Agenten liest. Im gemessenen Loop akzeptierte ein Gate, das ihnen vertraute, spätere Regressionen, bis der beste erreichte Zustand um 19 Prozent erodiert war.

Verwandt. Separate Verifier, Validation Contract.

Separate Verifier

Pattern.

Kontext. Ein Generator-Agent erzeugt in einem Loop Code oder ein Produkt. Etwas muss entscheiden, ob jede Runde gut genug ist.

Problem. Ein Review im selben Kontext wie der Generator übernimmt dessen Begründungen. Ein Judge, der nur Artefakt und Diff liest, akzeptiert trotzdem Regressionen.

Deshalb. Lasst den Verifier in frischem Kontext laufen und baut ihn als Evaluator in den Loop ein. Er bedient die Ausgabe wie ein User, mischt deterministische Checks mit Modellurteil und läuft wo möglich bei einem anderen Modellanbieter. Ein deterministisches Gate kann den Reviewer starten, sobald seine eigenen Checks bestehen.

Achtung. Validierung kostet Wall-Clock-Zeit, weil der Verifier auf echte Ausführung wartet. Ein Reviewer bläht seine Befunde gern auf, um gründlich zu wirken. Akzeptiert deshalb einen kurzen Durchlauf und deckelt Nits. Ein Managed Grader hält seine Begründung womöglich vor dem Aufrufer verborgen.

Verwandt. Self-Grading, Validation Contract, Software Factories in Produktion: Belege.

Validation Contract

Pattern.

Kontext. Ein Feature oder eine Mission ist in Planung, und noch existiert kein Code.

Problem. Tests nach der Implementierung bestätigen Entscheidungen, statt Bugs zu finden. Außerdem kann ein Generator mittendrin die Torpfosten verschieben.

Deshalb. Schreibt die Definition of Done schon in der Planung, unabhängig von der Implementierung. Das sind Assertions, die Features zugeordnet sind, oder eine Rubrik bewertbarer Kriterien aus einem bekannt guten Artefakt.

Achtung. Jedes Kriterium muss bewertbar sein. Fragt, ob die Ausgabe den festgelegten Designprinzipien folgt, nicht, ob sie schön ist.

Verwandt. Separate Verifier, Self-Grading.

Warum kann ein Agent seine eigene Arbeit nicht bewerten?

Das verlässlichste Ergebnis über alle Quellen hinweg lautet: Ein Agent kann seine eigene Arbeit nicht bewerten. Bittet ihr ihn darum, lautet der Befund: “it’s likely going to praise it”. Das gilt auch dann, wenn die Qualität “obviously mediocre to a human observer” ist. Ohne Anpassung ist ein Modell “a poor QA agent”: Es meldet wiederholt echte Probleme und gibt die Arbeit trotzdem frei, “talking itself into deciding they weren’t a big deal” (The AI Automators - harness design for long-running agents (öffnet in einem neuen Tab), 25. März 2026). Die Lösung ist ein separater Verifier in frischem Kontext. Dann gilt für ihn: “is not biased by the implementation agent’s reasoning” (Agent-Loops in Produktion (öffnet in einem neuen Tab)). Harnesses mit nur einem Agenten erreichen dasselbe: Sie verzweigen in einen sauberen Review-Kontext und holen die Fixes danach zurück (Review-Workflow in Pi (öffnet in einem neuen Tab), 31. Januar 2026).

Ein kontrollierter Pilot misst das Versagen in einem laufenden Loop und zeigt, dass ein separater Judge allein nicht reicht. Zwei unabhängige Forscher:innen hielten Agent und Tools fest und variierten nur, was der Gate-Evaluator sehen konnte. Ein simulierter User außerhalb der Reichweite des Agenten maß die echten Ergebnisse. Der Agent behauptete in allen 54 Zyklen eine Verbesserung, doch 56 Prozent davon ergaben gemessen null oder schlechter. Ein Gate, das diesen Behauptungen vertraute, akzeptierte spätere Regressionen, bis der beste erreichte Zustand um 19 Prozent erodiert war. Ein starker In-Band-Judge las Artefakt, Diff und seine eigene Urteilshistorie. Trotzdem akzeptierte er Zyklen, von denen 44 Prozent Regressionen waren, und lehnte 38 Prozent echter Verbesserungen ab. Die Lücke schloss sich nur bei einer Aufgabe, deren Erfolg sich am Artefakt selbst ablesen ließ. Die Autor:innen folgern daraus, dass der Judge das reale Signal erreichen muss, das er bewertet. Das Paper ist ein vorläufiger Entwurf im Pilotmaßstab mit einem Agenten (When Do Agent Loops Mistake Stagnation for Progress? (öffnet in einem neuen Tab), Juli 2026, überarbeitet September 2026).

Ein Benchmark isoliert einen Mechanismus hinter Self-Grading. Self-Correction Bench fügt denselben Fehler in ein Gespräch ein, einmal als Fehler des Users, einmal als eigenen Fehler des Modells. Alles andere bleibt identisch. Über 14 Open-Source-Modelle ohne Reasoning misst der Benchmark einen blinden Fleck von 64,5 %. Die Modelle korrigieren den Fehler, wenn jemand anderes ihn gemacht hat, und übersehen denselben Fehler in ihrer eigenen Ausgabe. Die Fähigkeit existiert also, wird aber nicht aktiviert. Die Autor:innen führen die Lücke auf Fine-Tuning-Daten zurück, denen Sequenzen zur Fehlerkorrektur fehlen. Das angehängte Wort “Wait” verkleinerte den blinden Fleck ohne jedes Training um 89,3 % (Self-Correction Bench: Uncovering and Addressing the Self-Correction Blind Spot in Large Language Models (öffnet in einem neuen Tab), Juli 2025, überarbeitet August 2026). Der Befund spricht dafür, einem Reviewer die Arbeit als Ausgabe einer anderen Partei vorzulegen. Ein Webbuch über Delegation zieht vorerst diesen Schluss. Es setzt unabhängiges Review dort ein, wo die zusätzlich gefundenen Fehler die Kosten rechtfertigen (The Elastic Loop: Harness (öffnet in einem neuen Tab)).

Ein Bericht formuliert das Prinzip direkt: “agents produce better code when they can gauge the quality of the code they produce themselves rather than relying on us to check it” (Menschen und Agenten im Loop (öffnet in einem neuen Tab), 4. März 2026).

Wie baut ihr einen Verifier in den Loop ein?

Den Evaluator fest in den Loop einzubauen ist der Schritt in die Produktion. The AI Automators modellieren das nach einem GAN: ein Generator-Agent, gepaart mit einem Evaluator-Agent. Der Unterschied zum spontanen “LLM as a judge” ist “an evaluator wired into a production loop.” Drei Anforderungen lassen das funktionieren. Macht subjektive Qualität bewertbar, fragt also “does this follow our principles for good design?” statt “is this beautiful?”. Gewichtet die Kriterien hin zu den nachgewiesenen Stärken des Modells. Lasst den Evaluator mit der Ausgabe interagieren, etwa indem er die App über ein Browser-MCP bedient und wie ein echter User Screenshots macht.

Legt Done vor dem Bauen fest: Factory schreibt in der Planung einen Validation Contract, “before any code”. Für ihn gilt: “defines correctness independently of implementation”. Das sind manchmal Hunderte Assertions, jede einem Feature zugeordnet, denn “tests written after implementation don’t catch bugs, they confirm decisions” (Factory - Missions (öffnet in einem neuen Tab), 6. Mai 2026).

Das Harness-Team von Anthropic handelt unabhängig davon die “definition of done up front” aus. Dann gilt für den Generator: “couldn’t move the goal posts halfway through.” Factory lässt danach zwei Typen von Validatoren laufen. Ein Scrutiny-Validator prüft Tests, Typen, Lint und macht Code-Review pro Feature. Ein User-Testing-Validator startet die App und bedient sie per Computer Use. Für ihn gilt: “most of the wall-clock time is spent waiting for real-world execution instead of generating tokens.”

Zwei weitere Mechaniken schärfen die Verifikation. Setzt das richtige Modell in jede Rolle: Factorys “droid whispering” geht von diesem Satz aus: “no single model nor model provider is best at all three”. Die drei sind Planung, Implementierung und Validierung. Deshalb läuft die Validierung bewusst “on a different model provider entirely”. Dann gilt für sie: “is not biased by the same training data”. So wird modellagnostisches Design zum strukturellen Vorteil. Bewertet außerdem mit einer Mischung aus Check-Typen. OpenAIs Retraining-Beispiel lässt deterministische Grader (Namensabgleich, Länge, Kosinus-Ähnlichkeit) neben einem LLM-as-Judge laufen, “mixing deterministic checks with semantic judgment”. Es versioniert den Prompt des Agenten, sodass eine Regression auf eine bekannt gute Version zurückrollt (OpenAI Cookbook - self-evolving agents (öffnet in einem neuen Tab)).

Anthropics Managed Agents machen den separaten Grader zum Plattform-Feature. Der Aufrufer definiert ein Outcome mit einer Markdown-Rubrik aus expliziten, bewertbaren Kriterien. Ein Grader in eigenem Kontextfenster bewertet die Arbeit des Agenten gegen jedes Kriterium und begründet jedes Urteil. Der Agent überarbeitet dann, bis der Grader das Outcome als erfüllt meldet oder der Lauf max_iterations erreicht. Der Standardwert ist 3, erlaubt sind höchstens 20. Jede Runde meldet ein Ergebnis: satisfied, needs_revision, max_iterations_reached, failed, wenn die Rubrik nicht zur Aufgabe passt, und interrupted. Die Dokumentation empfiehlt, eine Rubrik aus einem bekannt guten Artefakt abzuleiten. Die Begründung des Graders bleibt für den Aufrufer verborgen, und das Feature ist eine Beta-API (Anthropic - Define outcomes (öffnet in einem neuen Tab)).

Ein deterministisches Gate kann den Verifier selbst auslösen. Habit Hooks, ein Tool fürs Linter-Coaching, beendet jeden sauberen Lauf mit einer Instruktion an den implementierenden Agenten: Er soll einen Reviewer-Subagent starten. Das Briefing dafür liefert das Tool mit. Der Implementierer soll die Änderung vorher nicht selbst reviewen, denn den frischen Blick bringt erst der Reviewer. Das Briefing schließt alles aus, was das Gate schon prüft. Es listet, was das Gate nicht sieht: Korrektheit, Design, Testlücken und Edge Cases. Außerdem bremst es den Drang eines Reviewers, gründlich zu wirken. Ein zweizeiliger Durchlauf ist ein gültiges Ergebnis, jeder Befund nennt Datei und Zeile, und Nits sind auf zwei gedeckelt. Fordert der Reviewer Änderungen, bringt der implementierende Agent die Befunde zum User. Mit ihm stimmt er ab, welche er umsetzt, bevor er etwas fixt (habit-hooks - habit-hooks-review skill (öffnet in einem neuen Tab), Stand Oktober 2026).

Verwandte Seiten

Quellen

Tools zur Verifikation

Forschung