ProgramBench Vetted
Kan een agent een programma heropbouwen op basis van een uitvoerbaar binair bestand? Dat is de fundamentele vraag achter ProgramBench. Wij presenteren ProgramBench Vetted, een set van 50 taken gebaseerd op hetzelfde uitgangspunt, maar met verbeteringen in het ontwerp-proces om de benchmark eerlijker en betrouwbaarder te maken.
Naast het behouden van meetbare gedeeltelijke vooruitgang en deterministische testgebaseerde beoordeling, voegt ons ontwerp-proces een breder scala aan controles toe voor foutmodi met betrekking tot testduplicatie, omgevingskwaliteit, 'hackbaarheid' en eerlijkheid.
Wat is ProgramBench?
ProgramBench, uitgebracht door Meta in mei 2026, geeft een agent een gecompileerd programma dat kan worden uitgevoerd maar niet gelezen, samen met de bijbehorende documentatie. De agent moet een nieuwe codebase schrijven die het waargenomen gedrag reproduceert.
Elk van de 200 taken is een echt open-source CLI-project, variërend van kleine utilities tot FFmpeg, SQLite en de PHP-interpreter. Het taakpakket is een verzegelde container: het binaire bestand is alleen beschikbaar voor uitvoering, de documentatie is bewaard, en de broncode en git-geschiedenis zijn verwijderd. De agent krijgt een shell, geen internettoegang, duizend stappen en zes uur de tijd. Gedragstests beoordelen het resultaat. De tests zijn zelf geschreven door een agent die het originele repository en binaire bestand heeft onderzocht.
Het oorspronkelijke constructieproces bestaat uit drie fasen:
- Bouw van de referentie: Selecteer een repository in een gecompileerde taal en laat een build-agent het 'gold' binaire bestand produceren.
- Genereer gedragstests: Een test-generatie-agent onderzoekt de repository en het binaire bestand met toegang tot de broncode, bestaande tests en documentatie.
- Valideren en verzegelen: Elke gegenereerde test moet een assertion-linter passeren, slagen bij het gold-binaire bestand en falen bij een dummy-binair bestand. Daarna wordt de werkruimte van het model beperkt tot het executable, de documentatie en de behouden test-assets.
Tijdens de evaluatie ontbreken de broncode, repository-tests en git-geschiedenis. De agent behoudt de documentatie en kan het referentie-binaire bestand uitvoeren tijdens het bouwen van de vervanging. De gegenereerde behavioral suite beoordeelt de reconstructie op basis van het fractie van geslaagde tests; een taak is pas opgelost wanneer elke test slaagt.
De behouden documentatie biedt een deel van de specificatie, maar niet het volledige gedragscontract. De rest moet worden afgeleid door het binaire bestand te onderzoeken, hypothesen te vormen, deze te implementeren, het resulten te vergelijken en te herzien. De vier geanalyseerde frontier-agents besteden 23% tot 34% van hun acties aan het onderzoeken van de referentie.
Waarom ProgramBench Vetted anders is
ProgramBench Vetted is niet simpelweg ontworpen om moeilijker te zijn. Het is ontworpen zodat elk punt van beloning (reward) getrouwer het beoogde gedrag vertegenwoordigt. Het doel is gecalibreerde moeilijkheid: een taak moet ruimte laten voor betekenisvolle gedeeltelijke vooruitgang, maar mag niet het grootste deel van de score toekennen voor het reproduceren van een oppervlakkige interface of het exploiteren van een defect in de evaluatie.
De interne ProgramBench-generatie-pipeline
Net als de originele ProgramBench zet onze pipeline een repository om in twee gekoppelde artefacten: een cleanroom-reconstructieomgeving en een gedragstest-suite. Om de foutmodi die we vonden tijdens de audit van de releasede dataset aan te pakken, hebben we validatie en reparatie over het hele constructieproces toegevoegd.
Continu onderzoek door onderzoekers vormt de basis voor gespecialiseerde Agents as Judges en Agents as Doctors. De rechters onderzoeken de werkruimte, testen het relevante gedrag en produceren gescoreerde rapporten. Wanneer een veelbelovende taak een herstelbaar probleem heeft, gebruiken de 'dokters' dat bewijs om een beperkte wijziging aan te brengen. Deze loops werken samen met deterministische poorten voor eigenschappen die exact gemeten kunnen worden en adversarial agents die actief proberen de taak of de beloning te exploiteren. Menselijke reviewers behandelen ambigue gevallen en nemen de uiteindelijke beslissing.
Het proces is verdeeld in vier stadia:
Stadium 01: Bron en build
Een levensvatbare referentie is noodzakelijk vóór de testgeneratie. Menselijk geselecteerde repositories gaan door een sourcing-judge, een build-agent, deterministische compilatiepoorten en een judge-doctor reparatie-loop voordat er een gold-binair bestand en een cleanroom-basis ontstaat.
Stadium 02: Genereren en dedupliceren
Eén referentie, vele onafhankelijke pogingen om het gedrag te beschrijven. De repository en het binaire bestand voeden tot vijftien onafhankelijke test-generatie-branches via vijf frontier-modellen. Deterministische validatie en een gespecialiseerd multi-stage deduplicatieproces produceren een kandidaat-behavioral suite.
Stadium 03: Audit en reparatie-cleanup
De omgeving en de score worden als één systeem beoordeeld. Parallelle cleanroom-lek en test-kwaliteit judges kunnen optionele reparatie-dokters aanroepen. Goedgekeurde outputs gaan direct naar een kandidaat-taak; herhaalde mislukkingen escaleren naar menselijke review.
Stadium 04: Calibratie en goedkeuring
Modellen lossen de taak op; adversarial agents proberen de beloning te breken. Een kandidaat-taak doorloopt normale model-inferentie en gespecialiseerde adversarial-inferentie in parallel. Een algemene kwaliteitsjudge evalueert beide stromen en bereidt bewijs voor voor een menselijke beslissing om de taak te accepteren, te repareren of af te wijzen.
De huidige candidate set
De candidate set bevat 50 apart gehouden, verifier-beoordeelde taken. De constructie maakt gebruik van vijf frontier-modellen over maximaal 15 onafhankelijke testgeneratie-pogingen per taak.
- Shortcut-controles: De pipeline onderzoekt bekende foutklassen: niet-variërend gold-gedrag, bereikbare referentie-implementaties, constante pinning-tests en degenerate suite-vormen.
- Calibratie: We draaien meerdere modellen tegen elke kandidaat en bestuderen de distributie van gedeeltelijke credits. Het doel is een bruikbare moeilijkheidsgraad: genoeg toegankelijk gedrag om vooruitgang te meten, maar genoeg onopgelost gedrag om ruimte voor verbetering te behouden.
- Eerlijkheid en hackbaarheid: We onderzoeken zowel vereisten waaraan een echte implementatie niet kan voldoen, als shortcuts die credit opleveren zonder het bedoelde gedrag te herbouwen. In de originele dataset hing FFmpeg bijvoorbeeld af van ontbrekende referentie-inputs, en een wrapper van acht regels rond het reeds geïnstalleerde XZ-executable leverde 77,3% van de actieve beloning op.
- Deduplicatie: We consolideren paren die geclassificeerd zijn als hetzelfde of subsumeerd gedrag.
Vergelijking van het leaderboard
| Model | ProgramBench (Mean Reward) | ProgramBench (Almost $\ge$95%) | ProgramBench (Resolved) | ProgramBench Vetted (Mean Reward) | ProgramBench Vetted (Almost $\ge$95%) | ProgramBench Vetted (Resolved) |
|---|---|---|---|---|---|---|
| Claude Opus 5 (xhigh) | 74.7% | 37.0% | 4.5% | 81.9% | 50.0% | 14.0% |
| Grok 4.6 (xhigh) | --- | --- | --- | 68.7% | 24.0% | 6.0% |
| GPT 5.5 (xhigh) | 69.8% | 13.5% | 0.5% | 85.2% | 28.0% | 2.0% |
| DeepSeek V4 Pro 0813 (xhigh) | --- | --- | --- | 71.8% | 22.0% | 2.0% |
| Claude Sonnet 5 (xhigh) | --- | --- | --- | 57.9% | 14.0% | 2.0% |
| Muse Spark 1.2 (high) | --- | --- | --- | 55.5% | 6.0% | 2.0% |
| GPT 5.6 Sol (xhigh) | 69.9% | 15.5% | 1.0% | 82.8% | 28.0% | 0.0% |
| Kimi K3 (max) | 77.8%* | --- | --- | 22.1% | 10.0% | 0.0% |
| Gemini 3.7 Flash (high) | 61.6% | 5.5% | 0.0% | 43.4% | 6.0% | 0.0% |
| DeepSeek V4 Flash 0731 (high) | --- | --- | --- | 51.6% | 4.0% | 0.0% |
| GPT 5.6 Terra (xhigh) | --- | --- | --- | 70.6% | 4.0% | 0.0% |
| GLM-5.2 (xhigh) | 64.6% | 8.5% | 0.0% | 59.1% | 4.0% | 0.0% |
| Gemini 3.6 Flash (high) | 55.7% | 4.0% | 0.5% | 57.8% | 0.0% | 0.0% |
| GPT 5.6 Sol (medium) | 57.8% | 2.5% | 0.5% | 61.2% | 0.0% | 0.0% |
| Gemini 3.1 Pro Preview (high) | 36.6% | 0.0% | 0.0% | 29.1% | 0.0% | 0.0% |
| GPT 5.6 Terra (medium) | --- | --- | --- | 26.1% | 0.0% | 0.0% |
| Muse Glimmer 30B (high) | --- | --- | --- | 7.2% | 0.0% | 0.0% |
Mean reward is het macro-gemiddelde van de fractionele testscore per taak. "Almost" is het aandeel taken dat minstens 95% bereikt; "resolved" is het aandeel dat 100% bereikt. Alle ProgramBench Vetted resultaten gebruiken pass@1.
GPT 5.5 leidt in ProgramBench Vetted qua gemiddelde beloning (85,2%), maar lost slechts 2% van de taken volledig op. Claude Opus 5 heeft een iets lagere gemiddelde beloning (81,9%), maar leidt zowel bij 'almost' (50%) als 'resolved' (14%).
Analyse van taakmoeilijkheid en trajecten
In ProgramBench Vetted vallen 46 van de 50 taken tussen de 20% en 80% gemiddelde beloning. Dit gecalibreerde bereik behoudt ruimte voor betekenisvolle gedeeltelijke vooruitgang, terwijl er genoeg onopgelost gedrag overblijft zodat een verbeterd model vooruitgang kan omzetten in een volledig opgeloste taak.
Voor elke modelconfiguratie die op beide benchmarks is geëvalueerd, vereist ProgramBench Vetted gemiddeld meer modelaanroepen per taak. Dit toont aan dat gecalibreerde taken uit kleinere of minder bekende repositories nog steeds langere oplossingstrajecten kunnen ondersteunen dan de originele set, zonder afhankelijk te zijn van ongewoon grote projecten zoals FFmpeg.
Soorten programma's
Elke taak is een gedragstechnisch testbaar CLI-programma. We classificeren de kandidaten in een vaste taxonomie:
| Categorie | Wat het omvat | Aantal taken |
|---|---|---|
| Interpreters, compilers en virtuele machines | Kleine talen, bytecode VM's, compilers | 18 |
| Assemblers en disassemblers | Assembly en disassembly voor echte en toy ISA's | 12 |
| Ontwikkelaarsgereedschappen | Developer utilities: runners, inspectors, generators, log-analyse | 4 |
| Gestructureerde data-codecs | Formaat-parsers en converters | 7 |
| Media- en geometrieverwerking | Media codecs, mesh transformatie, simplificatie en encoding | 4 |
| Wiskundige en constraint-solving tools | Numerieke algoritmen, expressie-evaluatie en constraint solvers | 3 |
| Machine- en console-emulators | Machine- en console-emulators | 2 |
De originele dataset en de noodzaak voor een nieuwe
Het herscheppen van ProgramBench op schaal legde twee belangrijke bevindingen bloot: gedupliceerde actieve beloningen en concrete credits die verdiend werden zonder het beoogde programma te herbouwen.
1. Gedupliceerde actieve beloningen
De releasede manifests bevatten 247.723 actieve test-ID's. Twee tests worden als duplicaten beschouwd wanneer ze hetzelfde of materieel vergelijkbaar gedrag oefenen. In de geauditeerde set draagt de mediane taak 11% aan verwijderbare duplicaten in zijn gescorede suite; het hoogste gemeten aandeel is 37% (bijv. tui journal).
Duplicatie is problematisch omdat het bepaalde gedragingen zwaarder weegt dan andere. Dit kan modellen bevoordelen die herhaaldelijk een smalle familie van vergelijkbare checks doorlopen en kan reinforcement learning sturen naar de meest herhaalde gedragingen in plaats van naar het volledige programmacontract.
2. De beloning kan worden "gekocht"
We vonden gevallen waarbij een inzending die aantoonbaar het programma niet herbouwde, toch actieve credits verzamelde.
- Score-inflatie (cmatrix): Veel tests vragen of een vlag wordt geaccepteerd, maar combineren dit met
-V. Het programma stopt na het printen van de versie, voordat het gedrag van de vlag kan draaien. Een klein programma dat alleen de help- en versietekst reproduceert, slaagt voor 79,5% van de actieve suite. - Ontbrekende credits (FFmpeg): Van de 1.091 actieve FATE-cases vereisen 1.029 mediabestanden die ontbreken in het releasede archief. Hierdoor meten deze gevallen verpakkingsfouten in plaats van reconstructievermogen.
- Toegang tot ambient implementaties (XZ en LZ4): De originele omgevingen bieden toegang tot werkende implementaties van de programma's. Een wrapper van acht regels rond het geïnstalleerde XZ-executable levert 77,3% van de actieve beloning op. Bij LZ4 verhoogt het delegeren van compressie naar de geïnstalleerde library de score met 31,62 procentpunten.
Implicaties voor reward design
Een zwakke suite kan rankings vervormen. Voor reinforcement learning is de suite zowel een meting als een instructie. Wanneer een shortcut een goedkopere weg naar beloning biedt (bijv. het printen van een --help string in plaats van het implementeren van de parser), zal het model deze weg volgen.
Toekomstige ontwikkelingen
We zullen het aantal gevalideerde taken blijven verhogen en de benchmark updaten naarmate modellen verbeteren, met als doel: meer eerlijkheid, meer betrouwbaarheid en een toenemende moeilijkheidsgraad.
Daarnaast werken we aan uitbreidingen buiten gecompileerde CLI-binaries:
- Spec2Code benchmarks: Benchmarks gebaseerd op expliciete specificaties als startpunt, zonder referentie-binair bestand om te onderzoeken.
- API's en servers: Herbouw van een server op basis van API-documentatie en probing, waarbij de verifier parity-checks uitvoert op response, statuscodes en state.
- Libraries en SDK's: Re-implementatie van een library vanuit een gedocumenteerde publieke interface.
- Protocol-daemons: Bouwen van een compatibele implementatie van een server die een wire-protocol spreekt.
- Data pipelines: Herbouw van een verzegelde transformatie (container) waarbij de verifier output-parity controleert op held-out inputs.
---
Appendix A: Uitgevoerde audits van de originele dataset
1. Residuele beloning voor een leeg programma
We testten een programma dat enkel int main(void) { return 0; } bevat. Dit lege programma behaalde toch scores bij nnn (23 tests), xq (19 tests) en ripgrep (22 tests), omdat deze tests stilte accepteren of een lege output verifiëren zonder eerst te bewijzen dat het doelgedrag is uitgevoerd.
2. Asserties die een proxy meten
In cmatrix, nnn en tty-clock vonden we tests die feitelijk iets anders meten dan de naam suggereert. In cmatrix wordt een kleurvlag getest door deze te combineren met -V, waardoor de test enkel controleert of de versiebanner verschijnt. In tty-clock is de test hard-coded op het jaar 2026, waardoor hij automatisch faalt vanaf 2027.
3. FFmpeg tests met ontbrekende inputs
We stelden vast dat 1.029 van de 1.091 FATE-cases falen omdat de benodigde mediabestanden ontbreken in de taak-image. Een correcte implementatie kan hier geen credit voor krijgen.
4. Een niet-renderende cmatrix implementatie
Een agent bouwde een programma van 99 regels dat help, versie en opties correct afhandelt, maar nooit de matrix-animatie rendert. Dit programma behaalde 79,5% van de score, omdat het overgrote deel van de punten gekoppeld is aan oppervlakkig CLI-gedrag.
5. Omgevingen die misbruikt kunnen worden
In de originele XZ- en LZ4-omgevingen waren de implementaties reeds geïnstalleerd. Een wrapper van acht regels rond /usr/bin/xz behaalde 77,3% van de score.
---
Appendix B: Ambient implementatie reproducties
1. XZ: Een dunne wrapper
De originele XZ-omgeving bevat XZ 5.2.5, terwijl de referentie XZ 5.8.2 is. Een wrapper die elke aanroep doorstuurt naar de geïnstalleerde versie behaalde 77,30% van de tests.
2. LZ4: Een adapter rond een geïnstalleerde library
De LZ4-omgeving bevat liblz4.so.1 1.9.3. Een adapter van 349 regels die de centrale compressie-algoritmen aan deze library overlaat, behaalde 37,23% van de tests. Zonder de library daalde de score naar 84/1.496.
---
Appendix C: Uitvoerbare maar moeilijke test-oppervlakken
We onderzochten vijf van de moeilijkste taken uit de originele ProgramBench om te bepalen of ze technisch uitvoerbaar zijn en of ze redelijkerwijs hersteld kunnen worden door een agent.
1. PHP: Een zichtbare interface en een verborgen regressie-oppervlak
De taak vereist het reproduceren van een volledige taalruntime. Hoewel de interface zichtbaar is, zijn veel tests gebaseerd op historische regressiegevallen (PHPT suite) die extreem specifiek zijn in hun output-verwachtingen. Een agent moet in essentie gissen naar de vraag voordat de referentie-binary als orakel kan dienen.
2. Ctags: Een brede parser-suite in een over-exposed omgeving
Ctags vereist veel taalparsers, maar in de geëvalueerde image was het executable zelf aanwezig in /workspace/ctags. Dit is een environment-lek waardoor een agent de implementatie kan hergebruiken in plaats van hem te reconstrueren.
3. Cppcheck: De grader herstelt een dependency die de probe niet heeft
In de inferentie-omgeving faalt Cppcheck omdat std.cfg ontbreekt. De grader voegt dit bestand echter wel toe voordat de tests worden uitgevoerd. Hierdoor is er sprake van asymmetrische executie: de grader repareert een runtime-dependency die de agent tijdens de reconstructie niet heeft.
4. Pandoc: Goed gedocumenteerd, maar uitzonderlijk breed en exact
Pandoc is goed gedocumenteerd, maar de tests eisen vaak een exacte match van output (bijv. 8.928 bytes aan AST-rendering). Een kleine afwijking in conventie kan een groot blok aan beloningen wissen, zelfs als de conversie functioneel correct is.
5. GROMACS: Gedocumenteerde commando's zonder representatieve probe-assets
De commando's van GROMACS zijn goed gedocumenteerd, maar de inferentie-omgeving bevat niet de wetenschappelijke assets (trajectories, topologies) die nodig zijn om het gedrag te observeren. De assets worden pas tijdens de grading toegevoegd.
---
Appendix D: De memorisatie-paradox
ProgramBench gebruikt bekende publieke programma's, wat prior exposure van modellen waarschijnlijk maakt. Het reconstrueren van een bekend programma kan een combinatie zijn van prior representaties en reverse engineering.
De paradox splitst de betekenis van de benchmark:
- In-corpus RL: Zou kunnen testen of RL helpt bij het ophalen en coördineren van bestaande kennis.
- Out-of-corpus RL: Zou transfer-capaciteiten kunnen testen als kan worden bewezen dat een repository afwezig was in de pretraining.
- Cross-corpus checkpoints: Zou kunnen helpen bij het onderscheiden van retrieval versus nieuw aangeleerd probleemoplossend gedrag.
Groetjes,