🤖 AI

When Does Restricting a Coding Agent to execute_code Help? A Regime $\times$ Agent-Design Ablation

Dit artikel toont aan dat het beperken van programmeeragenten tot één enkele `execute_code`-tool vaak even effectief is als en frequent goedkoper dan het gebruik van tool-rijke omgevingen, wat onthult dat het optimale tool-oppervlak gezamenlijk wordt bepaald door de interactie tussen taakregimes en specifieke agentontwerpen, in plaats door een van beide factoren alleen.

Oorspronkelijke auteurs: Hong Yang, Qi Yu, Travis Desell

Gepubliceerd 2026-07-14

📖 6 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Hong Yang, Qi Yu, Travis Desell

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je voor dat je een super-slimme robotassistent hebt wiens taak het is om kapotte code te repareren of wiskundige puzzels op te lossen. Op dit moment is er een enorme discussie in de techwereld over hoe deze robot met de computer moet communiceren om de klus te klaren.

Sommigen zeggen: "Geef hem een volledige gereedschapskist met speciale knoppen voor elke taak!" (Zoals een luxe IDE).
Anderen zeggen: "Geef hem gewoon een command line en laat hem shell-commando's typen!" (Zoals een hacker in een film).
Een derde groep zegt: "Nee! Laat de robot gewoon een Python-script schrijven en dat in één keer uitvoeren!" (De execute_code aanpak).

Dit paper is als een enorme, eerlijke scheidsrechter die een race organiseert om te zien welke methode daadwerkelijk geld bespaart en de klus klaart. Ze hebben niet alleen gegokt; ze hebben exact dezelfde robot (twee verschillende modellen: Claude en Codex) op exact dezelfde taken laten draaien, maar veranderden alleen de tools die de robot mocht gebruiken.

Hier is wat ze vonden, onderverdeeld in eenvoudige verhalen.

De belangrijkste ontdekking: Het hangt af van de robot en de taak

De grootste verrassing? Er is niet één "beste" tool. De winnaar verandert afhankelijk van wie de robot is en wat hij doet.

Denk er zo over na:

De "Wiskundige Puzzel" Taak (Artifact Tasks): Als de robot berekeningen of data-verwerking uitvoert, is de "schrijf een script en voer het uit" methode (code_only) de duidelijke winnaar. Het is alsof je een chef inhuurt die gewoon één perfect recept schrijft en de hele maaltijd in één keer kookt.
- Voor de Claude-robot bespaarde deze methode 24,6% op de kosten.
- Voor de Codex-robot bespaarde het ongeveer 6,7% (hoewel het paper vermeldt dat dit een beetje wankel is, als een muntopwerp).
- Verdict: Voor wiskunde en data is de script-methode goedkoper en even goed in het oplossen van het probleem.
De "Een Rommelige Codebase Repareren" Taak (SWE-bench Tasks): Dit is waar het ingewikkeld wordt. Deze taken houden in dat er veel bestanden in een complex project bewerkt moeten worden.
- Als je de Codex-robot gebruikt: De script-methode is nog steeds de kampioen! Het bespaarde 19,9% op de kosten. Waarom? Omdat de script-methode de robot in staat stelt om veel kleine verzoeken te bundelen in één groot pakket, zoals een bezorgwagen die 50 pakketjes vervoert in plaats van een persoon die 50 keer heen en weer loopt.
- Als je de Claude-robot gebruikt: Oei. De script-methode werd zelfs duurder (met 14,4%), hoewel het paper opmerkt dat dit geen statistisch "bewezen" verschil was, maar slechts een sterke trend. Waarom? Omdat voor Claude het schrijven van een script om een bestand te bewerken is als proberen een band te wisselen door eerst een nieuwe auto te bouwen. Het kost veel te veel woorden (tokens) om de bewerking in code uit te leggen, wat zorgt voor "edit friction" (bewerkingswrijving).

Wat het paper uitsluit

Het paper betoogt expliciet tegen het idee dat één tool-interface altijd beter is voor iedereen.

Het sluit uit: "Speciale IDE-knoppen zijn altijd vereist." (Omdat de script-methode won bij Codex).
Het sluit uit: "Bash-commando's zijn altijd voldoende." (Omdat de script-methode goedkoper was voor Claude bij wiskunde-taken).
Het sluit uit: "Code-uitvoering is altijd de goedkoopste optie." (Omdat het duurder was voor Claude bij complexe code-reparaties).

De auteurs zijn heel duidelijk: Je kunt een tool niet kiezen op basis van de tool zelf. Je moet kijken naar de combinatie van het brein van de robot en het type werk.

De verrassing bij de "Pass Rate"

Hier is het belangrijkste deel: De kosten veranderden, maar het succespercentage niet.

Stel je twee hardlopers voor. De één rent in zware laarzen (dure tools), en de ander rent in sneakers (goedkope tools). Het paper vond dat beide hardlopers de race met exact dezelfde snelheid voltooiden.

Of de robot nu de luxe gereedschapskist, de bash-commando's of de script-methode gebruikte, het percentage taken dat ze correct oplosten was bijna identiek (binnen 3 procentpunt).
De "script"-methode maakte de robot niet slimmer of dommer; het veranderde alleen hoe hij de finishlijn bereikte. Soms was die wandeling een sprint (goedkoop), en soms een struikeling (duur).

Waarom veranderden de kosten?

Het paper duikt in de vraag waarom de script-methode goedkoper of duurder was.

De "Edit Friction" Belasting (Voor Claude): Wanneer Claude de script-methode moest gebruiken om een bestand te bewerken, moest hij een lang Python-script schrijven om alleen maar te zeggen "verander regel 5". Dit verbruikte veel "output tokens" (woorden die de robot moest typen). Het was alsof je een tol betaalde elke keer dat je een pagina wilde omslaan. Dit gebeurde vooral bij taken waarbij de robot faalde of moeite had, waardoor die specifieke runs zeer duur werden.
De "Batching" Bonus (Voor Codex): Wanneer Codex de script-methode gebruikte, kon hij veel kleine commando's in één script verpakken. In plaats van de computer te vragen "Lees bestand A", dan "Lees bestand B", en dan "Lees bestand C" (drie aparte ritten), vroeg hij "Lees A, B en C" in één keer. Dit bespaarde een enorme hoeveelheid "input tokens" (woorden die de robot moest lezen).
Het "Doomed Run" Effect: De extra kosten voor Claude bij de code-reparatietaken kwamen vooral voor wanneer de robot toch al van plan was te falen. Het was als een auto die zonder benzine komt te zitten terwijl hij cirkels rijdt. De script-methode veroorzaakte de mislukking niet; het maakte de mislukte poging alleen duurder.

Hoe zeker zijn we?

De auteurs zijn zeer zelfverzekerd over de wiskunde-taken en de Codex-robot resultaten. Ze hebben deze tests uitgevoerd op 93 wiskunde-taken en 100 code-reparatie-taken, waarbij ze drie verschillende "seeds" (willekeurige startpunten) gebruikten voor elke taak om te zorgen dat de resultaten niet op toeval berustten. De besparingen voor Codex bij code-reparaties waren statistisch significant (een daling van 19,9% met een p-waarde van 2,0 × 10⁻⁹, wat in feits nagenoeg nul kans op toeval betekent).

Echter, voor de Claude-robot bij code-reparaties is het resultaat wat minder eenduidig. De kosten gingen omhoog met 14,4%, maar de statistische test zei dat dit geen "slam dunk" bewijs was (p-waarde van 0,12). De auteurs noemen dit "directioneel", wat betekent dat de trend er is, maar ze zouden de tests vaker moeten uitvoeren om 100% zeker te weten dat het geen toevalstreffer is.

De Kern van de Zaak

Als je een coding agent bouwt:

Gok niet. De "beste" tool hangt af van je specifieke robot en je specifieke taak.
Voor Wiskunde/Data: Probeer de "schrijf een script" methode. Het is goedkoper en werkt net zo goed.
Voor Code-reparaties: Het hangt ervan af. Als je Codex gebruikt, is de script-methode geweldig. Als je Claude gebruikt, wil je misschien de standaard bewerkings-tools behouden, vooral voor moeilijke problemen, omdat de script-methode kan vastlopen in "edit friction".
Maak je geen zorgen over intelligentie: Het veranderen van de tools zal je robot niet slimmer of dommer maken; het verandert alleen de prijs van de reis.

Het paper concludeert dat de "goedkoopste" manier om een agent te draaien geen universele regel is; het is een puzzel waarbij je de tool moet afstemmen op de robot en de taak.

Technische Samenvatting: Wanneer helpt het beperken van een coding agent tot `execute_code`?

Probleemstelling

Het vakgebied van coding agents opereert momenteel onder drie onderling onverenigbare claims met betrekking tot de optimale "tool surface" (de set interfaces die aan de agent worden blootgesteld):

Gespecialiseerde IDE-primitieven zijn vereist: Gestructureerde interfaces (bijv. Agent-Computer Interface of ACI) presteren aanzienlijk beter dan ruwe shell-toegang, zoals beargumenteerd door SWE-agent.
Bash is voldoende: Minimale bash-only scaffolds kunnen competitieve prestaties leveren op software engineering benchmarks zonder IDE-primitieven.
Code Executie is Optimaal: Het routeren van agent-acties via een enkele execute_code tool (via Model Context Protocol, MCP) vermindert het tokengebruik drastisch vergeleken met het direct aanroepen van native tools.

Eerder werk is er niet in geslaagd deze tegenstrijdigheden op te lossen omdat bestaande studies één variabele vastleggen (bijv. het vergelijken van ACI vs. shell op een specifiek model) zonder de taakregime (computatie versus code-modificatie) en agent-ontwerp (verschillende modelfamilies) te kruisen. Gevolgelijk ontbreekt een verenigd begrip van welke condities welke tool surface bevoordelen.

Methodologie

De auteurs voeren een "missing crossed comparison" uit met behulp van een integriteit-schone, drieledige ablatiestudie. Het experimentele ontwerp is een $3 \times 2 \times 2$ factorieel ontwerp:

Drie Tool Surfaces:
- Baseline: De standaard tool surface van de agent (bijv. Read, Grep, Edit, Write, Bash).
- Bash_Only: Beperkt tot native bash plus read-only browsen (Read, Glob, Grep); alle file-editing primitieven (Edit, Write) zijn verwijderd.
- Code_Only: De gehele native surface wordt vervangen door een enkele MCP tool (mcp__codebox__execute_code) die een persistente Python+Bash REPL draait. Alle native built-ins zijn verboden.
Twee Agents: Claude Code (model claude-sonnet-4-6) en OpenAI Codex CLI (model gpt-5.5).
Twee Taakregimes:
- Computation (Computatie): Een nieuwe "Artifact" suite ( $n=93$ ) bestaande uit zelfstandige taken gedefinieerd door een workspace, een verborgen grader en een referentie-output.
- Modification (Modificatie): SWE-bench Mini ( $n=100$ ), een gecureerde subset van repository-modificatietaken.

Experimentele Controles:

Integriteit: De harness handhaaft een strikt SWE-bench protocol waarbij testpatches worden toegepast nadat de agent is afgerond. File system states zijn geïsoleerd tussen de armen met behulp van fuse-overlayfs om kruisbesmetting te voorkomen.
Kostenrekening: Om variabiliteit in server-side prompt caching aan te pakken, gebruiken de auteurs een "cache-adjusted cost" metriek. Dit past een median-floor aanpassing toe op de eerste-beurt input tokens, waardoor de "warm/cold" cache loterij wordt genormaliseerd zonder te beweren dat volledige cache-isolatie is bereikt.
Statistische Rigor: De eenheid van inferentie is de taak, niet de seed. Resultaten worden geanalyseerd met gepaarde Wilcoxon signed-rank tests op per-taak verschillen over drie onafhankelijke seeds.

Belangrijkste Bijdragen

1. Een Vier-Cell Agent-Conditionele Kostenstructuur

De studie onthult dat de kosteneffectiviteit van het beperken van een agent tot execute_code niet universeel is, maar gezamenlijk wordt bepaald door het taakregime en het agent-ontwerp.

Drie van de vier cellen bevoordelen code_only:
- Artifact/Claude: Significante kostenreductie ( $-24.6\%$ , $p=7.4 \times 10^{-14}$ ).
- Artifact/Codex: Directionele kostenreductie ( $-6.7\%$ , niet significant).
- SWE-bench/Codex: Significante kostenreductie ( $-19.9\%$ , $p=2.0 \times 10^{-9}$ ).
Eén cel keert de trend om:
- SWE-bench/Claude: code_only is directioneel kostbaarder ( $+14.4\%$ , niet significant).

Dit bevinding toont aan dat de drie eerdere claims in de literatuur niet tegenstrijdig zijn, maar alleen waar zijn onder specifieke (regime, agent) combinaties.

2. Drie-Mechanisme Causale Decompositie

De auteurs deconstrueren de geobserveerde kostenvariaties in drie afzonderlijke mechanismen:

Path-Cost (Edit Frictie): Voor Claude op SWE-bench dwingt code_only elke file edit om als een Python script te worden uitgedrukt. Dit schaalt de output tokens met de edit volume (Spearman $\rho=0.488$ ), wat een "belasting" creëert op high-edit taken.
Failure-Cost (Foutkosten): De kostenoverschrijding voor Claude op SWE-bench is gelokaliseerd naar "doomed-run" trajecten (instanties waar alle armen falen). Op de subset van unanimiteit-pass instanties, stort het kostenverschil in van $+14.4\%$ naar $+4.1\%$ (niet significant).
Pricing Asymmetry (Batching): Voor Codex op SWE-bench bereikt code_only significante besparingen ( $-19.9\%$ ) primair door input token reductie ( $-24.8\%$ ). Dit wordt gedreven door tool-call batching (één Python script vervangt meerdere native tool calls) en programmatische output suppressie (de agent beperkt de output volume, waardoor de harde output caps van native tools worden vermeden).

3. Capability Invariance (Capaciteitsinvariantie)

Over alle vier de cellen en drie tool surfaces heen zijn de pass rates statistisch gelijk (verschillen $<3$ procentpunten, allemaal niet significant).

De agreement matrix laat zien dat voor de meerderheid van de instanties ( $\ge 91\%$ onder majority vote), alle armen ofwel samen slagen ofwel samen falen.
Dit bevestigt dat de keuze van de tool surface de weg en de kosten van het oplossen van een taak verandert, maar niet de capaciteit om de taak op te lossen, wat consistent is met het "Capability Overlap Principle".

Resultaten Samenvatting

Het papier biedt een "at-a-glance" kaart van wanneer code_only voordelig is:

Computation Taken (Artifact): Het beperken tot execute_code is goedkoper voor beide agents, met een significante winst voor Claude.
Modification Taken (SWE-bench) met Codex: Het beperken tot execute_code is aanzienlijk goedkoper door input token batching en output controle.
Modification Taken (SWE-bench) met Claude: Het beperken tot execute_code is directioneel duurder. Dit wordt gedreven door "edit frictie" (hogere output tokens voor edits) en "failure costs" (dure mislukte trajecten), in plaats van een straf op succesvolle edits.

Betekenis en Claims

Het papier claimt de "drie tegenstrijdige claims" van het vakgebied op te lossen door aan te tonen dat geen enkele tool surface optimaal is in alle contexten.

Kosten vs. Capaciteit: Het belangrijkste signaal van de keuze van de tool surface is kosten, niet de pass rate. Omdat pass rates invariant zijn, is de keuze van de surface een kosten-engineering beslissing in plaats van een capaciteitsverbetering.
Gezamenlijke Bepaling: De optimale surface wordt bepaald door de intersectie van het taakregime (computatie versus modificatie) en de specifieke implementatie van de agent (hoe het omgaat met batching, output caps en edit primitieven).
Empirisch Ontvangst: De studie levert het eerste empirische bewijs voor de "tool-use tax" ongelijkheid in coding agents: een tool surface levert alleen een netto voordeel wanneer de taakspecifieke capaciteitswinst groter is dan de per-call kosten van de definitie ervan.

De auteurs stellen expliciet dat hun bevindingen kosten-engineering claims zijn, geen capaciteitsclaims. Ze beweren niet dat code_only universeel superieur is, noch beweren ze dat hun resultaten generaliseren naar alle modellen of externe MCP-tools zonder verdere validatie. De betekenis ligt in het methodologische framework dat de disambiguatie van agent-ontwerp en regime-effecten mogelijk maakt, waardoor het vakgebied beweegt van anekdotische industrie-rapporten naar gecontroleerde, gekruiste ablatiestudies.