Fable 5, Opus 4.8 en Sonnet 4.6: hoe je LLM's eerlijk vergelijkt op je eigen code

Wanneer er een nieuw model uitkomt, beantwoordt de aankondiging de vraag 'hoeveel beter is het op benchmarks' — en niet de enige vraag die mij interesseert: wat verandert het in mijn werk. Ik heb een gecontroleerd experiment uitgevoerd: drie Claude-modellen — Fable 5, Opus 4.8 en Sonnet 4.6 — kregen woordelijk dezelfde opdracht om de codebase van deze blog te auditen, elk in een geïsoleerde kopie van de repository, met een vooraf afgesproken beoordelingsrubriek. In het artikel staat de methodiek zelf, die je op elk project kunt herhalen, de resultaten, en apart: hoe het experiment twee keer stukliep en wat dat leerde.

Waarom benchmarks mijn vraag niet beantwoorden

Publieke benchmarks hebben twee problemen, en beide zijn fundamenteel. Het eerste is datacontaminatie: testvoorbeelden sijpelen door in de trainingssets, en het model 'herinnert' zich de antwoorden gedeeltelijk in plaats van de taak op te lossen. Dat is geen marginaal vermoeden, maar het onderwerp van een hele onderzoeksrichting: het overzicht van Xu en coauteurs (2024) systematiseert onderzoek naar benchmarkcontaminatie, en het EMNLP 2025-overzicht legt de reactie van de industrie vast — de overgang van statische tests naar dynamisch gegenereerde.

Het tweede probleem is eenvoudiger: de benchmark meet niet mijn taak. Ik heb geen model nodig dat het beste olympiadeopgaven oplost. Ik heb een model nodig dat echte bugs vindt in mijn Laravel-blog, geen niet-bestaande verzint, en bewijst dat zijn fix werkt.

Daaruit volgt een simpele gedachte: de beste testbank om modellen te vergelijken is je eigen project. De code ervan bestaat in die combinatie niet in de trainingssets, de taken erop zijn precies die waarvoor ik betaal, en de resultaten kan ik met de hand controleren omdat ik deze code ken.

Experimentontwerp: één prompt, drie geïsoleerde werelden

De opdracht voor alle drie de modellen was woordelijk identiek — alleen de branchnaam en de resultatenmap verschilden. Vier fasen: audit van het tweetalige artikelsysteem van de blog met bewijs voor elke bevinding in de vorm van файл:строка met een codecitaat; keuze van oplossingen voor de drie belangrijkste bevindingen met beschrijving van de afwegingen; implementatie van één fix met zelfcontrole; een notitie over de resultaten in het Russisch en Engels. Een volledige cyclus van engineeringwerk, geen geïsoleerde 'vraag-antwoord' — die aanpak raadt ook Anthropic aan: agents evalueren op taken uit een echt product, volgens een rubriek die vóór de start is afgesproken.

Drie regels maakten de vergelijking eerlijk:

Isolatie. Elk model werkte in een aparte git worktree — een eigen kopie van de werkmap met een eigen branch. De modellen konden elkaars resultaten fysiek niet zien of elkaar hinderen.

Bescherming tegen hallucinaties — in de prompt zelf. De sleutelzin van de opdracht: 'een verzonnen bevinding (niet-bestaande code, verkeerde regel) is erger dan het ontbreken van een bevinding'. Zonder die prikkel neigt een model dat gevraagd wordt problemen te vinden ernaar ze hoe dan ook te 'vinden'. Met die prikkel moet elke bevinding een handmatige controle doorstaan.

Hints buiten de beoordeling houden. In de repository staat een CLAUDE.md die de bekende valkuilen van het project beschrijft — bijvoorbeeld relatieve paden naar assets die breken op URL's met een taalprefix. Alle drie de modellen lezen dit bestand, dus zulke bevindingen zijn 'gratis': ze tellen mee voor zorgvuldigheid, maar niet voor diepgang.

Rubriek: beoordeel alleen wat je met de hand kunt controleren

Vóór de start legde ik zes assen vast van elk vijf punten: nauwkeurigheid van de audit (handmatige controle van een steekproef van bevindingen via файл:строка), diepgang (bevestigde bevindingen die niet in de hints staan), kwaliteit van de redenering over afwegingen, code en de realiteit van de zelfcontrole, kwaliteit van de Russische en Engelse tekst, discipline (nul vragen aan de mens, geen enkele schending van de beperkingen). Het principe is hetzelfde als bij een goede code review: hoe minder een as op smaak leunt en hoe meer op een controleerbaar feit, hoe meer je haar kunt vertrouwen.

Hoe alles de eerste keer stukliep

De eerste run deed ik verkeerd — en dat bleek het meest overdraagbare deel van het experiment. Ik opende drie interactieve sessies parallel in dezelfde repositorymap. Na een paar minuten lagen er niet-gecommitte wijzigingen in de werkboom die niet toe te schrijven waren: een gedeelde checkout betekent dat wanneer één sessie git checkout -bdoet, de branch bij alle drie wisselt, en hun wijzigingen en commits door elkaar lopen. Een van de sessies deed bovendien git stash en veegde alles erin bij elkaar — inclusief mijn eigen bestanden die niets met het experiment te maken hadden.

“Parallelle AI-agents in één map is geen parallel experiment. Het is één groot conflict met drie auteurs.”

– de conclusie die me een herstart kostte

De resultaten van twee sessies moesten als onbruikbaar worden beschouwd: zelfs als ze tot het einde doorgewerkt zouden hebben, zou ik niet eerlijk kunnen zeggen wiens aanpassingen ik beoordeel. De tweede run — al in geïsoleerde worktrees — liep tegen de limieten van het abonnement aan: twee agents sneuvelden bij de start, en de derde hing, terwijl hij in de interface bleef lijken op 'werkend'. De diagnose werd gesteld door het bestandssysteem, niet door de statusindicator: in twintig minuten verscheen er geen enkel bestand in zijn werkkopie. Dit is de tweede overdraagbare les: de levendigheid van een agent controleer je aan de hand van wijzigingen op schijf. Na een herstart doorliepen alle drie de modellen de volledige cyclus onder gelijke omstandigheden.

Resultaten: waar de modellen gelijk zijn en waar ze verschillen

Het belangrijkste resultaat is wat niet gebeurde: geen enkel model had hallucinaties. Ik heb van elk handmatig drie of meer bevindingen gecontroleerd — alle citaten en regelnummers zijn tot op het teken nauwkeurig. Voor audit-taken is dit de belangrijkste vertrouwensdrempel, en alle drie zijn erdoor gekomen.

Daarna beginnen de verschillen:

	Fable 5	Opus 4.8	Sonnet 4.6
Bevestigde bevindingen	11	5	9
Niet-triviale unieke	3	1	2
Zelfcontrole van de fix	integratierender op een tijdelijke DB, xmllint, attributie van andermans gefaalde test	linter + render; ving een eigen bug	alleen linter en lijst van routes
Tokens / tijd	164k / 21 min	101k / 12 min	131k / 12 min
Totaalscore rubriek (van 30)	30	24	25,5

Kwalitatieve verschillen zijn informatiever dan scores. Opus 4.8 was de enige die een kapotte kop Content-Type in de sitemap niet opmerkte (de twee anderen vonden die wel) en liet hem in zijn eigen fix staan; en in zijn Nederlandse tekst lekte een Engels woord — 'и even путь к картинке'. Sonnet 4.6 maakte een correcte fix, maar haar zelfcontrole was declaratief: een linter in plaats van een run. Fable 5 onderscheidde zich juist op de zelfcontrole: ze ontdekte dat php op mijn machine een wrapper is om een docker-container die op de hoofdmap is gemount, bouwde alle controles om via wegwerpcontainers en draaide haar fix integraal op een tijdelijke database. Het verschil tussen 'ik heb het gedaan' en 'ik heb bewezen dat ik het heb gedaan' — dat is de meest onderscheidende as voor agent-taken.

Nog een nuttig signaal is convergentie: alle drie de modellen noemden onafhankelijk van elkaar hetzelfde probleem met de sitemap als belangrijkste bevinding. Wanneer onafhankelijke auditors samenkomen in de topbevinding, is dat een goedkoop surrogaat voor interexpert-overeenstemming: het probleem is vrijwel zeker echt.

Een jurylid uit de deelnemers

De beoordeling volgens de rubriek werd uitgevoerd door Fable 5 — hetzelfde model dat aan de vergelijking deelnam. Dit is een methodologische zwakte, en die moet je ronduit benoemen: LLM-jury's geven systematisch hogere scores aan hun eigen teksten, en die neiging is sterker naarmate het model zijn eigen teksten beter herkent — dit is aangetoond in het werk van Panickssery en coauteurs op NeurIPS 2024. De bias kun je op twee manieren verzachten, en ik heb beide gebruikt: ten eerste de rubriek zo veel mogelijk verschuiven van smaakassen naar verifieerbare feiten — nauwkeurigheid van regels, volledigheid van de fix, een geleend anderstalig woord zijn niet afhankelijk van de sympathie van de jury; ten tweede het conflict expliciet declareren en betwiste assen aan een kruiscontrole door een ander model of een mens geven. De subjectieve assen van mijn eindoordeel — kwaliteit van de tekst, kwaliteit van de redenering — moet je met deze correctie lezen.

Beperkingen van eerlijkheid

Eén run per model is n=1: verschillen van een of twee punten betekenen niets, je moet alleen kwalitatieve kloven vertrouwen — een gemiste bug, de diepte van de zelfcontrole. Het experiment meet drie modellen op één taak in één domein; 'Fable 5 is in het algemeen beter' volgt daar niet uit. En je moet de prijs in gedachten houden: het topmodel verbruikte 1,6 keer meer tokens en bijna twee keer zoveel tijd als de zuinigste deelnemer, en zijn token volgens de prijslijst is op zichzelf ook duurder — voor reguliere taken is dat een zwaarwegend argument voor eenvoudigere modellen.

Wat ik meeneem

De methodiek kwam neer op een korte checklist die werkt voor elk project en elk model:

• Een testopdracht — een volledige cyclus van echt werk op je eigen code, geen synthetisch puzzeltje.
• Eén prompt voor iedereen, isolatie via aparte worktrees, resultaten in aparte branches.
• In de prompt een expliciete prijs voor hallucinatie: een verzonnen bevinding is erger dan geen bevinding.
• Hints die voor iedereen beschikbaar zijn (documentatie, notities in de repository) tellen niet mee voor de diepte.
• De rubriek wordt vóór de start vastgelegd en steunt op verifieerbare feiten, niet op indruk.
• De selectie van bevindingen met de hand controleren; overeenkomst in topbevindingen bij onafhankelijke modellen is een signaal van hun realiteit.
• Een jurylid dat zelf deelnemer is — een gedeclareerd conflict: betwiste assen aan kruisbeoordeling geven.
• De levendigheid van een agent controleren via schijf, niet via de indicator in de interface.

Een bonus die niet in het plan zat: het experiment betaalde zichzelf terug. Drie onafhankelijke audits vonden echte problemen in de blog — van een sitemap zonder Engelse pagina's tot dode queries in de controller — en twee kant-en-klare fixes liggen al in branches te wachten op overdracht naar productie. Modellen vergelijken op je eigen code levert, anders dan het lezen van benchmarks, niet alleen een mening op.

Bronnen en richtlijnen

• Benchmark Data Contamination of Large Language Models: A Survey (Xu et al., 2024) — een systematisering van het probleem van benchmark-vervuiling; het belangrijkste argument voor tests op je eigen code.
• Benchmarking LLMs Under Data Contamination: From Static to Dynamic Evaluation (EMNLP 2025) — hoe de industrie overstapt van statische tests naar dynamische; mijn experiment is een specifiek geval van een dynamische test.
• Demystifying evals for AI agents (Anthropic Engineering, 2026) — de praktijk van het evalueren van agents: taken uit een echt product, verifieerbare rubrieken, onderscheid tussen traject en resultaat.
• LLM Evaluators Recognize and Favor Their Own Generations (NeurIPS 2024) — waarom een model-als-rechter zijn eigen werk hoger beoordeelt en wat daaraan te doen.
• Run parallel sessions with worktrees (Claude Code Docs) — het standaardmechanisme voor het isoleren van parallelle agent-sessies, zonder welke de eerste uitvoering van het experiment mislukte.