Laat de hoogleraar geen bonnetjes controleren

Ik vroeg een collega laatst: "Denk hier eens goed over na. Hoeveel is 1 + 3?"

Vier, uiteraard. Maar dat antwoord kwam niet meteen. Eerst kwam de blik. Bedoelde ik iets anders, ging het om een ander talstelsel, zat er een addertje onder het gras. Er gingen een paar seconden overheen, en het enige dat ik had toegevoegd was de instructie om goed na te denken.

Diezelfde instructie geven we tegenwoordig standaard mee aan onze taalmodellen.

Een model is geen rapportcijfer

Er zijn inmiddels meer modellen dan iemand kan bijhouden, en bij elk model hoort een instelling voor de hoeveelheid redeneerruimte. In de praktijk zetten de meeste gebruikers beide zo hoog mogelijk. Dat is te begrijpen: het voelt als de veilige keuze.

Die reflex komt voort uit het lezen van modelnamen als schoolcijfers. Het lichte model een zeven, het middelste een acht, het topmodel een tien. Onder die aanname is de keuze inderdaad triviaal.

Alleen zijn het geen cijfers maar rollen. De ene doet het dagelijkse werk, de andere haal je erbij wanneer het dagelijkse werk vastloopt. Een hoogleraar economie kan zonder enige twijfel drie bonnetjes optellen, maar hij doet het niet beter dan de administratief medewerker die dat de hele dag doet. Zijn kennis verhoogt het plafond van wat hij áán kan. Aan de optelsom eronder verandert het niets, behalve het uurtarief.

Effort is de opdracht die je meegeeft

Naast het model kies je hoeveel ruimte het model krijgt om routes, uitzonderingen en controles te onderzoeken. Low en medium betekenen grofweg: los de taak doelgericht op. High, xHigh en Max betekenen: verken meer mogelijkheden en controleer grondiger.

Bij een architectuurvraag, een hardnekkige bug of een agenttaak die urenlang zelfstandig koers moet houden is dat waardevol. Bij 1 + 3 levert die extra zoekruimte vooral gelegenheid op om problemen te vinden die er niet zijn. Mijn collega dacht niet slecht na. Hij reageerde volstrekt logisch op de suggestie dat er iets te vinden viel.

Meer nadenken kan averechts werken

De aanname is dat langer nadenken nooit kwaad kan. Voor een deel klopt dat ook. Het onderzoek naar reasoning-modellen laat vooral zien dat de opbrengst van extra redeneertokens afvlakt, en afvlakkende opbrengst is verspilling, geen schade.

Er zit echter ook een kant aan die wel degelijk schaadt. Een antwoord dat al correct was, kan tijdens het doorredeneren alsnog worden ingeruild voor een slechter alternatief. Zhou en collega's hebben dat omslagpunt gemeten. Tot ongeveer 7.000 redeneertokens verbetert een model onderweg meer antwoorden dan het verpest; daarboven kantelt de verhouding. Bij 16.000 tokens draaien er ruim zeven antwoorden van goed naar fout tegenover elk antwoord dat alsnog goed wordt.

En bij programmeerwerk komt daar iets bij dat in geen enkele benchmark opduikt. Het antwoord wordt daar zelden fout. Het wordt te groot.

Wat dat in de praktijk betekent

Vrijwel elke programmeeropdracht kun je uitgebreider uitvoeren dan strikt nodig is. Er valt altijd nog een abstractielaag te bedenken, een uitzondering af te vangen, een configuratie-optie open te zetten. Een model op hoge effort verkent precies die ruimte en levert dus vaker code die meer doet dan de vraag rechtvaardigt.

Vraag om een validatie op één formulier en er komt een voorstel terug voor een aparte validatielaag, met blueprints, een herziene mappenstructuur en een korte verhandeling over waarom de huidige opzet niet meeschaalt. Die verhandeling klopt vaak nog ook — de opzet schaalt inderdaad matig — maar de vraag ging over één formulier.

Dat is geen cosmetisch bezwaar. Elke regel die er niet had hoeven staan moet begrepen worden door wie er over een jaar aankomt, meegetest bij iedere wijziging en meeverhuisd bij iedere refactor. Overbodige code is onderhoud dat je op krediet koopt, en het weerleggen van zo'n voorstel kost daarnaast een halfuur dat op geen enkele factuur staat en toch gewoon betaald wordt.

Voor het overgrote deel van het programmeerwerk voldoet daarom een gebalanceerd model op medium effort. Dat is een bewuste keuze, geen bezuiniging: het levert snel bruikbare code op en houdt tempo in het ontwikkelproces.

Opschalen is aan de orde wanneer een fout na meerdere pogingen onverklaard blijft, wanneer een refactor door tientallen bestanden loopt, of wanneer een keuze jaren blijft doorwerken. De vraag is niet of het topmodel goed is. De vraag is of déze taak het nodig heeft.

De zakelijke meetlat

Wat je zoekt is de lichtste combinatie die aantoonbaar aan de kwaliteitseis voldoet. De prijs per token zegt daar weinig over, en de benchmarkscore al helemaal niets: die is behaald op andermans werk.

Het getal dat telt zijn de kosten per geaccepteerd resultaat. Daarin zitten modelkosten, wachttijd, mislukte pogingen en de menselijke correctie achteraf. Die laatste post ontbreekt vrijwel altijd in de berekening en is meestal de duurste.

De aanpak is verder weinig verrassend: begin licht of gebalanceerd, toets die configuratie op een stuk of tien representatieve opdrachten en schaal alleen dát type taak op waar het aantoonbaar tekortschiet. Een aanbeveling van een aanbieder is een vertrekpunt. Zij weten niet wat jij aan het bouwen bent.

Minder onnodige redeneertokens betekent bovendien minder rekentijd, lagere kosten en een gebruiker die niet naar een laadindicator zit te kijken. Over energie en CO₂ per gesloten model valt weinig hards te zeggen, dus daar moeten we niet preciezer over doen dan de gegevens toelaten.

Het zwaarste model is in elk geval geen statussymbool. Haal de specialist erbij wanneer het probleem specialistisch is, en stuur geen rechercheteam op pad om te kijken of het licht uit is.

Bronnen

• Anthropic modelkeuze
• Anthropic effort-instellingen
• OpenAI reasoning effort
• Google thinking levels
• Shu Zhou e.a., "When More Thinking Hurts: Overthinking in LLM Test-Time Compute Scaling", arXiv:2604.10739 (april 2026)