LLM-Subagenten-Output gegen Ground-Truth prüfen

Ein Subagent schreibt: „Erledigt. Alle Tests grün. Commit gesetzt." Das ist kein Beweis — das ist eine Behauptung, formuliert von einem Sprachmodell, das sehr gut darin ist, plausibel klingende Abschlussmeldungen zu produzieren. Ich habe aufgehört, diese Berichte auf Treu und Glauben zu nehmen. Nicht weil ich den Agenten für unzuverlässig halte — sondern weil ich verstanden habe, was ein LLM-Bericht strukturell leisten kann und was nicht.

Warum Reports trügen

Ein Sprachmodell hat keinen privilegierten Zugang zur Wahrheit seines eigenen Outputs. Es hat gelernt, wie „ein erfolgreicher Abschlussbericht" klingt — und produziert genau das, wenn die vorherigen Token in diese Richtung zeigen. Ein selbstbewusst formuliertes „Done, all tests passing" ist statistisch genauso wahrscheinlich wie ein korrektes. Beide sehen auf Token-Ebene identisch aus.

Das ist kein Argument gegen den Einsatz von Subagenten. Es ist ein Argument für eine klare Rollentrennung: Der Agent erledigt Arbeit. Die Verifikation liegt beim Orchestrator — oder bei mir. Beides kann nicht dieselbe Instanz sein, die den Bericht verfasst hat, denn der Bias sitzt in der Completion, nicht im Werkzeug.

Drei Fälle haben mich das konkret verstehen lassen.

Beleg 1 — gefundene Bugs, die keine waren

In einem Verdict-Loop hatte ein Agent die Aufgabe, Bugs in einer Codebasis zu finden und zu bewerten. Er fand welche. Der Report war formatiert wie ein echter Code-Review: Dateinamen, Zeilennummern, Fehlerbeschreibungen. Alles stimmig.

Das Problem: die Fundstellen lagen in Demo-Code, den er nicht von Production-Logik unterschieden hatte. Die „Bugs" waren illustrative Platzhalter, absichtlich kaputt, damit die Demo etwas zu zeigen hat. Der Agent behandelte sie als echte Befunde.

Hätte ich den Report blind weitergegeben, hätte jemand Demo-Artefakte als echte Schwachstellen priorisiert. Die Form des Reports — überzeugend, strukturiert, vollständig — hatte keinen Zusammenhang mit seinem Inhalt. Der Fehler war nicht im Agent, sondern in meiner Erwartung, dass „gut formatiert" mit „inhaltlich valide" korreliert. Das tut es nicht.

Beleg 2 — der Verifier, der gar nicht testete

Ein Verifier-Agent sollte nach einem Refactor sicherstellen, dass die Tests noch grün sind. Er lieferte ein Urteil: Tests fehlgeschlagen, drei Failures. Ich war überrascht — der Code sah korrekt aus.

Dann sah ich das Detail: Gesamtlaufzeit ~0,4 Sekunden. Drei Tests. Eine der Fehlermeldungen lautete document is not defined. Der Agent hatte bun test gerufen statt pnpm/vitest — in seiner Sandbox war pnpm nicht verfügbar, also fiel er auf die nächstverfügbare Runtime zurück. bun test ignoriert die jsdom-Konfiguration; die Tests, die DOM-Zugriffe brauchen, fallen sofort mit document is not defined durch.

Das Urteil war technisch korrekt — in der Sandbox, mit der falschen Runtime. Was der Agent wirklich geleistet hatte: er hatte den Diff gelesen und bewertet. Das ist wertvoll. Aber das Testurteil war wertlos, weil die Ausführungsumgebung nicht zu den Anforderungen des Test-Setups passte.

Hätte ich das Urteil geglaubt, hätte ich funktionierenden Code als kaputt eingestuft und nach Fehlern gesucht, die nicht existieren. Der Report war in sich konsistent. Er war trotzdem falsch.

Beleg 3 — doppelt gebaut

Carry-over-Buchhaltung über Sessions ist ein unterschätztes Problem. Ein offenes Item wanderte aus einer Session in die nächste — korrekt dokumentiert, klar beschrieben. Zwei parallele Sessions zogen dasselbe Item und bauten denselben Fix unabhängig voneinander.

Beide Fixes waren korrekt. Beide wurden committed. Der zweite Commit musste aufgelöst werden, weil er auf einem Stand aufbaute, der die Änderung schon enthielt.

Das war kein Fehler des einzelnen Agenten — er hatte das Item gesehen, es noch nicht als erledigt markiert vorgefunden, und angefangen zu bauen. Der Fehler lag in der fehlenden Snapshot-Verifikation vor Arbeitsbeginn: ein git status --short plus ein Blick auf den letzten Commit hätte gezeigt, dass die Änderung bereits existierte. Statt auf den Buchhaltungsstand zu vertrauen, wäre ein 30-Sekunden-Ground-Truth-Check ausreichend gewesen.

Die Praxis: Ground-Truth vor Buchhaltung

Das Muster hinter allen drei Fällen ist dasselbe: ich habe dem Selbstbericht geglaubt, anstatt die Realität zu prüfen. Die Gegenmaßnahme ist simpel und mechanisch:

git show <hash> auf den behaupteten Commit — nicht den Report lesen, den Diff sehen.
Die Test-Suite selbst laufen lassen, nicht das Ergebnis übernehmen: pnpm test, in der korrekten Umgebung, mit der korrekten Runtime.
Vor jedem Deploy dist/ greppen — auf Markdown-Artefakte, Pfade, Secrets, Privatdaten.
Vor Arbeitsbeginn an einem Carry-over-Item git status --short und letzten Commit prüfen.

Dreißig Sekunden Realitäts-Check statt Narrativ-Glauben. Das ist die ganze Methode. Sie klingt trivial — und ich habe sie trotzdem dreimal nicht angewendet, bevor ich die Fälle hatte, die mich dazu gebracht haben.

Das ändert sich nicht mit besseren Agenten. Ein Agent, der präziser antwortet, produziert präziser klingende Reports — und macht sie damit überzeugender, nicht wahrer. Der strukturelle Bias bleibt: er berichtet über seine Arbeit mit denselben Mitteln, mit denen er sie erledigt hat — Sprache, keine Ausführung. Den Unterschied zwischen beidem kann kein Sprachmodell aus sich selbst heraus auflösen.

Was offen ist

Verifikation kostet Zeit und Tokens. Jeder Check, den ich selbst mache, frisst genau den Produktivitätsgewinn, den der Agent eigentlich erbringen soll. Die Grenze zwischen „gesund skeptisch" und „alles zweimal machen" ist unscharf — und sie verschiebt sich je nach Aufgabe, Risiko, und wie kritisch die Folgen eines Fehlers sind.

Ich habe noch keine gute Antwort darauf, wie selektiv ich diese Checks anwenden soll. Aktuell gilt: je näher eine Agentenausgabe an einem externen Artefakt ist — einem Commit, einem Deploy, einer Kommunikation —, desto eher prüfe ich nach. Bei reinen Analyse-Outputs, die ich sowieso lese, spare ich mir den Overhead. Ob das die richtige Heuristik ist, weiß ich noch nicht.

Nachgeprüfte Selbstberichte sehen oft anders aus als gemeldet. Wenn du ähnliche Verification-Patterns nutzt oder andere Ansätze kennst, schreib mir.