Ejecutar o no ejecutar: Análisis de la costo-efectividad de la ejecución de código en la reparación de programas basada en LLM

Resumen

Los agentes basados en modelos de lenguaje de gran escala (LLM) para la reparación de programas se construyen cada vez más sobre un paradigma de "generar-ejecutar-revisar", ejecutando iterativamente pruebas para evaluar y refinar parches. Este enfoque basado en la ejecución se ha convertido en una práctica estándar en los sistemas de última generación. Sin embargo, las ejecuciones pueden ser costosas en tiempo y recursos, y su impacto en estos agentes sigue sin explorarse adecuadamente. En este artículo, realizamos un estudio empírico en dos etapas sobre el comportamiento de ejecución en la reparación de programas basada en LLM. Para caracterizar el comportamiento de ejecución a escala, primero analizamos 7,745 trazas de agentes de las presentaciones en la tabla de clasificación de SWE-bench. En segundo lugar, evaluamos 3,000 intentos de reparación de extremo a extremo en 200 instancias de SWE-bench y tres agentes (Claude Code, Codex y el de código abierto OpenCode) bajo cuatro paradigmas de ejecución, lo que permite una comparación detallada del rendimiento y el costo. Nuestro análisis revela tres observaciones clave: (1) La ejecución de código se utiliza en todos los agentes y modelos analizados, con un promedio de 8.8 ejecuciones de prueba por tarea. El comportamiento de ejecución varía sustancialmente entre agentes y modelos, con frecuencias que oscilan entre 2 y 19 por tarea, y las ejecuciones en etapas tardías logran consistentemente tasas de éxito más altas que las de etapas tempranas. (2) Las restricciones de ejecución tienen poco efecto en el éxito de la reparación: en agentes comerciales con modelos de última generación, la brecha en la tasa de resolución entre "Prohibido" y "Sin restricciones" es de solo 1.25 puntos porcentuales y no es estadísticamente significativa, mientras que la opción "Prohibido" ahorra un costo sustancial en tokens y tiempo real. (3) El beneficio de la ejecución es concentrado en lugar de uniforme. Estos patrones sugieren que los agentes actuales aplican la ejecución de manera indiscriminada, asumiendo su costo en instancias donde aporta poco beneficio. Por lo tanto, la ejecución debe tratarse como un recurso con una compensación explícita entre costo y beneficio, no como una capacidad predeterminada.

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.