Запускать или не запускать: анализ экономической эффективности выполнения кода при исправлении программ на основе LLM
To Run or Not to Run: Analyzing the Cost-Effectiveness of Code Execution in LLM-Based Program Repair
June 25, 2026
Авторы: Zhihao Lin, Junhua Zhu, Mingyi Zhou, Xin Wang, Zhensu Sun, Renyu Yang, David Lo, Li Li
cs.AI
Аннотация
LLM-агенты для исправления программ всё чаще строятся на парадигме «генерация–запуск–доработка», выполняя тесты итеративно для оценки и улучшения патчей. Этот подход, основанный на выполнении кода, стал стандартной практикой в современных системах. Однако выполнение может быть трудоёмким и дорогостоящим, при этом его влияние на таких агентов остаётся недостаточно изученным. В данной статье мы проводим двухэтапное эмпирическое исследование поведения выполнения в LLM-агентах, предназначенных для исправления программ. Чтобы охарактеризовать поведение выполнения в масштабе, мы сначала анализируем 7 745 трасс агентов из заявок на доску лидеров SWE-bench. На втором этапе мы оцениваем 3 000 сквозных попыток исправления по 200 экземплярам SWE-bench для трёх агентов (Claude Code, Codex и OpenCode с открытым исходным кодом) в рамках четырёх парадигм выполнения, что позволяет провести детальное сравнение производительности и стоимости. Наш анализ выявил три ключевых наблюдения: (1) Исполнение кода используется во всех проанализированных агентах и моделях, в среднем 8,8 тестовых запусков на задачу. Поведение выполнения существенно различается между агентами и моделями: частота варьируется от 2 до 19 на задачу, при этом выполнения на поздних этапах стабильно достигают более высоких показателей успеха, чем на ранних. (2) Ограничения выполнения мало влияют на успех исправления: у коммерческих агентов с моделями SOTA разница в показателе разрешения между режимами «Запрещено» и «Без ограничений» составляет всего 1,25 процентных пункта и не является статистически значимой, при этом режим «Запрещено» экономит значительные ресурсы токенов и реального времени. (3) Польза от выполнения сосредоточена, а не равномерна. Эти закономерности указывают на то, что современные агенты применяют выполнение без разбора, неся его стоимость на тех экземплярах, где оно приносит мало пользы. Таким образом, выполнение следует рассматривать как ресурс с явным компромиссом между затратами и выгодой, а не как возможность по умолчанию.
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.