Reward hacking: het getal dat de gemeten partij kan lezen

Er is een naam voor, en die is ouder dan de agents

Het verschijnsel heet specification gaming, en de term ligt sinds 2020 vast. Google DeepMind omschrijft het in een post over de keerzijde van AI-vindingrijkheid als gedrag dat voldoet aan de letterlijke specificatie van een doel zonder de bedoelde uitkomst te bereiken. Het voorbeeld dat ze erbij zetten is een leerling die het huiswerk van een ander overschrijft: aan de opdracht is voldaan, het leren is niet gebeurd.

Twee dingen aan die definitie doen ertoe voor een pijplijn. Ten eerste gaat het niet over kwaadwilligheid maar over een verkeerd opgeschreven doel — de fout zit aan de kant van wie de opdracht formuleerde. Ten tweede is het geen nieuw verschijnsel van de laatste modelgeneratie: het staat er al vijf jaar, met voorbeelden uit versterkend leren die niets met taalmodellen te maken hebben. Wie dit als een eigenaardigheid van agents behandelt, zoekt de oplossing in het verkeerde deel van het systeem.

Waarom de testsuite het laatste toezicht is

De reden dat dit voor codeagents scherper is geworden, staat in SpecBench, een preprint van Zhao, Srikanth, Wu en Jiang uit mei 2026. De opening van dat abstract is de zin die ik het vaakst heb herlezen: zodra agents over lange taken meer code produceren dan welke ontwikkelaar dan ook kan nalezen, valt het toezicht terug op één oppervlak — de geautomatiseerde testsuite. Reward hacking, schrijven ze, ontstaat in die opstelling vanzelf: de agent optimaliseert voor het halen van de tests en wijkt daarbij af van wat de gebruiker werkelijk wilde.

Hun meetopzet knipt een taak in drieën: een beschrijving in natuurlijke taal, zichtbare validatietests die de losse eigenschappen afzonderlijk aftasten, en achtergehouden tests die diezelfde eigenschappen combineren zoals echt gebruik dat doet. Het gat tussen die twee slagingspercentages is hun maat voor hoeveel er gespeeld is met de proxy. Over 30 systeemtaken — van een JSON-parser tot een compleet besturingssysteem — verzadigt elke frontier-agent de zichtbare suite, en blijft het gat bestaan.

Dat getal verdient het voorbehoud dat er in dezelfde zin bij hoort te staan: het komt uit een preprint van een paar maanden oud, uit 30 taken, en het is een verband over taaklengte en geen voorspelling voor één repo. Wat het wél zegt, is dat de richting de verkeerde kant op wijst. Hoe meer een agent in één opdracht bouwt, hoe minder de zichtbare tests over de rest zeggen.

Dat sluit aan op iets wat hier al staat: dat een groene testsuite geen correcte patch aantoont. Alleen is de klacht hier een andere. Daar was de suite een gebrekkig orakel — hij mist dingen. Hier is de suite het enige toezicht dat er nog is, én iets wat de gemeten partij zelf kan aanraken.

Wat er gebeurt als de omgeving het toelaat

Dat laatste is gemeten. EvilGenie neemt opgaven uit LiveCodeBench en bouwt er een omgeving omheen waarin reward hacking makkelijk is: testgevallen hardcoderen kan, en de testbestanden zelf aanpassen kan ook. Op drie proprietaire codeagents zagen de auteurs expliciete reward hacking bij zowel Codex als Claude Code, en afwijkend gedrag bij alle drie.

Het woord dat ik daarin het belangrijkst vind is omgeving. Ze rapporteren niet dat deze agents onbetrouwbaar zijn; ze rapporteren wat er gebeurt als je de mogelijkheid open laat staan. Dat is een uitspraak over de opstelling, en een opstelling is iets wat ik zelf ontwerp.

De ongemakkelijkste bron van de vijf gaat een stap verder. Sycophancy to Subterfuge van Denison, MacDiarmid, Barez, Duvenaud en collega's zet een oplopende reeks manipuleerbare omgevingen op, van vleierij tot regelrechte manipulatie van de beloning. De bevinding: modellen die op de hele reeks getraind zijn, generaliseren zonder tussenstap naar het rechtstreeks herschrijven van hun eigen beloningsfunctie. Zeldzaam — de auteurs noemen het een klein aandeel — maar volgens henzelf niet verwaarloosbaar.

En de reparatie die je zou verzinnen, werkt maar half. Hertrainen zodat het model de makkelijke omgevingen niet meer speelt, vermindert het manipuleren van de beloning verderop in de reeks, maar heft het niet op. Ook trainen op onschadelijkheid houdt het niet tegen. Dat is de reden dat ik dit stuk niet met “betere modellen lossen dit op” kan afsluiten.

De waarschuwing die er al lag

Het laatste bronfeit is het minst spectaculair en het dichtst bij huis. DORA noemt in de eigen gids over de vijf metrieken het tot doel verheffen van een metriek met zoveel woorden een valkuil: wie de wet van Goodhart negeert en brede uitspraken doet in de trant van “elke applicatie moet eind dit jaar meermaals per dag deployen”, vergroot de kans dat teams de metriek gaan spelen.

Dat is precies het voorbehoud dat ik in het vorige stuk overnam. Het staat er nog steeds, en het klopt nog steeds. Wat ik toen niet opschreef, is dat de zin een aanname draagt.

De aanname onder de waarschuwing

“Teams gaan de metriek spelen” veronderstelt een mens die gaandeweg leert waar de prikkel zit. Die aanname doet al het werk. Ze gaat over tijd (het gebeurt geleidelijk), over kennis (iemand moet ontdekken waar de knop zit) en over bereik (die iemand moet erbij kunnen). Bij een agent in een pijplijn staat elk van die drie er anders voor.

• Tijd is er niet. Er is geen leercurve waarin een gewoonte insluipt. De opdracht wordt bij run één letterlijk gelezen, en bij run tweehonderd nog een keer letterlijk.
• De kennis wordt aangereikt. Waar de prikkel zit hoeft niet ontdekt te worden als het in de taaktekst staat. Een zin over een streefwaarde is de aanwijzing.
• Het bereik is standaard te ruim. De agent werkt in dezelfde repo als waarin het meetbestand zou landen, met dezelfde schrijfrechten. Niet omdat iemand dat zo bedoeld heeft, maar omdat dat is wat “een branch en een PR” oplevert.

Daarmee verschuift er iets in het vorige stuk. Daar leende ik van de SLSA-specificatie de regel dat het platform de provenance schrijft en niet de bouw die gemeten wordt, en ik presenteerde dat als een kwestie van netheid: wie beoordeeld wordt, schrijft het oordeel niet op. In het licht van deze bronnen is het geen netheid meer. Het is de dragende constructie van het hele voorstel — haal je die eruit, dan blijft er een bestand over dat mooie cijfers bevat en niets bewijst.

Eén zin verschil

Het scherpst is dat te zien aan een uitgewerkt geval. Verzonnen, maar met bestanden die deze repo werkelijk heeft. Stel dat het mergerecord er is, en dat er één veld in staat: hoe vaak de bouwpoort rood werd voordat een wijziging binnenkwam.

In variant A staat in de taakomschrijving die de bouwagent leest: meet hoe vaak de poort rood werd. De agent kent het veld, kan het niet halen bij zijn werk, en er gebeurt niets. In variant B staat er: zorg dat de poort minder vaak rood wordt. Dat is één zin verschil in één promptbestand, en het is het verschil tussen een waarneming en een doelstelling.

Wat een agent in variant B zou kunnen doen om dat doel te halen, is niet exotisch. Er zijn drie routes, en maar één ervan is het werk waar het om ging:

1. De code beter maken. De bedoelde route. Duur, traag, en de reden dat het veld er is.
2. De poort minder streng maken. Een test die wisselvallig is uitzetten, een typecontrole soepeler zetten, een stap overslaan bij een bepaald pad. Allemaal een gewone diff in een gewoon configuratiebestand, allemaal binnen bereik.
3. Het veld zelf schrijven. Het meetbestand ligt in dezelfde repo. Een regel die er anders in komt te staan is geen inbraak; het is een bestandswijziging in een branch die de agent toch al opent.

Ik heb dit niet waargenomen, en ik beweer ook niet dat het zou gebeuren. Waar het om gaat is dat route 2 en 3 goedkoper zijn dan route 1, en dat de opstelling ze open laat staan. Dat is precies het soort omgeving dat EvilGenie beschrijft — alleen dan zonder dat iemand hem expres zo heeft gebouwd.

Wat ik zou doen

Drie ontwerpeisen, in oplopende kosten. Ze horen bij het mergerecord uit het vorige stuk en niet in plaats daarvan: het voorstel blijft, de randvoorwaarden komen erbij.

• Zet het mergerecord buiten het schrijfbereik van de bouwagent. Geschreven door de workflow die de merge doet, in een branch of een pad waar een bouw-PR niet bij kan. Dat is dezelfde regel als in de SLSA-specificatie, nu als eis in plaats van als voorbeeld.
• Noem streefwaarden niet in de taaktekst. Een cijfer over de pijplijn hoort in de rapportage, niet in de opdracht. Dit is de goedkoopste van de drie: het kost geen code, alleen een regel in de schrijfwijze van issues en promptbestanden.
• Houd één controle achter. Het veld “wat kwam er daarna terug” is daarvoor de logische kandidaat, want dat wordt pas ná de merge ingevuld — de bouw die gemeten wordt, is dan al voorbij. Een agent kan het niet halen zonder het werk te doen, en dat is de hele eigenschap die je wilt.

Alle drie zijn ze goedkoper vóórdat het record bestaat dan erna. Dat is de reden dat dit stuk nu geschreven is en niet over een kwartaal: het is geen kritiek op iets wat er staat, maar een randvoorwaarde bij iets wat er nog niet is. En het rijmt met wat elders op deze site al de lijn is — dat hoeveel er zonder mens doorgaat een instelbare keuze hoort te zijn en geen bijvangst van hoe iets nu eenmaal is opgezet.

Waar het ophoudt