Ausführen oder Nichtausführen: Analyse der Kosteneffizienz von Codeausführung bei der LLM-basierten Programmreparatur
To Run or Not to Run: Analyzing the Cost-Effectiveness of Code Execution in LLM-Based Program Repair
June 25, 2026
Autoren: Zhihao Lin, Junhua Zhu, Mingyi Zhou, Xin Wang, Zhensu Sun, Renyu Yang, David Lo, Li Li
cs.AI
Zusammenfassung
LLM-basierte Agenten zur Programmreparatur basieren zunehmend auf einem "Generieren-Ausführen-Überarbeiten"-Paradigma, bei dem Tests iterativ ausgeführt werden, um Patches zu bewerten und zu verfeinern. Dieser ausführungsbasierte Ansatz ist in modernsten Systemen zum Standard geworden. Allerdings können Ausführungen zeit- und kostenintensiv sein, und ihre Auswirkungen auf diese Agenten sind noch wenig erforscht. In dieser Arbeit führen wir eine zweistufige empirische Studie zum Ausführungsverhalten in der LLM-basierten Programmreparatur durch. Um das Ausführungsverhalten im großen Maßstab zu charakterisieren, analysieren wir zunächst 7.745 Agentenablaufverfolgungen aus SWE-bench-Leaderboard-Einreichungen. Zweitens evaluieren wir 3.000 End-to-End-Reparaturversuche über 200 SWE-bench-Instanzen und drei Agenten (Claude Code, Codex und den Open-Source-Agenten OpenCode) unter vier Ausführungsparadigmen, was einen detaillierten Vergleich von Leistung und Kosten ermöglicht. Unsere Analyse ergibt drei wesentliche Beobachtungen: (1) Codeausführung wird über alle untersuchten Agenten und Modelle hinweg eingesetzt, mit durchschnittlich 8,8 Testläufen pro Aufgabe. Das Ausführungsverhalten variiert erheblich zwischen Agenten und Modellen, mit einer Häufigkeit von 2 bis 19 pro Aufgabe, wobei Ausführungen in späteren Phasen durchweg höhere Erfolgsraten erzielen als solche in frühen Phasen. (2) Ausführungsbeschränkungen haben nur geringe Auswirkungen auf den Reparaturerfolg: Bei kommerziellen Agenten mit modernsten Modellen beträgt der Unterschied in der Lösungsrate zwischen "Verboten" und "Uneingeschränkt" nur 1,25 Prozentpunkte und ist statistisch nicht signifikant, während "Verboten" erhebliche Token- und Wanduhrkosten einspart. (3) Der Nutzen der Ausführung ist konzentriert und nicht gleichmäßig verteilt. Diese Muster deuten darauf hin, dass aktuelle Agenten Ausführungen unterschiedslos einsetzen und deren Kosten bei Instanzen tragen, bei denen sie nur geringen Nutzen bringen. Ausführung sollte daher als Ressource mit explizitem Kosten-Nutzen-Abwägung behandelt werden, nicht als Standardfähigkeit.
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.