Databricks heeft een van de meest interessante benchmarks van dit moment gepubliceerd voor programmeeragents, niet omdat het gebruikmaakt van een openbare dataset met oefeningen, maar omdat het gebaseerd is op hun eigen code. Het bedrijf heeft modellen en harnesses van agents geëvalueerd op echte taken, afkomstig uit interne pull requests, met wijzigingen binnen een codebase van miljoenen regels code en meerdere programmeertalen, waaronder Python, Go, TypeScript, Scala, Rust en Java.
Het meest opvallende resultaat is dat GLM 5.2, een open source-model van Z.ai, in de hoge capaciteitsgroep verschijnt en statistisch gelijkwaardig scoort met Claude Opus 4.8 in kwaliteit binnen deze interne Databricks-test. Het verschil zit in de kosten: GLM 5.2 kost 1,28 dollar per taak, tegenover 1,94 dollar per taak voor Opus 4.8 in de vergeleken configuratie.
De conclusie is niet dat één model automatisch alle andere vervangt in alle scenario’s. Een belangrijke les is dat in echte engineering-taken de grenzen van efficiëntie niet meer exclusief bij één leverancier liggen. Volgens Databricks omvat de Pareto-curve van hun tests modellen van OpenAI, Anthropic en open source, wat wijst op een toekomst waarin bedrijven niet langer kiezen voor “het beste model” zonder context, maar verschillende trajecten volgen op basis van kosten, complexiteit en taaktype.
De benchmark die bedrijven zelf zouden moeten ontwikkelen
Databricks legt uit dat publieke benchmarks zoals SWE-bench of TerminalBench nuttig zijn, maar niet alle interne vragen beantwoorden. De reden is simpel: openbare datasets kunnen in de loop van de tijd geleidelijk aan in het trainingsdata worden opgenomen en weerspiegelen niet altijd de realiteit van een specifiek zakelijk codebase. Daarom bouwde het bedrijf hun evaluatie op basis van daadwerkelijke, recente en gecontroleerde pull requests, met kwaliteitscontroles en wijzigingen binnen gerichte modules.
Deze aanpak maakt een groot verschil. Een publieke benchmark meet algemene capaciteit. Een interne benchmark evalueert of een agent daadwerkelijk helpt bij het oplossen van problemen binnen een organisatie, rekening houdend met haar patronen, frameworks, conventies, build-systemen en geschiedenis.
Databricks filterde veranderingen die door bots, service-accounts, volledig door AI gegenereerde commits en automatisch gegenereerde code waren gemaakt. Vervolgens maakten ze van de geselecteerde pull requests taken: ze summariseerden de bedoeling, verwijderden aanwijzingen over de oplossing, scheidden de tests van de rest en beoordeelden of de agent in staat was om een correcte implementatie te reproduceren. Het bedrijf vermeed het gebruik van een LLM-jury om te beslissen of de antwoorden geldig waren, omdat ze menen dat zo’n aanpak kan belonen dat antwoorden overtuigend zijn, ook al zijn ze niet correct.
Een ander belangrijk technisch detail was het voorkomen van interne datalekken. Bij de eerste experimenten ontdekte Databricks dat sommige oplossingen ‘te goed’ leken omdat de agent de juiste implementatie kon terugvinden in de Git-geschiedenis. Om dit te corrigeren, blokkeerden ze de geschiedenis tijdens de uitvoering van elke taak, zodat de agent niet kon terugkijken naar eerdere commits om de oplossing te vinden.
Dit maakt het experiment een waardevolle indicator voor elk engineeringteam: veel organisaties hebben al zo’n benchmark in huis, zonder het te weten. Het zit verborgen in gesloten PR’s, tests, opgeloste incidenten en revisies door mensen.
Het model is belangrijk, maar het harness is bijna even cruciaal
Het meest technische inzicht uit de studie ligt in de scheiding tussen model en harness. In een programmeer- agent is het model verantwoordelijk voor redeneren, voorstellen doen en code schrijven. Het harness is de laag die het mogelijk maakt te opereren: bestanden zoeken, commando’s uitvoeren, output lezen, context managen, bepalen welke informatie in elk gesprek wordt verzonden en de taak onder controle houden.
De industrie vergelijkt modellen vaak alsof ze geïsoleerd functioneren. Dat is onvoldoende. Databricks toont dat hetzelfde model met dezelfde redeneerinspanning, uitgevoerd via twee verschillende harnesses, de kosten per taak met factor 2 of meer kan laten variëren, terwijl de kwaliteit gelijk blijft. De voornaamste oorzaak is de hoeveelheid context die elk harness naar het model terugstuurt in elk beurt.
Pi, het interne harness dat in de analyse uit de verf kwam, stuurde ongeveer drie keer minder context per beurt. Volgens Databricks beheerde het beter de workload, hield het een smallere venster en voltooide het taken in minder pogingen.
Dit verandert de discussie over kosten. Het is niet genoeg om alleen naar de prijs per miljoen tokens te kijken. Als een agent te veel leest, onnodig context doorstuurt, te vaak moet herhalen of de focus verliest, kan het toch duurder uitvallen, zelfs als het model een lagere prijs per token heeft.
| Onderdeel | Beslist in een code-agentsysteem |
|---|---|
| Model | Redenering, codegeneratie, instructiebegrip |
| Harness | Verzonden context, beschikbare tools, commando’s, bestandslezing |
| Tests | Werkelijke verificatie van de oplossing |
| Routing | Keuze van model op basis van moeilijkheid en kosten |
| Interne pipeline | Veiligheid, tracering, permissies, herhaalbaarheid |
De misleidende kosten per token
Databricks illustreert dat de prijs per token niet het hele verhaal vertelt. Zo was Sonnet 5 ongeveer 1,7 keer goedkoper per token dan Opus 4.8, maar kostte het uiteindelijk meer per taak: 2,09 dollar versus 1,94 dollar, met een lagere afrondingspercentage (81% versus 87%). De reden was dat Sonnet 5 ongeveer 1,9 keer meer tokens nodig had om tot een resultaat te komen.
De belangrijke metriek is dus niet de prijs per token, maar de totale kosten om een geldige taak op te lossen. In code-agentsystemen omvat dit tokens voor input, output, reasoning, toolcalls, retries, runtime, contextlezing en eventuele fouten.
Dit nuanceverschil wordt steeds relevanter voor bedrijven die overstappen van het testen van copilots naar het operationeel inzetten van agents op grote schaal. Een schijnbaar lagere prijs per token kan overschaduwd worden door extra tokens, herhalingen of onnodige context die het proces duurder maken.
GLM 5.2 en de nieuwe rol van open source
GLM 5.2 verschijnt niet in dit benchmark als een curiositeit met lage kosten, maar als een volwaardige optie die concurreert op hoogwaardig niveau binnen een echte omgeving. Z.ai presenteert GLM 5.2 als een open source-model met MIT-licentie, gericht op lange-termijn taken, wat de aantrekkelijkheid voor bedrijven die open modellen naast gesloten alternatieven willen gebruiken versterkt.
Dat betekent niet dat alle teams het gratis kunnen downloaden en draaien zonder operationele kosten. Grotere open source-modellen vereisen infrastructuur, GPU’s, geheugen, inference-engineering, beveiliging, monitoring en operationeel beheer. Maar het schept wel een strategisch evenwicht: een organisatie kan open modellen inzetten voor bepaalde routing, open source combineren met gesloten modellen en alles evalueren op basis van eigen resultaten.
De zakelijke conclusie is helder. Eén enkele leverancier wordt minder relevant wanneer kwaliteit, kosten en efficiëntie afhankelijk worden van taak, model en harness. Een volwassen AI-ontwikkelarchitectuur moet het mogelijk maken om modellen te testen, te routeren en te vervangen zonder de hele workflow te herstructureren.
Databricks wijst in die richting door te vermelden dat ze werken aan geavanceerde routing in Unity AI Gateway en Omnigent om ontwikkelaars te ondersteunen bij het kiezen van de meest geschikte agent, met behoud van efficiëntie en controle.
Wat engineers van deze studie kunnen leren
De studie van Databricks biedt enkele praktische lessen. Ten eerste dat publieke benchmarks slechts het beginpunt zijn. Ze helpen de markt te verkennen, maar de daadwerkelijke beslissing moet gebaseerd zijn op je eigen taken, testprocedures en metrics.
Ten tweede dat de volledige agent de evaluatie-eenheid is. Model, harness, tools, permissies, context, tests en reviewflows vormen samen een systeem. Alleen modellen vergelijken kan leiden tot verkeerde beslissingen.
Ten derde dat routing een centrale rol zal spelen. Niet elke taak vereist het duurste model. Databricks ontdekte dat ongeveer een kwart van de taken van lage complexiteit was, en ongeveer 60% van gemiddelde complexiteit, hoewel dure modellen vaak standaard werden gebruikt.
Ten vierde dat open source niet langer buiten beschouwing kan blijven. Als een open source-model vergelijkbare kwaliteit biedt tegen lagere kosten per taak, moet het minstens geëvalueerd worden. Het wint niet altijd, maar het negeren wordt moeilijker te rechtvaardigen.
AI-ondersteunde engineering bevindt zich zo in een meer volwassen fase. Het is niet meer voldoende om te vragen welk model het beste code schrijft in een demo. Men moet meten welk agent daadwerkelijk betere resultaten oplevert, hoeveel het kost, hoeveel toezicht nodig is, welke risico’s het introduceert en hoe het past binnen de ontwikkelarchitectuur van de organisatie.
De toekomst van code-agents wordt niet alleen bepaald door het krachtigste model. Het hangt af van wie modellen, harnesses, tests en routing slim combineert met organisatie-specifieke data. Databricks heeft laten zien dat een serieuze aanpak mogelijk is.
Veelgestelde vragen
Waar heeft Databricks precies naar gekeken?
Ze hebben agents geëvalueerd op echte taken die voortkomen uit interne pull requests, met vaststelling of de oplossing werkte via eigen tests en code review.
Waarom is GLM 5.2 belangrijk in deze benchmark?
Omdat het in de hoge capaciteitsgroep staat, statistisch gelijkwaardig is met Opus 4.8 in kwaliteit, maar met een lagere cost per task in de test van Databricks.
Wat is een harness in code-agents?
Het is de laag die tools, context, bestandsbeheer, terminalcommando’s, tests en de interactie tussen het model en de repository beheert.
Waarom is de prijs per token niet allesbepalend?
Omdat een goedkoper model per token veel tokens kan gebruiken of meer iteraties nodig kan hebben. De belangrijkste maatstaf is de totale kost van het correct voltooide werk.
Moeten organisaties zelf benchmarks maken?
Ja, vooral als ze op grote schaal met code-agents werken. Historische PR’s, tests en daadwerkelijke wijzigingen geven een veel beter beeld van prestaties dan generieke benchmarks.