Home / Vault & Second Brain / Mijn AI haalde 50% in een publieke benchmark. Toen las ik de methodologie.

Mijn AI haalde 50% in een publieke benchmark. Toen las ik de methodologie.

Mijn AI haalde 50% in een publieke benchmark. Toen las ik de methodologie.

Mijn AI haalde een middelmatige score in een publieke benchmark. Toen las ik de methodologie.

Vorige week deed een benchmark de ronde die beweerde acht verschillende AI-agent-harnesses te vergelijken die hetzelfde model draaien. Mijn eigen opzet eindigde in de middenmoot — 50%, 15 van de 30 taken. Het bericht werd gedeeld met een licht triomfantelijke toon: “DeepSeek V4 Flash werkt het best met Pi, niet met de rest.” Mijn eerste reactie was, eerlijk gezegd, een steek van twijfel. Had ik op de verkeerde harness gegokt?

Toen deed ik wat ik heb geleerd te doen vóórdat ik een cijfer vertrouw: ik las de methodologie. En hoe beter ik keek, hoe meer de vergelijking uit elkaar begon te vallen. Niet de resultaten zelf — de manier waarop ze waren geproduceerd.

Het eerste probleem: de routing

Elke harness in de test draaide via OpenRouter, een dienst die je verzoek routeert naar welke provider er capaciteit heeft — en providers verschillen enorm in kwaliteit, prijs en cache-gedrag. De ene harness zag 70% cache-hits, de andere 1,5%. Dat is geen eigenschap van de harness. Dat is een eigenschap van welke provider OpenRouter toevallig het verkeer naartoe stuurde. Zoals een commentator het zei: je benchmarkt de harnesses niet, je benchmarkt hoe variabel de routing van OpenRouter is.

Het tweede probleem: de winnaar draaide een andere opzet

De harness die “won” met 66,7% gebruikte niet alleen een andere model-instelling — hij gebruikte een andere reasoning-modus en trok uit twee verschillende providers, terwijl iedereen er één gebruikte. Wanneer je twee variabelen tegelijk verandert, heb je niets vergeleken. Je hebt een verhaal gemaakt.

Het derde probleem: verkeerde taak-fit

De taken waren SaaS-automatisering — Slack, Sheets, Gmail, Airtable. Maar de meeste geteste harnesses zijn gebouwd en geoptimaliseerd om code te schrijven in een repository. Een codetool beoordelen op hoe goed hij spreadsheets beheert, is als een renpaard beoordelen op hoe goed hij een ploeg trekt. Het zegt je iets, maar niet wat de kop beweert.

Wat ik er daadwerkelijk van leerde

Dus mijn score ging van “zorgwekkend” naar “geruststellend” — niet omdat hij veranderde, maar omdat ik begreep wat hij wel en niet betekende. Maar dit is het deel dat ik bewaar: de beoordelingsmethode was echt goed. Een programmatische verifier controleerde de echte staat van de apps, niet de beweringen van de agent. Er zaten decoys in elke taak om agents te vangen die te veel deden. Pass/fail was binair — één gemiste check deed de hele run falen. Dat is precies de discipline die ik in mijn eigen stack wil.

Dus deze week bouw ik mijn eigen versie van die benchmark, op mijn eigen stack: Home Assistant, WordPress, mijn vault, mijn genealogie-database. Read-only guards zodat de agent niets kan muteren. Een deterministische verifier, geen AI die AI beoordeelt. Decoys om overreach te vangen. Wekelijkse runs om regressies te spotten. Niet om een leaderboard te winnen — maar om week na week te weten of mijn agent een taak daadwerkelijk correct afrondt.

De les waar ik telkens op terugkom: een benchmark-score is alleen zo eerlijk als zijn methodologie. Wanneer een cijfer je verrast, update dan niet eerst je overtuigingen. Lees de kleine lettertjes. Soms mat het cijfer dat je zorgen baarde nooit wat je dacht dat het mat.


Hoe bepaal jij of een benchmark-resultaat het vertrouwen waard is — of gewoon een slim verpakt verhaal? Ik hoor graag hoe jij de kleine lettertjes leest.

Wat vond je van dit bericht?

Laat een reactie achter

Je e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *