Voortdurende verbetering, ongemeten erosie: het gat tussen Harness-of-Harness en SlopCodeBench

Twee papers uit 2026 beschrijven samen hetzelfde probleem, maar trekken er tegenovergestelde conclusies uit. En het meest interessante gat zit precies tussen die twee.

Harness-of-Harness (HoH, Shanghai AI Lab, 1 september 2026) stelt een framework voor waarmee coding agents software over langere horizon autonom zouden kunnen blijven verbeteren. SlopCodeBench (SCBench, Wisconsin-Madison c.s., 25 maart 2026) meet wat er gebeurt als coding agents hun eigen code herhaaldelijk uitbreiden: die code erodeert, en pass-rate benchmarks zien dat niet.

En hier wordt het scherp: HoH citeert SCBench expliciet in de related work, als bewijs dat langhorizon-degradatie een erkend probleem is. Maar vervolgens past HoH geen van beide SCBench-kwaliteitsmetrieken toe op de eigen resultaten. De eindkwaliteit stijgt, de erosie wordt niet gemeten.

Dat gat is de kern van dit essay.

Evidence: twee papers, twee meetlacunes

Ik heb beide papers volledig aan de bron gelezen, inclusief de appendices. HoH is van 1 september 2026 (Shanghai AI Lab). SlopCodeBench is van 25 maart 2026 (Wisconsin-Madison c.s.); een v2 van 7 mei 2026 bestaat maar is hier niet gebruikt, omdat de analyse draait om de v1-meting.

HoH organiseert een vaste harness-model combinatie in een herhaalde planning-coding-testing loop: een Project Planner kiest de volgende begrensde increment, een Developer implementeert, en een QA Tester evalueert onafhankelijk. Op GameCraft-Bench, FrontierSWE en ProgramBench verslaat HoH drie keer de standalone harnesses, met een gemiddelde relatieve winst van 52,25% en een maximum van 82,86% na drie iteraties.

SCBench meet twee soorten kwaliteitserosie over 20 problemen en 93 checkpoints: structurele erosie (de concentratie van complexiteit in al-complexe functies) en verbosity (overbodige of gedupliceerde code). Geen enkel model lost een probleem volledig op; de hoogste checkpoint-solve rate is 17,2%. Erosie stijgt in 80% van de trajectorieën, verbosity in 89,8%.

Het verschil in ambitie is precies waar de spanning zit. SCBench meet of agents onder iteratie eroderen. HoH claimt dat een betere loop die erosie voorkomt. Maar HoH beantwoordt nooit de vraag die het zelf via SCBench als probleem heeft erkend: erodeert de software onder HoH? De enige kwaliteitsmeting is de eindscore op het benchmark-rubrics, en die is precies het type pass-rate meting waarvan SCBench bewijst dat het structurele erosie mist.

Falsification: vier zwakke plekken die HoH's claim ondermijnen

De dominantiescore van HoH is niet coherent over publicaties heen. Dezelfde configuratie, Codex met GPT-5.5 (high) op FrontierSWE, scoort in Tabel 1 een dominantie die stijgt van 44% (Vanilla) naar 71% (HoH@3). In Figuur 5 stijgt dezelfde configuratie van 27,33% (Vanilla) naar 39,33% (HoH@3). De reden is geen slordigheid, maar een verschil in vergelijkingspool. Tabel 1 berekent dominantie over een vaste pool van 12 systeem-conditie configuraties (drie systemen maal vier condities). Figuur 5 gebruikt een vaste pool van 11 checkpoints (Vanilla plus HoH@1 tot en met HoH@10) voor een enkele configuratie die doorgaat tot tien loops. Dezelfde configuratie presteert dus anders naargelang de pool. Dat maakt de dominancescore als bewijs voor de claim "HoH verbetert" lastig te interpreteren: hij is niet zonder context reproduceerbaar.

De "52,25% gemiddelde relatieve winst" aggregeert over onvergelijkbare schalen. GameCraft-Bench rapporteert een 0-100 kwaliteitsscore, FrontierSWE een domein-gemiddelde dominantie en reward, ProgramBench een gemiddelde test-pass rate. Deze drie hebben verschillende eenheden en verschillende spreiding. Een relatieve winst op de ene schaal is niet vergelijkbaar met een winst op de andere, en het middelen ervan tot één getal verwart samenvatten met meten.

De functiescheiding is niet wat hij lijkt. HoH instantieert de drie rollen (planner, developer, tester) als aparte invocaties van dezelfde vaste harness-model configuratie. De QA Tester deelt dus de gewichten met de Developer. Dat betekent dat de "onafhankelijke" acceptatie en de implementatie dezelfde modelfouten kunnen delen. Functiescheiding zonder een ongecorreleerd foutmodel geeft schijnbestuur: een tester die dezelfde blinde vlek heeft als de schrijver bevestigt vooral wat al aangenomen is. Dit is de klassieke zwakte die SCBench juist blootlegt: een testportaal dat door hetzelfde model is geproduceerd ziet dezelfde structurele erosie niet.

De GitHub-repo van HoH bevat vandaag geen reproduceerbare implementatie. De gelinkte repository biedt showcase-materiaal (README, gameplay-video, figuren) maar geen code waarop de beweerde verbetering zelf gedraaid of gecontroleerd kan worden. SCBench daarentegen is volledig publiek, met de complete benchmark, problemen, skills en evaluatie-infrastructuur. De asymmetrie is betekenisvol: het paper dat het probleem meet deelt alles; het paper dat de oplossing claimt deelt het bewijs niet.

Triangulatie: drie onafhankelijke lijnen naar hetzelfde punt

Drie onafhankelijke bevindingen wijzen naar dezelfde conclusie: foutafhandeling degradeert het eerst, erosie is onzichtbaar voor testpoorten maar zichtbaar in kosten, en regressie van geverifieerd gedrag is het dominante falen.

Ten eerste degradeert foutafhandeling het eerst onder SCBench. De paper deelt tests in naar type: core, error, functionality en regression. Naarmate checkpoints vorderen, neemt de error-handling pass rate het sterkst af, terwijl core en functionality relatief stabiel blijven. Dat is geen cosmetisch detail. Error-handling code is waar een agent randgevallen, ongeldige invoer en failure modes afhandelt, en dat is precies waar beveiligingsoppervlak ontstaat. De eerste code die erodeert is de code die de aanvaller raakt.

Ten tweede is erosie onzichtbaar voor testpoorten maar zichtbaar in kosten. SCBench meet de voorspellende correlatie van erosie met de pass rate van het volgende checkpoint (r = -0,003, vrijwel nul) en met de kosten van het volgende checkpoint (r = +0,127, positief). Met andere woorden: een opgeblazen, geerodeerde codebase kan net zo goed door de tests komen als een schone, maar kost de volgende iteratie structureel meer. Pass-rate benchmarks missen dit falen volledig, omdat testsuites structurele erosie niet kunnen zien. De kostenstijging is het zichtbare spoor van een onzichtbaar probleem.

Ten derde is HoH's eigen proces een levend voorbeeld van precies de regressie die SCBench meet. In de Fusepoint-case werd over 70 loops een first-person shooter ontwikkeld. Van de 81 geregistreerde issues waren er 65 gesloten en 16 open op Loop 70. Zeventien issues werden heropend nadat een latere wijziging eerder geverifieerd gedrag deed falen. Die zeventien heropende issues zijn letterlijk: geregresseerd geverifieerd gedrag. Het fenomeen dat SCBench meet, erosie die verborgen blijft tot het te laat is, treedt op binnen het framework dat claimt het op te lossen, en wordt alleen zichtbaar omdat HoH een issue-history bijhoudt. Zonder die history was het onzichtbaar geweest.

Alle drie de lijnen komen samen in één beeld. Het foutpadoppervlak van een iteratief gegroeide codebase is het beveiligingsoppervlak. Erosie begint daar, het is onzichtbaar voor de tests die de organisatie vertrouwt, en het wordt zichtbaar in kosten en regressies zodra het te laat is.

De bestuurlijke les: promptgestuurde AI-governance is geen beheersmaatregel

De scherpste bestuurlijke bevinding volgt uit SCBench' prompt-interventie-studie. In die studie krijgt een agent "anti-slop" en "plan-first" prompts om de kwaliteit te verbeteren. Het resultaat is genuanceerd en daarom verontrustend: de prompts verlagen de initiële erosie en verbosity aanzienlijk, anti-slop halveert de initiële verbosity, maar de degradatie-helling blijft identiek. Naarmate de agent zijn eigen code herhaaldelijk uitbreidt, hervat de erosie op exact dezelfde snelheid, ongeacht hoe schoon de start was. De prompts verlagen het beginpunt, niet de helling.

De statistische consequentie is helder. Promptgestuurde AI-governance, een prompt hier, een instructie daar, een "wees netjes" in de system prompt, verandert de initiële conditie, niet het cumulatieve gedrag. Het verandert de intercept, niet de slope. Dat betekent: een prompt is geen beheersmaatregel. Een beheersmaatregel is mechanisme dat de helling verandert, dat degradeert op structureel niveau, met tooling of training die cross-checkpoint discipline afdwingt. SCBench' meting laat zien hoe een organisatie de twee kan onderscheiden: meet de helling van erosie over iteraties, niet alleen de startkwaliteit. En wees kritisch tegen elke leverancier die alleen een netter beginpunt laat zien.

Regelgevingsduiding: agentische codeertooling hoort niet primair in het AI Act-dossier

De tweede bestuurlijke consequentie gaat over waar dit risico gereguleerd wordt. Agentische codeertooling wordt vaak in het EU AI Act-dossier geparkeerd, omdat het een AI-systeem is. Maar dat is de verkeerde framing.

Onder de Cyber Resilience Act (CRA) valt software als product met essentiële cybersecurity-eisen, waaronder het veilig behandelen van kwetsbaarheden, integriteit en het beperken van aanvalsoppervlak. Een coding agent die zijn eigen code uitbreidt en daarbij het foutpadoppervlak laat eroderen, is in precies die categorie een productrisico. De CRA-certificering gaat over de toestand en het beheer van het product, en een agent die zelfstandig code wijzigt maakt die toestand dynamisch. Dat is hetzelfde probleem dat we eerder zagen bij AI-security agents onder de CRA (zie onze analyse van Certifying Ghosts): een statische beoordeling dekt niet een product dat zichzelf aanpast.

Voor Nederlandse publieke organisaties geldt daarnaast de Cyberbeveiligingswet (Cbw, de NIS2-implementatie). Als deze tooling in vitale of essentiële processen landt, of dat nu software-ontwikkeling is of geautomatiseerde beheerprocessen, valt de organisatie onder de incident-meldplicht en de risicobeheersverplichtingen.

Cruciaal is het timing-aspect. Het Digital Omnibus-uitstel heeft de AI Act-tijdlijnen van hoog-risico systemen verschoven, van 2 augustus 2026 naar eind 2027 en 2028. Maar dat uitstel geldt niet voor de CRA. De CRA-verplichtingen lopen op hun eigen schema, en de beoordeling van substantiele wijzigingen door AI-agents is een lopend vraagstuk dat geen uitstel heeft gekregen. Wie agentische codeertooling wegzet als "AI Act, en dat schuift toch", mist dat het CRA/Cbw-dossier niet geschoven is.

Pull-quote

Een prompt verlaagt het beginpunt van je AI-governance, niet de helling van je erosie. En pas op voor het framework dat de degradatie claimt op te lossen zonder de meetlat toe te passen waarmee degradatie zichtbaar wordt.

---

Bronnen: SlopCodeBench, arXiv 2603.24755, v1 (25 maart 2026); Harness-of-Harness, arXiv 2609.01481v1 (1 september 2026) en de bijbehorende GitHub-projecten. Beide papers zijn in de primaire bron gelezen inclusief appendices; alle genoemde cijfers zijn hieraan getoetst.