Welk AI-model schrijft de beste code?

Waarom code de moeilijkste benchmark is om te faken

Code is onverbiddelijk op een manier die de meeste taken voor taalmodellen niet zijn. Proza kan vaag kloppen en toch bruikbaar zijn; code is correct of het crasht. Een model dat een functie schrijft die er plausibel uitziet maar randgevallen fout afhandelt, produceert een testsuite die groen kleurt en een productie-incident dat rood kleurt. Er bestaat geen versie van dit werk waarbij halve punten tellen.

Daardoor is code ook de benchmark die het moeilijkst te manipuleren valt. Een leverancier kan een score publiceren op een gecureerde testset, maar elke developer met API-toegang kan het model binnen minuten testen op een echte bug uit zijn eigen backlog. De community-consensus over welk model de beste code schrijft loopt doorgaans maanden voor op officiële leaderboards — en komt steeds op hetzelfde antwoord uit. Let op wat de beste engineers daadwerkelijk gebruiken, niet op wat marketingpagina's beweren.

De aard van het werk is ook veranderd. Twee jaar geleden betekende coding-assistentie single-turn completions: typ een comment, accepteer een suggestie, ga verder. Vandaag strekt hetzelfde werkproces zich uit over agentische loops die bestanden lezen, tests draaien, code aanpassen en zonder toezicht verder itereren. Het model moet niet alleen goed zijn in code schrijven, maar ook in beslissen wát te schrijven, herstellen na fouten, en stoppen wanneer het klaar is. Andere vaardigheden, andere koplopers, andere prijsprofielen.

Vijf dingen scheiden de modellen die het waard zijn van de modellen die dat niet zijn: correctheid, tool-use discipline, begrip van lange contexten, taal-dekking en de totale kosten van een taak van begin tot eind. Het complete plaatje telt zwaarder dan één enkele dimensie.

Het tempo van vooruitgang bepaalt ook hoe je bouwt. Een coding-stack die één modelnaam hardcoded, veroudert snel. De beste teams behandelen het model als een vervangbaar onderdeel achter hun agent-laag en benchmarken elk kwartaal opnieuw. Een nieuwe release die op jouw backlog tien procent meer taken oplost, is meer waard dan elke feature die je in hetzelfde kwartaal zou bouwen — en de enige manier om dat te zien is blijven testen.

De vijf dimensies die bepalen welk model wint

Dit zijn de assen waarop onze scorecard elk model weegt dat in de buurt van een echte codebase komt. Hoe zwaar je elke as weegt hangt af van of het model in een IDE zit, een agent-loop of een batch-job — maar elk model moet op alle vijf een minimumscore halen.

1. 01 — Correctheid bij de eerste poging

   Draait de code, en doet hij het goede?

   Code die compileert maar een null fout afhandelt is erger dan helemaal geen code — de engineer leest het, vertrouwt het en shipt het. De beste voorspeller of een model geschikt is voor coding-werk is het aandeel taken dat het in één keer goed afrondt zonder tweede poging.

2. 02 — Tool-use en agent-loops

   Kan het een workflow aansturen, niet alleen een vraag beantwoorden?

   Moderne coding-agents roepen tools aan: lees een bestand, doorzoek een codebase, draai een test, pas een patch toe. Het model moet weten welke tool wanneer te gebruiken, wanneer te stoppen en hoe te herstellen als de tool rommel teruggeeft. Modellen getraind voor chat falen hier geruisloos; modellen getraind voor agentische loops werken door.

3. 03 — Begrip van lange contexten

   Kan het een hele repository vasthouden?

   Een context van een miljoen tokens is zinloos als het model alleen aandacht heeft voor de eerste en laatste paar pagina's. Test lange-context-prestaties met retrieval-probes op meerdere dieptes in je eigen bestanden. In de praktijk profiteert coding meer van aandachtsdiepte dan van ruwe venstergrootte.

4. 04 — Taal- en framework-dekking

   Beheerst het jouw stack, of alleen Python en JavaScript?

   Alle frontier-modellen zijn vloeiend in de populairste talen. Kwaliteit daalt scherp zodra je Rust, Zig, Elixir, Clojure of een DSL bovenop die talen gaat gebruiken. Framework-dekking is nog ongelijkmatiger: een model dat React moeiteloos aankan, kan struikelen over Phoenix LiveView. Benchmark altijd op je eigen stack.

5. 05 — Kosten per opgeloste taak

   Wat betaal je echt om de wijziging te shippen?

   Agent-loops stapelen kosten snel op. Een model dat twee keer zoveel per token kost maar de taak in één poging oplost in plaats van drie, is de goedkopere keuze. Meet altijd end-to-end: elke read, elke retry, elke tool-aanroep, én de tijd die de engineer besteedt aan het reviewen van het resultaat.

Tokonomix top 5 picks voor code vandaag

Dit is wat we een developer deze week daadwerkelijk in handen zouden geven. Elk model staat op de lijst om een reden die het uitsluit van élke lijst — er bestaat geen model dat tegelijk wint op inline completions, agentische refactors, repo-brede reviews en self-hosted inference. De teams die het meest uit coding-assistenten halen, draaien twee van deze parallel: een snel model op elke toetsaanslag en een zwaarder model dat de agent aanroept zodra het eerste model er niet uitkomt.

Outputprijs per miljoen tokens

Bij coding domineert de outputkost, omdat de assistent het grootste deel van zijn tokens besteedt aan het schrijven van code in plaats van het lezen van je prompt. De grafiek toont de actuele lijstprijs voor elk van de vijf modellen hierboven.

Veldgids: welk model voor welke taak

De mapping hieronder is wat we zouden gebruiken om een team te adviseren dat helemaal van nul begint. Zie het als een startpunt, niet als een definitief oordeel — een kleine benchmark op je eigen backlog verslaat elke generieke aanbeveling.

Benchmark op je eigen backlog voordat je kiest

Een gids als deze kan alleen redeneren over gemiddelden, en gemiddelden shippen je volgende release niet. Pak tien tot twintig gesloten tickets uit je laatste sprint — de rommelige, niet de makkelijke — en speel ze opnieuw af tegen twee of drie kandidaten. Gebruik dezelfde agent-loop en hetzelfde system prompt voor elk. Een middag is genoeg.

Lees daarna de diffs naast elkaar. Draaide de wijziging bij de eerste poging? Greep het model naar de juiste tools? Begreep het de delen van de codebase die het moest aanraken maar niet mocht wijzigen? Bleef het binnen je framework-conventies? Wat kostte elke poging van begin tot eind inclusief retries? Kies de winnaar op basis van je eigen data, ook als een ander model op elk leaderboard wint.