ChatPaper.aiChatPaper

Executar ou Não Executar: Analisando a Custo-Efetividade da Execução de Código na Reparação de Programas Baseada em LLM

To Run or Not to Run: Analyzing the Cost-Effectiveness of Code Execution in LLM-Based Program Repair

June 25, 2026
Autores: Zhihao Lin, Junhua Zhu, Mingyi Zhou, Xin Wang, Zhensu Sun, Renyu Yang, David Lo, Li Li
cs.AI

Resumo

Agentes baseados em LLM para reparo de programas são cada vez mais construídos sobre um paradigma de "gerar-executar-revisar", executando testes iterativamente para avaliar e refinar patches. Essa abordagem baseada em execução tornou-se prática padrão em sistemas de última geração. No entanto, execuções podem ser demoradas e custosas, e seu impacto nesses agentes permanece pouco explorado. Neste artigo, realizamos um estudo empírico em dois estágios sobre o comportamento de execução em reparo de programas baseado em LLM. Para caracterizar o comportamento de execução em escala, primeiro analisamos 7.745 rastros de agentes de submissões ao ranking do SWE-bench. Em segundo lugar, avaliamos 3.000 tentativas de reparo ponta a ponta em 200 instâncias do SWE-bench e três agentes (Claude Code, Codex e o código aberto OpenCode) sob quatro paradigmas de execução, o que permite uma comparação detalhada de desempenho e custo. Nossa análise revela três observações principais: (1) A execução de código é utilizada em todos os agentes e modelos analisados, com uma média de 8,8 execuções de teste por tarefa. O comportamento de execução varia substancialmente entre agentes e modelos, com frequência variando de 2 a 19 por tarefa, e execuções em estágio tardio alcançam consistentemente taxas de sucesso mais altas do que as em estágio inicial. (2) Restrições de execução têm pouco efeito no sucesso do reparo: em agentes comerciais com modelos de última geração, a diferença na taxa de resolução entre Proibido e Irrestrito é de apenas 1,25 pontos percentuais e não é estatisticamente significativa, enquanto Proibido economiza custos substanciais de tokens e tempo real. (3) O benefício da execução é concentrado, e não uniforme. Esses padrões sugerem que os agentes atuais aplicam execução indiscriminadamente, arcando com seu custo em instâncias onde ele fornece pouco benefício. Portanto, a execução deve ser tratada como um recurso com uma compensação explícita de custo-benefício, e não como uma capacidade padrão.
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.