Warum Selbstprüfung nicht reicht

Die Tool-Landschaft 2026 macht Selbstprüfung zum Weg des geringsten Widerstands. Claude Code schreibt eine Änderung und reviewt sie auf Zuruf; Cursors Agent schreibt einen PR und Bugbot reviewt ihn; Copilot generiert Code und Copilot Code Review kommentiert ihn. Der Fairness halber: Diese Reviewer sind gut, und ein zweiter Durchgang im frischen Kontext kann eine weitere Lesart ergänzen. Ein Praxisbericht beschreibt einen anbieterübergreifenden Workflow , ist aber weder kontrollierter Vergleich noch Ergebnis für eure Repositories.

Die engere Frage lautet, welche Abhängigkeiten Review und Generierung teilen. Kontext, Modellfamilie, Anbieter-Infrastruktur, Eingabedaten und unvollständiger Auftrag können jeweils relevant sein. Architektur allein sagt nicht, welchen konkreten Fehler ein Reviewer findet oder übersieht.

Der folgende Befund ist für Text-Evaluation gemessen, nicht für Code-Review. Panickssery, Bowman und Feng (2024) zeigten, dass LLM-Evaluatoren ihre eigenen Ausgaben mit deutlicher Trefferquote erkennen - und dass die Fähigkeit zur Selbst-Erkennung linear mit der Stärke der Selbst-Bevorzugung korreliert. Die Bias tritt out of the box auf, ohne jedes Fine-Tuning in diese Richtung.

Wataoka, Takahashi und Ri (2024) fanden den Mechanismus: Modelle bewerten niedrig-perplexen Text - Text, der ihnen vertraut vorkommt - höher als menschliche Juroren; GPT-4 zeigte in ihren Messungen signifikante Self-Preference. Code-Review ist eine andere Domäne mit anderen Referenzen und Werkzeugen. Ein Praxisberichtmotiviert einen Test von Reviewer-Distanz, macht die Übertragung aber nicht zum gemessenen Code-Befund.

Diese Dimensionen sind kein Reifegrad-Score. Ein anderer Reviewer verändert eine Abhängigkeit, deterministische Checks ergänzen reproduzierbare Beobachtungen, und ein schriftlicher Auftrag wechselt die Referenz. Zusammen erlauben sie die Fragen „Was haben die Checks beobachtet?“ und „Entspricht die Änderung dem erklärten Auftrag?“

1. Den Auftrag vor dem Run aufschreiben. Ziel, Grenzen, prüfbare Kriterien - das schafft eine Referenz außerhalb des generierten Diffs. Der Auftrag kann trotzdem falsch oder unvollständig sein; haltet diese Grenze sichtbar.
2. Deterministische Checks vorlassen. Typen, Tests und Linter liefern reproduzierbare Ergebnisse für ihre erklärten Checks. Sie beweisen weder Abdeckung, Absicht noch semantische Vollständigkeit. Ob sie überhaupt gelaufen sind oder nur als gelaufen gemeldet wurden, ist eine eigene Frage, die der Beleg über tatsächlich ausgeführte Checks beantwortet.
3. Mit Distanz reviewen. Nutzt ein anderes Modell oder einen anderen Anbieter, wo das Tooling es erlaubt, und messt dann die nützlichen Funde. Die zitierten Studien belegen diesen Code-Effekt nicht.
4. Die Merge-Entscheidung menschlich halten. Jemand liest verantwortlich beobachtete Ergebnisse und Grenzen und entscheidet. Die Entscheidung ist nicht automatisch richtig, aber Eigentümer und Grundlage bleiben prüfbar.

Reality Graph kann schriftlichen Auftrag, gewählte Validierung und accountable Entscheidung von der generierenden Session trennen und beobachtete Ergebnisse in einem Prüfbericht festhalten. Das beweist weder Vollständigkeit des Auftrags noch Bias-Freiheit und ersetzt weder PR-Review noch menschliche Merge-Entscheidung.