Uitvoeren of niet uitvoeren: Analyse van de kosteneffectiviteit van code-uitvoering bij op LLM gebaseerde programmareparatie

Samenvatting

LLM-gebaseerde agenten voor programmareparatie worden steeds vaker gebouwd op een "generate-run-revise"-paradigma, waarbij iteratief tests worden uitgevoerd om patches te evalueren en verfijnen. Deze uitvoeringsgebaseerde aanpak is de standaardpraktijk geworden in state-of-the-art systemen. Uitvoeringen kunnen echter tijdrovend en duur zijn, terwijl hun impact op deze agenten nog onderbelicht is. In dit artikel voeren we een tweefasige empirische studie uit naar het uitvoeringsgedrag bij LLM-gebaseerde programmareparatie. Om het uitvoeringsgedrag op schaal te karakteriseren, analyseren we eerst 7.745 agentsporen van SWE-bench leaderboard-inzendingen. Ten tweede evalueren we 3.000 end-to-end reparatiepogingen over 200 SWE-bench-instanties en drie agenten (Claude Code, Codex en het opensource OpenCode) onder vier uitvoeringsparadigma's, wat een fijnmazige vergelijking van prestaties en kosten mogelijk maakt. Onze analyse onthult drie belangrijke observaties: (1) Code-uitvoering wordt gebruikt bij alle geanalyseerde agenten en modellen, met gemiddeld 8,8 testuitvoeringen per taak. Het uitvoeringsgedrag varieert aanzienlijk tussen agenten en modellen, met een frequentie variërend van 2 tot 19 per taak, en uitvoeringen in een laat stadium behalen consequent hogere slagingspercentages dan die in een vroeg stadium. (2) Uitvoeringsbeperkingen hebben weinig effect op het reparatiesucces: bij commerciële agenten met SOTA-modellen bedraagt het verschil in oplossingspercentage tussen Verboden en Onbeperkt slechts 1,25 procentpunt en is het niet statistisch significant, terwijl Verboden aanzienlijke token- en wandklokkosten bespaart. (3) Het uitvoeringsvoordeel is geconcentreerd in plaats van uniform. Deze patronen suggereren dat huidige agenten uitvoering zonder onderscheid toepassen, en de kosten ervan dragen op instanties waar het weinig voordeel biedt. Uitvoering moet daarom worden behandeld als een hulpbron met een expliciete kosten-batenafweging, niet als een standaardmogelijkheid.

English

LLM-based agents for program repair are increasingly built on a "generate-run-revise" paradigm, iteratively executing tests to evaluate and refine patches. This execution-based approach has become standard practice in state-of-the-art systems. However, executions can be time-consuming and expensive, yet their impact on these agents remains underexplored. In this paper, we conduct a two-stage empirical study over execution behavior in LLM-based program repair. To characterize execution behavior at scale, we first analyze 7,745 agent traces from SWE-bench leaderboard submissions. Second, we evaluate 3,000 end-to-end repair attempts across 200 SWE-bench instances and three agents (Claude Code, Codex, and the open-source OpenCode) under four execution paradigms, which allows for a fine-grained comparison of performance and cost. Our analysis reveals three key observations: (1) Code execution is used across all agents and models analyzed, with an average of 8.8 test runs per task. Execution behavior varies substantially across agents and models, with frequency ranging from 2 to 19 per task, and late-stage executions consistently achieve higher success rates than early-stage ones. (2) Execution restrictions have little effect on repair success: on commercial agents with SOTA models the resolve-rate gap between Prohibited and Unrestricted is only 1.25 percentage points and not statistically significant, while Prohibited saves substantial token and wall-clock cost. (3) Execution benefit is concentrated rather than uniform. These patterns suggest that current agents apply execution indiscriminately, paying its cost on instances where it provides little benefit. Execution, therefore, should be treated as a resource with an explicit cost-benefit tradeoff, not a default capability.