Das Zitierfähigste in meinem Review war erfunden

Ich habe einen Agenten den Post über das Bewerten von Agent-Loops reviewen lassen. Zurück kamen drei Befunde, gut geschrieben, mit Zitaten aus meinem eigenen Text und Zahlen aus meinem eigenen Repository.

Zwei waren exakt richtig. Sie umzusetzen hat den schwächsten Abschnitt jenes Posts zum stärksten gemacht.

Der dritte war die beste Geschichte davon. Ich habe sie geprüft, und fast nichts davon stand in den Dateien.

Was gestimmt hat

Der Post behauptete, ich hätte keine Score-Historie, auf die sich ein Diagramm lohnt. Der Review sagte, es gebe sie seit dem 11. Juli, und hat die Zahlen mitgeliefert.

Ich habe var/score-history.jsonl geöffnet und erwartet, sie ungefähr wiederzufinden. Sie waren exakt — jeder Wert auf vier Nachkommastellen, in der richtigen Reihenfolge, inklusive einer Regression bei 0,9102, an die ich mich nicht mehr erinnert hatte. Eine Session, 79 Minuten, elf Zyklen von 0,8279 auf 1,0, danach 0,9985 auf dem vollen Dev-Set gegen 0,9940 auf dem Probe-Set.

Der zweite Befund war, dass zwei Zahlen im Post nicht zu meinem tatsächlichen Target passen. Ebenfalls richtig. Meine goal.md definiert die Abnahme als Holdout mindestens 0,95 und keine Kategorie unter 0,90, bei einem Probe-Gap von höchstens 0,02. Im Post stand „Gap zweimal hintereinander über 0,15" — beim Schreiben erfunden und danach vergessen, dass es erfunden war.

Das hat auf brauchbare Art wehgetan. Der Review hat eine Erfindung von mir gefunden, bevor ich es getan habe.

Was erfunden war

Der dritte Befund beschrieb eine Fehlerart, die ich übersehen hatte. Der Lauf habe perfekt abgeschnitten, und gebaut worden sei — in den Worten des Reviews — eine In-Memory-Engine ohne Datenbank, ohne Row-Level Security, ohne HTTP-Ingestion, ohne Rollen.

Dann die Pointe: Die Engine hätte jede echte Registrierung falsch attribuiert, weil alle 600 Eval-Szenarien vorgefertigte Click-Events mit einem meta-Feld fütterten, das echte Klicks nicht tragen, und der Rebuild sie still verworfen habe.

Das ist ein wirklich guter Absatz. Und das steht in den Dateien:

• Die Datenbank war echt. LOG.md verzeichnet ein per-Run-Schema, FORCE RLS nach Kit-Muster, eine RLS-Suite mit 14 grünen Fällen und eine Scorer-Rolle ohne Superuser- und ohne Bypass-Rechte. In goal.md steht ein Constraint, der genau das verlangt: Szenarien laufen über den Produktionspfad, und der Scorer prüft die Datenbank direkt statt über einen Sonderweg fürs Scoring.
• „Holdout 0,9995" existiert nicht. In der Verlaufsdatei steht überhaupt kein Holdout-Wert. Holdout läuft aggregat-only auf einem Budget von sechs Aufrufen pro 48 Stunden — deshalb ist er nicht da.
• Ein meta-Feld gibt es nicht. Null von 400 Dev-Szenarien enthalten eines. Der Mechanismus, von dem die Geschichte lebt, steckt nicht in den Daten.

Ein Teil davon stimmte, und welcher, konnte ich nur herausfinden, indem ich die Eval aufgemacht habe. Es sind 600 Szenarien — 400 Dev, 200 Holdout —, und jedes ist eine vorgefertigte Zustandsdatei ohne HTTP-Request. Die Ingestion-Routen standen also tatsächlich nie auf dem Prüfstand. Der Zuschnittsfehler war real. Die Geschichte, die ihn erklärte, nicht.

Die Befunde sortierten sich nach einer Sache

Im Rückblick teilen sich die drei sauber auf, und nicht entlang der Linie, die ich vermutet hätte.

Jede Behauptung, die auf einen Pfad und einen Wert zeigte, war richtig. Die Score-Historie, die Kriterien aus goal.md, die Eval-Größen — alles in unter einer Minute nachprüfbar, alles korrekt.

Jeder Fehler steckte in einem Satz, der den Zustand des Systems in Prosa beschrieb. „Keine Datenbank." „Kein RLS." Ein Feld, das sich soundso verhält. Solche Sätze lesen sich wie Beobachtungen und sind in Wahrheit Zusammenfassungen — und in einer Zusammenfassung lässt sich ein plausibles Detail ergänzen, ohne dass irgendetwas widerspricht.

Einen zweiten Datenpunkt habe ich in derselben Woche bekommen, ohne danach zu suchen. Ein Review-Bot am Pull Request dieser Seite meldete, ein geplanter Post breche über generateStaticParams den Production-Build. Ein echter Defekt war dort — Metadaten entstehen vor dem Publish-Gate der Komponente und lesen damit einen Übersetzungs-Namespace, der in Production entfernt wird. Nur war der beschriebene Mechanismus Tage vorher geschlossen worden. Richtig, dass etwas kaputt war. Falsch worin — und falsch in Richtung eines dramatischeren Fehlers als des echten.

Der Teil, der mir nicht gefällt

Die erfundene Behauptung war die, die ich wahr haben wollte.

„Ein perfekter Score auf einer Engine, die null Prozent der Realität korrekt verarbeitet hätte" ist ein besserer Satz als alles, was ich in der Woche geschrieben hatte. Er hätte den Post gemacht. Ich musste ihn gezielt prüfen, gerade weil er gut war — und dabei ist mir aufgefallen, dass ich hoffte, die Prüfung ginge glatt aus.

Das ist die unangenehme Fassung der Regel, die ich längst hatte: Ein erfolgreicher Lauf ist kein Beleg dafür, dass sein Ergebnis stimmt. Die Regel hält man leicht ein, solange das Ergebnis langweilig ist. Schwer abzulehnen ist das Ergebnis, das dem schmeichelt, woran man gerade schreibt.

Das ist ungefähr dieselbe Form wie das Argument aus dem letzten Post: Meine eigene Vorliebe hat entschieden, was genau geprüft wurde, und ich war das Einzige in der Schleife, das das hätte auffangen können.

Was ich jetzt anders mache

Nicht „Review-Agenten weniger vertrauen". Zwei von drei Befunden stimmten, einer davon hat eine Erfindung gefunden, die ich veröffentlicht hatte, und der Post ist spürbar besser als vorher. Bei jeder Trefferquote ist das ein guter Tausch.

Geändert hat sich die Reihenfolge, in der ich arbeite:

• Zuerst nach Belegbarkeit sortieren. Alles, was eine Datei und einen Wert nennt, wird sofort geprüft. Das dauert eine Minute, stimmt meistens, und es ist der schnellste Weg herauszufinden, ob der Rest meine Zeit wert ist.
• Prosa-Beschreibungen sind Hinweise, keine Befunde. „Es gibt kein X" ist eine Hypothese zum Nachprüfen, nie etwas, worauf man handelt. Jeder Fehler in beiden Reviews war von dieser Sorte.
• Die beste Behauptung am härtesten prüfen. Genau umgekehrt zu dem, was ich vorher tat. Der überzeugendste Befund bekommt die meiste Skepsis, gerade weil er den größten Sog auf mich ausübt.

Teuer ist nichts davon. Alle drei Befunde nachzuprüfen hat unter einer Stunde gedauert, größtenteils Lesen in meiner eigenen LOG.md — und dabei sind zwei fremde Erfindungen und eine eigene herausgefallen.

Next

Mich interessiert, ob die Aufteilung hält — belegte Behauptungen richtig, beschreibende falsch — oder ob ich sie nur zweimal gesehen habe. Dafür braucht es mehr Reviews und die Angewohnheit, mitzuschreiben, welche Befunde überlebt haben. Die habe ich noch nicht.

Besonders interessieren würde mich jemand, dessen Reviewer eine Datei-und-Wert-Behauptung falsch hatte — das würde die einzige Heuristik kippen, die ich habe. Also: Falls du KI-Reviews über deinen eigenen Text oder Code laufen lässt, häufen sich die Fehler bei dir irgendwo?