Fable 5, Opus 4.8 und Sonnet 4.6: Wie man LLMs ehrlich am eigenen Code vergleicht

Wenn ein neues Modell erscheint, beantwortet die Ankündigung die Frage „wie viel besser ist es in Benchmarks“ — und beantwortet nicht die einzige Frage, die mich interessiert: Was wird es an meiner Arbeit ändern. Ich habe ein kontrolliertes Experiment durchgeführt: drei Claude-Modelle — Fable 5, Opus 4.8 und Sonnet 4.6 — erhielten wortwörtlich dieselbe Aufgabe zum Audit der Codebasis dieses Blogs, jedes in einer isolierten Kopie des Repositories, mit einer vorab vereinbarten Bewertungsrubrik. Im Artikel steht die Methodik selbst, die man in jedem Projekt wiederholen kann, die Ergebnisse, und separat — wie das Experiment zweimal gescheitert ist und was das gelehrt hat.

Warum Benchmarks meine Frage nicht beantworten

Öffentliche Benchmarks haben zwei Probleme, und beide sind fundamental. Das erste ist Datenkontamination: Testbeispiele sickern in die Trainingsdaten, und das Modell „erinnert“ sich teilweise an die Antworten, statt die Aufgabe zu lösen. Das ist kein marginaler Verdacht, sondern Gegenstand eines ganzen Forschungszweigs: die Übersicht von Xu und Co-Autoren (2024) systematisiert die Forschung zur Benchmark-Kontamination, und die EMNLP-2025-Übersicht hält die Antwort der Industrie fest — den Übergang von statischen Tests zu dynamisch generierten.

Das zweite Problem ist einfacher: Der Benchmark misst nicht meine Aufgabe. Ich brauche kein Modell, das Olympiade-Aufgaben am besten löst. Ich brauche ein Modell, das reale Bugs in meinem Laravel-Blog findet, keine nicht existierenden erfindet und beweist, dass sein Fix funktioniert.

Daraus folgt ein einfacher Gedanke: Der beste Teststand für den Modellvergleich ist das eigene Projekt. Sein Code existiert in dieser Kombination nicht in den Trainingsdaten, die Aufgaben darauf sind genau die, für die ich bezahle, und die Ergebnisse kann ich von Hand prüfen, weil ich diesen Code kenne.

Versuchsdesign: ein Prompt, drei isolierte Welten

Die Aufgabe war für alle drei Modelle wortwörtlich gleich — unterschiedlich waren nur der Branch-Name und der Ergebnisordner. Vier Phasen: Audit des zweisprachigen Artikelsystems des Blogs mit Beleg jeder Fundstelle in Form von файл:строка mit Codezitat; Auswahl von Lösungen für die drei wichtigsten Fundstellen mit Beschreibung der Kompromisse; Umsetzung eines Fixes mit Selbstprüfung; Notiz zu den Ergebnissen auf Russisch und Englisch. Ein vollständiger Zyklus ingenieurmäßiger Arbeit, kein isoliertes „Frage-Antwort“ — diesen Ansatz empfiehlt auch Anthropic: Agenten an Aufgaben aus einem realen Produkt bewerten, nach einer vor dem Start vereinbarten Rubrik.

Drei Regeln machten den Vergleich ehrlich:

Isolation. Jedes Modell arbeitete in einem separaten git worktree — einer eigenen Kopie des Arbeitsverzeichnisses mit eigenem Branch. Die Modelle konnten physisch die Ergebnisse der anderen nicht sehen oder sich gegenseitig stören.

Schutz vor Halluzinationen — im Prompt selbst. Die Schlüsselzeile der Aufgabe: „eine erfundene Fundstelle (nicht existierender Code, falsche Zeile) ist schlimmer als keine Fundstelle“. Ohne diesen Anreiz neigt ein Modell, das gebeten wird, Probleme zu finden, dazu, sie in jedem Fall zu „finden“. Mit ihm muss jede Fundstelle eine manuelle Prüfung überstehen.

Ausschluss von Hinweisen aus der Wertung. Im Repository liegt eine CLAUDE.md, die bekannte Stolperfallen des Projekts beschreibt — etwa relative Asset-Pfade, die bei URLs mit Sprachpräfix brechen. Alle drei Modelle lesen diese Datei, daher sind solche Fundstellen „gratis“: Sie zählen für Sorgfalt, aber nicht für Tiefe.

Rubrik: nur bewerten, was man von Hand prüfen kann

Vor dem Start habe ich sechs Achsen mit je fünf Punkten festgelegt: Genauigkeit des Audits (manuelle Prüfung einer Stichprobe von Fundstellen per файл:строка), Tiefe (bestätigte Fundstellen, die nicht in den Hinweisen stehen), Qualität der Abwägung von Kompromissen, Code und Realität der Selbstprüfung, Qualität des russischen und englischen Textes, Disziplin (null Fragen an den Menschen, keine einzige Verletzung der Einschränkungen). Das Prinzip ist dasselbe wie bei einem guten Code-Review: Je weniger eine Achse auf Geschmack und je mehr sie auf prüfbaren Fakten beruht, desto mehr kann man ihr vertrauen.

Wie alles beim ersten Mal scheiterte

Den ersten Lauf habe ich falsch gemacht — und das erwies sich als der am besten übertragbare Teil des Experiments. Ich öffnete drei interaktive Sitzungen parallel im selben Repository-Ordner. Nach einigen Minuten lagen im Arbeitsbaum nicht committete Änderungen, die sich nicht zuordnen ließen: Ein gemeinsamer Checkout bedeutet, dass, wenn eine Sitzung git checkout -bmacht, der Branch bei allen dreien wechselt und ihre Änderungen und Commits sich vermischen. Eine der Sitzungen machte zusätzlich git stash und fegte alles hinein — einschließlich meiner eigenen Dateien, die nichts mit dem Experiment zu tun hatten.

„Parallele KI-Agenten in einem Ordner sind kein paralleles Experiment. Das ist ein großer Konflikt mit drei Autoren.“

– die Erkenntnis, die mich einen Neustart kostete

Die Ergebnisse zweier Sitzungen mussten als unbrauchbar eingestuft werden: Selbst wenn sie bis zum Ende nachgearbeitet hätten, hätte ich nicht ehrlich sagen können, wessen Änderungen ich bewerte. Der zweite Lauf – bereits in isolierten Worktrees – stieß an die Tarifgrenzen: Zwei Agenten starben beim Start, und der dritte hing fest, während er in der Oberfläche weiterhin „arbeitend“ aussah. Die Diagnose stellte das Dateisystem, nicht die Statusanzeige: In zwanzig Minuten erschien in seiner Arbeitskopie keine einzige Datei. Das ist die zweite übertragbare Lektion: Die Lebendigkeit eines Agenten wird an den Änderungen auf der Festplatte geprüft. Nach dem Neustart durchliefen alle drei Modelle den vollständigen Zyklus unter gleichen Bedingungen.

Ergebnisse: Wo die Modelle gleich sind und wo sie sich unterscheiden

Das wichtigste Ergebnis ist das, was nicht geschah: bei keinem Modell gibt es Halluzinationen. Ich habe bei jedem manuell drei oder mehr Funde geprüft – alle Zitate und Zeilennummern sind bis auf das Zeichen genau. Für Audit-Aufgaben ist dies die wichtigste Vertrauensschwelle, und alle drei haben sie bestanden.

Danach beginnen die Unterschiede:

	Fable 5	Opus 4.8	Sonnet 4.6
Bestätigte Funde	11	5	9
Nichttriviale einzigartige	3	1	2
Selbstprüfung des Fixes	Integrations-Rendering auf temporärer DB, xmllint, Zuordnung eines fremden fehlgeschlagenen Tests	Linter + Rendering; fing eigenen Bug	nur Linter und Routenliste
Token / Zeit	164k / 21 Min.	101k / 12 Min.	131k / 12 Min.
Ergebnis nach Rubrik (von 30)	30	24	25,5

Qualitative Unterschiede sind informativer als Punkte. Opus 4.8 war der einzige, der die kaputte Überschrift Content-Type in der sitemap nicht bemerkte (die beiden anderen fanden sie) und sie in seinem eigenen Fix beließ; zudem floss in seinen russischen Text ein englisches Wort ein – „und even der Pfad zum Bild“. Sonnet 4.6 machte einen korrekten Fix, aber ihre Selbstprüfung war deklarativ: Linter statt Ausführung. Fable 5 zeichnete sich gerade bei der Selbstprüfung aus: Sie entdeckte, dass php auf meiner Maschine ein Wrapper über einen Docker-Container ist, der auf das Hauptverzeichnis gemountet ist, baute alle Prüfungen über Einweg-Container um und ließ ihren Fix integrativ auf einer temporären Datenbank laufen. Der Unterschied zwischen „ich habe es gemacht“ und „ich habe bewiesen, dass ich es gemacht habe“ – das ist die am stärksten differenzierende Achse für Agentenaufgaben.

Ein weiteres nützliches Signal ist die Konvergenz: Alle drei Modelle nannten unabhängig voneinander dasselbe Problem mit der sitemap als wichtigsten Fund. Wenn unabhängige Auditoren beim Top-Fund übereinstimmen, ist das ein billiges Analogon zur Inter-Experten-Übereinstimmung: Das Problem ist fast sicher real.

Ein Richter aus den Reihen der Teilnehmer

Die Bewertung nach Rubrik führte Fable 5 durch – dasselbe Modell, das am Vergleich teilnahm. Das ist ein methodisches Loch, und man muss es direkt ansprechen: LLM-Richter bewerten eigene Texte systematisch zu hoch, wobei die Neigung umso stärker ist, je besser das Modell seine eigenen Texte erkennt – das zeigen Panickssery und Mitautoren auf der NeurIPS 2024. Man kann die Verzerrung auf zwei Weisen mildern, und ich nutzte beide: Erstens die Rubrik maximal von Geschmacksachsen auf überprüfbare Fakten zu verschieben – Zeilengenauigkeit, Vollständigkeit des Fixes, ein durchgesickertes fremdsprachiges Wort hängen nicht von den Sympathien des Richters ab; zweitens den Konflikt ausdrücklich zu deklarieren und strittige Achsen einer Kreuzprüfung durch ein anderes Modell oder einen Menschen zu übergeben. Die subjektiven Achsen meines Ergebnisses – Textqualität, Qualität der Argumentation – sollte man mit dieser Korrektur lesen.

Grenzen der Ehrlichkeit

Ein Durchlauf pro Modell ist n=1: Unterschiede von ein bis zwei Punkten bedeuten nichts, vertrauen sollte man nur qualitativen Abständen – einem übersehenen Bug, der Tiefe der Selbstprüfung. Das Experiment misst drei Modelle bei einer Aufgabe in einer Domäne; „Fable 5 ist generell besser“ folgt daraus nicht. Und man sollte den Preis bedenken: Das Top-Modell verbrauchte 1,6-mal mehr Token und fast doppelt so viel Zeit wie der sparsamste Teilnehmer, und sein Token ist laut Preisliste auch an sich teurer – für regelmäßige Aufgaben ist das ein gewichtiges Argument für einfachere Modelle.

Was ich für mich mitnehme

Die Methodik reduzierte sich auf eine kurze Checkliste, die für jedes Projekt und alle Modelle funktioniert:

• Die Testaufgabe ist ein vollständiger Zyklus realer Arbeit am eigenen Code, keine synthetische Aufgabe.
• Ein Prompt für alle, Isolation über separate Worktrees, Ergebnisse in separaten Branches.
• Im Prompt ein expliziter Preis für Halluzination: Ein erfundener Fund ist schlechter als kein Fund.
• Hinweise, die allen zugänglich sind (Dokumentation, Notizen im Repository), werden aus der Bewertung der Tiefe ausgeschlossen.
• Die Rubrik wird vor dem Start festgelegt und stützt sich auf überprüfbare Fakten, nicht auf Eindrücke.
• Eine Stichprobe der Funde von Hand prüfen; die Übereinstimmung der Top-Funde bei unabhängigen Modellen ist ein Signal für ihre Realität.
• Ein Richter-Teilnehmer ist ein deklarierter Konflikt: Strittige Achsen zur Kreuzbewertung geben.
• Die Lebendigkeit des Agenten an der Festplatte prüfen, nicht an der Anzeige in der Oberfläche.

Ein Bonus, der nicht im Plan stand: Das Experiment hat sich selbst amortisiert. Drei unabhängige Audits fanden im Blog reale Probleme – von der sitemap ohne englische Seiten bis zu toten Abfragen im Controller – und zwei fertige Fixes liegen bereits in Branches und warten auf die Übernahme in die Produktion. Der Vergleich von Modellen am eigenen Code hinterlässt, anders als das Lesen von Benchmarks, nicht nur eine Meinung.

Quellen und Orientierungspunkte

• Benchmark Data Contamination of Large Language Models: A Survey (Xu et al., 2024) – eine Systematisierung des Problems der Benchmark-Kontamination; das Hauptargument für Tests am eigenen Code.
• Benchmarking LLMs Under Data Contamination: From Static to Dynamic Evaluation (EMNLP 2025) — wie die Branche von statischen Tests zu dynamischen übergeht; mein Experiment ist ein Sonderfall des dynamischen Tests.
• Demystifying evals for AI agents (Anthropic Engineering, 2026) — Praxis der Agentenbewertung: Aufgaben aus dem realen Produkt, überprüfbare Rubriken, Unterscheidung von Trajektorie und Ergebnis.
• LLM Evaluators Recognize and Favor Their Own Generations (NeurIPS 2024) — warum das Richter-Modell sich selbst höhere Bewertungen gibt und was man dagegen tun kann.
• Run parallel sessions with worktrees (Claude Code Docs) — der standardmäßige Mechanismus zur Isolierung paralleler Agenten-Sitzungen, ohne den der erste Experimentlauf gescheitert ist.