Je wisselt op dinsdag van model. Op vrijdag zit er iets niet lekker.
De diffs zijn langer. De agent had twee pogingen nodig waar er eerst één genoeg was. Er komt een functie terug die jij nooit zo had opgeschreven. Er is niets kapot, maar het blijft opvallen.
Dus stel je de voor de hand liggende vraag. Is het model slechter geworden?
En dan merk je dat je geen enkele manier hebt om die vraag te beantwoorden.
Het best gedocumenteerde geval is er één waarin het model niet veranderde
In augustus 2025 begonnen mensen te melden dat Claude achteruit was gegaan. De meldingen waren vaag, spraken elkaar tegen, en waren makkelijk weg te wuiven als het effect dat altijd optreedt zodra mensen aan een tool gewend raken.
Ze hadden gelijk. De postmortem van Anthropic legde drie losse infrastructuurbugs bloot die tegelijkertijd speelden.
Een routeringsfout rond het contextvenster stuurde verzoeken naar het verkeerde servertype. De bug ontstond op 5 augustus en raakte toen 0,8% van de Sonnet 4-verzoeken. Een wijziging in de load balancing maakte hem op 29 augustus erger, en op 31 augustus zat hij op 16% van de Sonnet 4-verzoeken. Ongeveer 30% van de Claude Code-gebruikers kreeg in die periode minstens één bericht dat verkeerd werd gerouteerd.
Een verkeerd geconfigureerde TPU-server verminkte tussen 25 augustus en 2 september de output, en strooide af en toe Thaise tekens door Engelse antwoorden.
Een miscompilatie van approximate top-k in XLA:TPU, een precisieprobleem tussen bf16 en fp32, raakte Haiku 3.5 ruim twee weken lang.
Drie bugs, over elkaar heen, op drie hardwareplatformen. Aan de gewichten is nooit iets veranderd.
Twee dingen in die postmortem zijn zorgwekkender dan de bugs zelf.
De eigen evaluaties van Anthropic sloegen geen alarm. De reden die ze geven: "Claude often recovers well from isolated mistakes". De schade viel daardoor weg in de totalen, terwijl losse sessies zichtbaar slechter waren.
En de bugs die over elkaar heen liepen leverden "confusing and contradictory reports" op. Voor de mensen die de telemetrie voor zich hadden, leken drie echte problemen die tegelijk binnenkwamen op ruis.
Als de leverancier er een maand en bevoorrechte toegang voor nodig had om te achterhalen wat jij voelde, dan kom jij daar op gevoel alleen nooit achter.
"Het model is slechter geworden" zijn drie verschillende beweringen
Haal ze uit elkaar, want ze vragen om ander gereedschap:
- De gewichten zijn veranderd. Er is een nieuwe versie uitgerold, of een oude is teruggetrokken onder een naam waarvan jij dacht dat hij vastlag.
- De serverkant is veranderd. Dezelfde gewichten, andere routering, precisie of hardware. Dit is wat er bij Anthropic gebeurde, en van buitenaf zie je er niets van.
- Jij bent veranderd. Andere codebase, zwaardere taken, meer vertrouwen, minder lezen. Dat gebeurt echt, en niemand wil dat het het antwoord is.
In de meeste discussies over modelkwaliteit heeft de een een andere bewering in gedachten dan de ander, zonder dat iemand het doorheeft.
De prompt opnieuw draaien bewijst niets
De reflex is om dezelfde prompt tegen beide modellen aan te gooien en de uitkomsten te vergelijken.
Dat werkt niet, en de reden is interessanter dan "LLM's doen maar wat".
Thinking Machines Lab draaide 1.000 completions van Qwen3-235B op temperatuur 0. Daar kwamen 80 verschillende uitkomsten uit. De eerste 102 tokens waren in elke run identiek. Pas bij token 103 liepen ze uiteen.
Bij die eerste splitsing was de verdeling scheef: 992 runs gingen de ene kant op, 8 de andere. Duizend tokens verder kwam de meest voorkomende uitkomst nog maar 78 keer voor. Eén zeldzaam token aan het begin sleept de rest van de generatie mee, en daarom is een verschil dat bij token 103 niets voorstelt aan het eind een ander antwoord.
De gangbare verklaring is concurrency plus floating point: threads zijn in willekeurige volgorde klaar, atomic adds tellen net anders op. Die verklaring klopt niet, en ze laten dat zien door dezelfde matrixvermenigvuldiging duizend keer te draaien en elke keer bit voor bit hetzelfde resultaat te krijgen.
De echte oorzaak is dat de kernels niet batch-invariant zijn. RMSNorm, matrixvermenigvuldiging en attention rekenen alle drie net iets anders, afhankelijk van hoeveel verzoeken er in de batch zitten. En de server stelt zijn batches samen op basis van belasting.
Wat jouw output verschoof, was hoeveel wildvreemden op dat moment dezelfde API aanriepen.
Met batch-invariante kernels leverden 1.000 runs 1.000 identieke uitkomsten op, tegen ongeveer 1,6 keer de looptijd.
Hier is precisie op zijn plaats, want dit wordt in beide richtingen verkeerd geciteerd. Anthropic zegt met zoveel woorden dat ze "never reduce model quality due to demand, time of day, or server load". Dat gaat over beleid, en dat is prima te rijmen met alles hierboven. Niemand knijpt jouw sessie af.
Wat wel schuift, is de rekenkunde onder dat beleid. De bytes die je terugkrijgt verschillen nog steeds tussen twee runs van dezelfde prompt op hetzelfde model, en wat ze verschoof zit buiten je eigen machine en komt in geen enkel logbestand terecht dat jij kunt inzien.
Temperatuur 0 is geen gecontroleerde variabele. Je kunt twee losse runs niet vergelijken. Je kunt één run niet eens betrouwbaar met zichzelf vergelijken.
Een model vragen welke output beter is
Tweede reflex: leg beide uitkomsten voor aan een jurymodel en vraag welke beter is. Goedkoop, snel, en het faalt precies bij deze vraag.
Judging the Judges onderzoekt 15 jurymodellen op MTBench en DevBench, 22 taken, zo'n 40 modellen die de oplossingen schreven en ruim 150.000 beoordelingen. Positiebias "is not due to random chance and varies significantly across judges and tasks". Verwissel welk antwoord A is en welk B, en het oordeel schuift mee.
De bevinding die hier telt is de tweede. Positiebias hangt "strongly" samen met het kwaliteitsverschil tussen de oplossingen, en de positieconsistentie zakt zodra de twee antwoorden dicht bij elkaar liggen.
Leg dat naast wat je feitelijk aan het doen bent. Twee versies van een frontier-model vergelijken op je eigen taken is per definitie een vergelijking waarbij het verschil klein is. Precies in dat gebied is de jury het minst betrouwbaar, en in het gebied waarin je het nooit had hoeven vragen heeft hij altijd gelijk.
Ter verdediging van jurymodellen wordt meestal een cijfer aangevoerd: ze zijn het in zo'n 80% van de gevallen eens met mensen, ongeveer evenveel als twee mensen onderling. Het grootste onderzoek naar jury's tot nu toe laat zien dat dat cijfer deels een artefact is van hoe het gemeten wordt. Het verscheen in juni 2026 en beslaat 21 jurymodellen van negen aanbieders, 118 runs en zo'n 541.000 losse beoordelingen, inclusief de frontier van april 2026. Exact-match agreement, de maat achter die 80%, "does not correct for chance and systematically overstates discriminative ability", en corrigeren voor toeval kost op MT-Bench 33 tot 41 procentpunt.
Het resultaat waar je echt iets mee moet, noemen de auteurs een consistency-bias-paradox. Twee jury's die in productie draaien, combineren een test-hertestbetrouwbaarheid boven de 0,95 met een positiebias boven de 0,10. Stel er tien keer dezelfde vraag aan en je krijgt tien keer hetzelfde antwoord, terwijl dat antwoord nog steeds meebeweegt met welke kandidaat je als eerste noemde. Herhaalbaarheid is precies de eigenschap die je zou nakijken om jezelf ervan te overtuigen dat een jury deugt, en het is de enige eigenschap die dit niet kan betrappen.
Jurymodellen hebben bovendien een voorkeur voor hun eigen familie en voor tekst die op hun eigen training lijkt. Van de twee dingen die jij vergelijkt is er meestal één een familielid van de jury.
Het gereedschap deugt, de steekproef is te klein
Complexiteit, clone-detectie en fitness functions voor je architectuur meten wel degelijk iets. Wat ze beschrijven is een hoeveelheid code.
Over één pull request kunnen ze niets zeggen. Cyclomatische complexiteit op een losse diff is een getal zonder foutmarge. Het wordt pas bewijs als je drie maanden gemergede code bij elkaar optelt, en dat is precies de les die churn al gaf: kijk naar het verloop.
Goed gereedschap, verkeerd moment. Op de vrijdag dat jij argwaan kreeg, hebben ze niets te melden.
Wat wel werkt
Stop met het model meten. Meet de uitkomst, op een vaste verzameling taken, met een beoordelaar die geen smaak heeft.
- Een bevroren takenset. Twintig tot vijftig taken uit de geschiedenis van je eigen repo, met de diffs die eruit kwamen. Jouw problemen, met jouw eigen rommel eromheen.
- Een beoordelaar die geen mening kan hebben. Compileert het. Blijven de bestaande tests groen. Houdt de mutatiescore stand. Geldt de dependency-regel nog. Stuk voor stuk een ja/nee of een getal dat door geen enkel taalmodel is bedacht.
- Genoeg runs om de ruis weg te middelen. Met 80 verschillende uitkomsten op 1.000 is één run per taak een anekdote. Vijf per taak per model is het punt waarop het iets gaat betekenen.
- Een nulmeting van vóór de wissel. Het enige onderdeel dat je achteraf niet meer kunt reconstrueren, en het onderdeel dat iedereen overslaat.
Dat is een kleine, saaie meetopstelling. Hij kost ook echt geld: vijftig taken, vijf runs en twee modellen zijn samen vijfhonderd agent-sessies voordat iemand ook maar één uitkomst leest, wat meteen een argument is om het goedkoopste model te pakken dat de klus aankan.
De governance-literatuur van 2026 komt vanaf de andere kant op hetzelfde punt uit, door een model-update te behandelen als wat het werkelijk is: een dependency-bump waar niemand toestemming voor heeft gegeven. "Test Before You Deploy" noemt het een supply-chainprobleem, en betoogt dat regressietests en het vastzetten van een versie je op zichzelf niets in handen geven zolang het model ondoorzichtig blijft veranderen. Het voorstel is een contract voor hoe het model zich mag gedragen, een testsuite die is ingedeeld naar risico in plaats van naar functionaliteit, en poorten die een update tegenhouden tot hij daar doorheen komt.
De verkennende bevinding is dezelfde die Anthropic van de andere kant tegenkwam: gericht testen op specifieke risicogebieden "can uncover performance regressions that overall metrics miss". En het open probleem dat ze noemen, hoe je betrouwbare drempelwaarden vaststelt in een niet-deterministisch systeem, is dit hele artikel in één zin.
Bouw het terwijl je nog rustig bent
Op onderbuikgevoel varen is de norm in de branche, en ik snap ook wel waarom. De meetopstelling kost een weekend, het model schuift over zes weken alweer op, en de eerlijke opbrengst van de hele exercitie is meestal "geen meetbaar verschil".
Het alternatief is de positie waarin iedereen in augustus 2025 zat. Een echte achteruitgang, een sterk gevoel daarover, en geen manier om dat gevoel te scheiden van het simpele feit dat je aan de tool gewend was geraakt.
Bouw die meetopstelling dus voordat je hem nodig hebt. Tegen de tijd dat je hem nodig hebt ben je al achterdochtig, en een achterdochtige engineer die ongelabelde diffs zit te lezen vindt precies wat hij zocht. Als laboratorium stellen een bevroren takenlijst en een domme beoordelaar weinig voor. Ze zijn wel genoeg om "dit voelt slechter" om te zetten in een getal, en een getal is de enige versie van die zin waar iemand tegenin kan gaan.