Exécuter ou ne pas exécuter : Analyse de la rentabilité de l'exécution de code dans la réparation de programme basée sur les LLM

Résumé

Les agents basés sur des LLM pour la réparation de programmes sont de plus en plus construits sur un paradigme « générer-exécuter-réviser », qui exécute itérativement des tests pour évaluer et affiner les correctifs. Cette approche basée sur l'exécution est devenue une pratique standard dans les systèmes de pointe. Cependant, les exécutions peuvent être coûteuses en temps et en ressources, mais leur impact sur ces agents reste peu exploré. Dans cet article, nous menons une étude empirique en deux étapes sur le comportement d'exécution dans la réparation de programmes assistée par LLM. Pour caractériser le comportement d'exécution à grande échelle, nous analysons d'abord 7 745 traces d'agents issues des soumissions du classement SWE-bench. Ensuite, nous évaluons 3 000 tentatives de réparation de bout en bout sur 200 instances de SWE-bench et trois agents (Claude Code, Codex et l'agent open-source OpenCode) selon quatre paradigmes d'exécution, ce qui permet une comparaison fine des performances et des coûts. Notre analyse révèle trois observations clés : (1) L'exécution de code est utilisée par tous les agents et modèles analysés, avec une moyenne de 8,8 exécutions de tests par tâche. Le comportement d'exécution varie considérablement selon les agents et les modèles, la fréquence allant de 2 à 19 par tâche, et les exécutions tardives atteignent systématiquement des taux de succès plus élevés que les exécutions précoces. (2) Les restrictions d'exécution ont peu d'effet sur le succès des réparations : pour les agents commerciaux utilisant des modèles de pointe, l'écart du taux de résolution entre les modes Interdite et Illimitée n'est que de 1,25 point de pourcentage et n'est pas statistiquement significatif, tandis que le mode Interdite permet d'économiser des coûts substantiels en tokens et en temps réel. (3) Le bénéfice de l'exécution est concentré plutôt qu'uniforme. Ces schémas suggèrent que les agents actuels appliquent l'exécution de manière indifférenciée, en en payant le coût sur des instances où elle apporte peu d'avantages. L'exécution doit donc être traitée comme une ressource soumise à un compromis explicite entre coût et bénéfice, et non comme une capacité par défaut.

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.