AI-codeerbenchmarks lezen en voorkomen dat je een papieren winnaar kiest

Kort gezegd: het cijfer “lost 76 procent van de taken op” zegt op zichzelf bijna niets. Het gaat erom welke taakset dit cijfer heeft opgeleverd, welk model en welke agent-wrapper samen zijn meegerekend, of de taken nieuw of oud zijn en hoeveel het heeft gekost. Zonder deze voorwaarden is het percentage geschikt voor een reclamebanner, maar niet om een tool te kiezen.

Hierna leg ik in gewone taal uit wat de twee belangrijkste codeerbenchmarks meten, waar de addertjes onder het gras in de tabellen zitten en hoe je een ranglijst in een minuut controleert voordat je erop vertrouwt. Hieronder worden historische benchmarkdefinities besproken. Er wordt geen actuele gepaarde ranglijstmomentopname weergegeven; een huidige vergelijking van scores of kosten vereist een eigen gekoppelde tabel, datum en configuratie.

Lees meer over werken met modellen in de Ailoot-documentatie.

Wat laat een benchmarkpercentage eigenlijk zien?#

Een benchmark werkt eenvoudig. Er is een kant-en-klare lijst met programmeertaken. De tool krijgt elke taak, stuurt code terug en het systeem voert geautomatiseerde tests uit om te zien of de oplossing werkt. Het aandeel geslaagde taken is het percentage dat in de tabel staat.

Het sterke punt is dat de evaluatie objectief is. Een test is groen of rood; niemand geeft een score op basis van een “indruk”. In dat opzicht zijn benchmarks eerlijker dan reviews of aanbevelingen.

De zwakte is precies hetzelfde. De taakset is eindig en vooraf bij iedereen bekend, ook bij degenen die de modellen trainen. Elke meting heeft eigen voorwaarden. En de taken in de set lijken vrijwel zeker niet op wat jij doet. Daaruit volgen alle valkuilen die ik hieronder bespreek. Het percentage beschrijft hoe een tool presteert op de gesloten takenlijst van iemand anders en is niet rechtstreeks toepasbaar op jouw project.

Wat meet HumanEval, en waarom kun je er niet meer op kiezen?#

HumanEval is gemaakt bij OpenAI en in 2021 uitgebracht met het Codex-model. De set bevat 164 kleine Python-taken: modellen krijgen een beschrijving van een functie in woorden, schrijven de inhoud ervan en een reeks geautomatiseerde tests controleert of die correct werkt.

Destijds was dit een goede manier om modellen van elkaar te onderscheiden. In hun eigen artikel geven de auteurs dit cijfer: de eerste Codex loste in één poging 28.8 procent van de taken op, terwijl gewone GPT-3 er nul oploste.

Sindsdien zijn modellen gegroeid en tegenwoordig voltooien de sterke modellen bijna alle HumanEval-taken. Wanneer iedereen dicht bij 100 procent scoort, maakt de tabel geen onderscheid meer: de verschillen tussen tools verdwijnen. Dit heet verzadiging van de benchmark, en HumanEval verkeert al lange tijd in die toestand.

Het tweede gebrek is ernstiger. De taken zijn piepklein: schrijf één functie op basis van een beschrijving. Je echte werk is anders: je werkt aan een groot project met een geschiedenis, moet code van iemand anders begrijpen, een defect vinden en voorkomen dat je aangrenzende code breekt. Er gaapt een kloof tussen “een functie vanaf nul schrijven” en “een bug in een actief project oplossen”. Een hoge HumanEval-score is tegenwoordig dus geen reden meer om een tool te kiezen; het is eerder een teken dat “de basis op orde is”.

Wat meet SWE-bench, en hoe ligt die dichter bij echt werk?#

SWE-bench is fundamenteel anders en daarom interessanter. De benchmark is samengesteld uit echte issues en pull requests in populaire GitHub-projecten. Volgens de auteurs bevat hij 2,294 taken uit 12 grote Python-repositories en werd hij uitgebracht in oktober 2023.

De evaluatielogica is eerlijk. Ze nemen een moment in een project waarop een echt defect aanwezig was en een reeks tests die toen faalden. De tool krijgt de probleembeschrijving en past de code aan. Daarna worden diezelfde tests uitgevoerd: als ze groen worden, is de taak daadwerkelijk opgelost; hier vertrouwt niemand op mondelinge beloften.

De eerste cijfers laten zien hoeveel moeilijker dit is dan speelgoedtaken. De eerste baseline-aanpak scoorde slechts 1.96 procent op SWE-bench, en de eerste agent scoorde 12.47 procent. Met andere woorden: zelfs in de buurt komen van echt codeerwerk was moeilijk; de percentages zijn later gestegen, maar begonnen dicht bij nul.

Als je tegenwoordig hoge cijfers ziet in een ranglijst van AI-codeeragents, komen die meestal van SWE-bench of van de door mensen geverifieerde deelverzameling van 500 taken, SWE-bench Verified. Het is een redelijke benchmark. Maar ook deze heeft voorwaarden waaronder het percentage misleidend is, en daar ga ik nu op in.

Zelfs de eerlijkste benchmark in een tabel is nog geen resultaat op jouw project. De uitkomst hangt af van hoe je met de tool werkt, en de bovenste regel van de ranglijst zegt maar weinig. Voor betrouwbaar werk is de combinatie van belang: AI-kloon, Second Brain en context engineering. Schone context verhoogt je persoonlijke slagingskans veel merkbaarder dan een model uit een tabel kiezen.

Waarom laat hetzelfde model een ander percentage zien?#

Hier zit de meest voorkomende fout bij het lezen van benchmarks. Mensen lezen een tabel als een ranglijst van modellen: dit model is twee procent slimmer dan dat model. Maar drie dingen beïnvloeden het percentage, en het model is er maar één van.

Ten eerste het model zelf. Ten tweede de agent-wrapper eromheen: een programma waarmee het model door bestanden kan navigeren, opdrachten kan uitvoeren, fouten kan lezen en code kan herschrijven. Hetzelfde model geeft in een slimme wrapper andere resultaten dan in een eenvoudige, omdat de wrapper bepaalt hoe het model met het project werkt. Ten derde het redeneerniveau: hoe diep het model over elke stap nadenkt. Hoe langer het nadenkt, hoe hoger het percentage meestal is en hoe hoger de kosten.

Een reproduceerbare vergelijking moet de volledige opzet bewaren. Gebruik dit als rapportagesjabloon, niet als gemeten ranglijst:

Zo zie je wat veranderde en of de vergelijking de redeneerinstelling werkelijk isoleert. Het eerdere numerieke voorbeeld zonder bronlink geldt niet als gemeten resultaat.

De regel is: een goede ranglijst vermeldt altijd welk model, welke wrapper en welk redeneerniveau zijn gebruikt. Als de tabel alleen een modelnaam en een percentage bevat, zonder wrapper, is hij moeilijk te vertrouwen: je weet niet wat er eigenlijk is gemeten. Meer over de combinatie van “model plus wrapper” staat in het artikel over de ranglijst van AI-codeeragents.

Dit verklaart ook waarom een tool met een topscore soms moeite heeft bij jou. De benchmark meet een model in de verfijnde wrapper van iemand anders, op de taken van iemand anders. Jouw wrapper, project en de context die je het model geeft, zijn anders. Op jouw project hangt het resultaat af van de context; de tabelregel is van ondergeschikt belang.

Waarom “verlopen” taken, en wat is datalek van trainingsdata?#

Hier zit de adder onder het gras die niet in het cijfer zelf zichtbaar is, maar het cijfer meer dan wat ook ondermijnt. Modellen worden getraind op enorme hoeveelheden tekst en code die van het internet zijn verzameld. En bijna alle codeerbenchmarks zijn openbaar: de taken, tests en referentieoplossingen.

Het werkt eenvoudig. Als een taak en de juiste oplossing ervan in de trainingsdata terecht zijn gekomen, kan het model ze hebben onthouden. Tijdens de evaluatie lost het de taak dan niet zozeer op, maar haalt het een bekend antwoord uit zijn geheugen. Het lijkt een oplossing, maar is slechts een herinnering. Dit heet trainingslekkage of datacontaminatie.

Hoe ouder en populairder de taakset, hoe groter het risico. HumanEval staat sinds 2021 online; de set is vele malen herschreven, geanalyseerd en in talloze datasets opgenomen. Het zou vreemd zijn om te verwachten dat een modern model hem niet heeft “gezien”. Daarom is de actualiteit van de taken een aparte kwaliteitsindicator voor een benchmark. Een goede set wordt regelmatig bijgewerkt of houdt een deel van de taken gesloten, zodat die niet vooraf kunnen worden aangeleerd.

Wat moet je doen als je een ranglijst bekijkt? Controleer de datum van de taken en of de set wordt bijgewerkt. Als een benchmark is opgebouwd uit recente defecten uit de afgelopen maanden, verdient hij meer vertrouwen. Als het een set van vijf jaar geleden is, zegt een hoog percentage daarop meer over het goede geheugen van het model dan over zijn vermogen om jouw nieuwe taak op te lossen. Dit effect wordt met een concreet voorbeeld getoond in het artikel over de nieuwe FrontierCode-benchmark, waarvan de taken bewust nieuw waren.

Waarom betekent een verschil van een paar procentpunten vaak niets?#

Nog iets dat de bovenste plek in een tabel misleidend maakt: een model reageert niet elke keer hetzelfde. Op dezelfde prompt kan het een iets andere redeneerlijn volgen. Als je één tool dus meerdere keren op één taakset uitvoert, schommelt het percentage een beetje tussen runs; die schommeling heet variatie.

De praktische conclusie is eenvoudig. Wanneer twee regels in een ranglijst één of twee procent verschillen, kan dat makkelijk ruis zijn. Een tool najagen die “twee procent hoger” scoort, is zinloos: bij de volgende run kunnen de posities gemakkelijk omdraaien. Een verschil is het overwegen waard als het duidelijk is en overeind blijft bij een grote set taken; een paar punten voldoen niet aan die norm.

En het laatste punt, dat bijna altijd belangrijker is dan het percentage zelf, is de prijs. Vergelijkbare resultaten kunnen heel verschillende bedragen kosten. Een kostenvergelijking vereist beide model-harnasconfiguraties en de totale uitgaven aan de geëvalueerde takenreeks, inclusief mislukte pogingen. Deel door alle pogingen voor kosten per poging of door opgeloste taken voor kosten per opgeloste taak en benoem welke maatstaf je gebruikt. Dit artikel levert geen gepaarde kostenmeting met bron. Lees een regel in een ranglijst dus altijd samen met de prijs, want op zichzelf zegt het percentage weinig. Het artikel over de kosten van één opgeloste taak legt uit hoe je tools eerlijk op kosten vergelijkt.

Hoe lees je een benchmarktabel in een minuut?#

Laat me alles samenvatten in een korte checklist. Open een ranglijsttabel en loop deze zeven punten op volgorde na.

1. Welke taakset? HumanEval is tegenwoordig zwak; SWE-bench ligt dichter bij echt werk. Als de set helemaal niet wordt genoemd, hoef je niet verder te lezen.
2. Zijn de taken nieuw of oud? Een nieuwe of gedeeltelijk gesloten set is betrouwbaarder dan een oude openbare set die het model mogelijk heeft geleerd.
3. Welk model is gemeten? De exacte naam en versie, geen vaag “AI” of alleen de naam van een modelfamilie.
4. Welke agent-wrapper? Het percentage hoort bij de combinatie “model plus wrapper”. Als de wrapper niet is vermeld, weet je niet wat er is gemeten.
5. Welk redeneerniveau? Eén model levert op verschillende niveaus verschillende percentages en kosten op.
6. Wat kost een taak? Vergelijkbare resultaten kunnen qua prijs meerdere keren verschillen. Lees het percentage samen met de kosten.
7. Hoe groot is de variatie? Een verschil van één of twee punten tussen regels is vaak gewoon ruis.

Er is een achtste vraag, en die gaat over jou: Lijken de taken in de set op jouw werk? Een benchmark met Python-taken zegt weinig tegen iemand die een website of bot bouwt met een andere set tools. Zelfs een eerlijk cijfer op de taken van iemand anders garandeert geen resultaat op jouw project. Er is maar één betrouwbare manier om dat te controleren: voer een paar van je gebruikelijke taken uit met de tool en bekijk zelf het resultaat. Het artikel over AI-gegenereerde code controleren legt uit hoe je kunt zien of de code werkt als je zelf niet programmeert.

Waar moet je uiteindelijk naar kijken?#

Het belangrijkste punt van dit hele artikel is kort: een plek in de ranglijst is een reden om een tool nader te bekijken, maar je zult zelf verder moeten graven. Een hoog cijfer zegt alleen dat een tool het behoorlijk deed op een specifieke, gesloten takenlijst onder specifieke voorwaarden. Het percentage laat niet zien of die voorwaarden overeenkomen met die van jou.

Lees dus wat er onder de regel in de ranglijst staat: welke taken, hoe actueel ze zijn, welke combinatie van model en wrapper is gebruikt, welk redeneerniveau, hoeveel het kost en of het verschil in de ruis verdwijnt. Een tabel die deze vragen niet beantwoordt, hoort op een reclamebanner. De beoordeling welke tool je in 2026 voor programmeren kiest legt uit welke tool je in eerste instantie voor jouw taken kunt kiezen.

En dit is belangrijker dan welke benchmark dan ook. Zelfs de beste tool in de ranglijst heeft moeite met rommelige context en werkt goed met schone context. Je persoonlijke slagingskans hangt af van wat je het model aanreikt en hoe je de taak formuleert; de tabelregel is van ondergeschikt belang. De ranglijst helpt de duidelijk zwakke opties uit te sluiten, maar jij levert het resultaat.

Een plek in de ranglijst helpt zwakke opties uit te sluiten, maar resultaten op jouw project hangen af van de werkwijze: AI-kloon plus Second Brain plus context engineering.

Voor je verdere werk: Ailoot.