1 Introduction↩︎

Large Language Models (LLMs) are far from perfect. Nevertheless, they are increasingly used in software engineering (SE) research and practice [1]. A common pattern when using LLMs for programming tasks is iterative refinement: users generate a solution, validate the output, identify remaining issues such as compiler errors, failing test cases, or missing edge cases, and feed these back to the model for repair. This process is repeated until the generated artifact either satisfies the requirements or the user abandons the attempt and reformulates the prompt. This iterative repair behavior has also been adopted by many LLM-based SE tools [2]–[11].

Instead of relying on manual feedback, such systems automatically validate generated artifacts using mechanisms such as compilation, static analysis, or test execution. When validation fails, the observed errors are provided to the model in order to generate a repaired version automatically. To prevent infinite repair cycles or oscillating behaviors in which one repair introduces new faults, these systems typically enforce an arbitrary fixed iteration limit [12], [13]. Furthermore, with the emergence of autonomous LLM agents [14]–[16] repair loops are becoming even more relevant. Such agents internally perform iterative cycles of tool calls, generation, validation, testing, and repair in order to accomplish complex SE tasks. As agent-based workflows become increasingly common, the choice of repair-loop limits directly affects the practicality and efficiency of these systems.

Choosing the right limit for repair loop iterations is important and impactful for several reasons. First, each additional repair attempt increases API usage costs and energy consumption, contributing both to higher economic as well as environmental impact [17]. Second, repeated inference calls increase runtime which can lead to slower development workflows. Third, iteration limits directly influence reproducibility and comparability across studies. Different repair budgets may lead to substantially different performance outcomes, making it difficult to fairly compare approaches when iteration limits are selected arbitrarily or are insufficiently documented [18].

Despite their importance, iteration limits are rarely studied systematically. Existing work often selects a small fixed number of repair attempts without providing empirical justification for this choice [6], [11], [12]. To the best of our knowledge, no prior work systematically studies the impact of repair-loop iteration limits across SE tasks and LLMs. In this work, we investigate the effectiveness of repair loops across multiple SE tasks, including code generation, test generation, and code translation. Using several low-cost LLMs and representative LLM-based SE tools, we analyze whether the commonly used limit of three or five repair attempts is sufficient or whether meaningful improvements continue to occur beyond this threshold. Our findings aim to contribute to a better understanding of how repair budgets should be selected and reported in future LLM-based SE research and systems.

Our central question is:

2 Repair Loops in LLM-Based SE-Tools↩︎

We define a repair-loop-based system as any LLM-based software engineering workflow, tool, or approach that iteratively generates, validates, and repairs artifacts until either a correct solution is produced or a predefined iteration limit is reached. 1 illustrates the general structure of such an approach.

These systems typically receive input in the form of task-specific context and an initial generation prompt. For example, a system may receive a textual specification and is prompted to generate source code, or receive source code and is prompted to generate corresponding test cases. Based on this input, the LLM generates an initial candidate artifact. The generated output is then validated using task-dependent mechanisms. In code generation scenarios, this may involve compilation, static analysis, or test execution. In test-generation tasks, generated tests may be checked for syntactic validity, coverage, or execution behavior.

If the produced artifact satisfies the validation criteria, the workflow terminates successfully and returns the generated output. Otherwise, the system extracts feedback from the failed validation step and provides this information back to the LLM to generate a repaired version of the artifact.

The repaired artifact is then validated again, resulting in an iterative generate \(\rightarrow\) validate \(\rightarrow\) repair cycle. This process continues until either a valid artifact is produced or a predefined iteration limit is reached and an error is returned. In practice these iteration limits are commonly implemented implicitly through bounded loops or explicitly through retry counters within the orchestration logic of the system. Despite being a central configuration parameter, these limits are often selected heuristically and rarely justified empirically [4], [6], [7].

In the context of this work, repair generally refers to feedback-driven regeneration conditioned on previous validation failures and we define a repair step as one iteration of the repair loop following a failed validation attempt.

3 Empirical Study↩︎

To answer our posed question we conduct an empirical study across a set of tools with different tasks, datasets, and programming languages. The tasks span code generation, test-case generation and code translation. To ensure that any observed results are not due to a particular model’s behavior we select three models: Google’s Gemma-4¹, Qwen3.5² and OpenAI’s gpt-4o-mini³.

We study four existing repair-based tools and a baseline that simulates human-style iterative chat interactions solving coding problems. The tools include INTERVENOR [7], Large Language Model Debugger (LDB) [8], from which we use the code translation component, CASCADE [5] and OpenCodeInterpreter (OCI) [12] in two versions. First, the original version where the initial prompt contains all test-cases that should pass and a second version without test-cases in the initial prompt. 1 lists the tools and their datasets. Each datasets was also used in the tools original papers. For the baseline (Basic LLM Call) we use Defects4J [19].

To enable a comparison between the tools, we made two types of modifications. First, all tools were adapted to support the backbone LLMs that were hosted on a local server (Gemma-4 and Qwen3.5). For INTERVENOR this entailed a change from the OpenAI completions to the chat.completions API to enable the usage of the contemporary models since the completions API is deprecated. OCI was restructured to use a multi-turn conversation format rather than rebuilding the prompt from scratch each iteration, as in the original. These changes slightly alter the semantics of OCI and INTERVENOR, however, the change to the API call would be needed anyways to use contemporary models and were not specific to our study.

Second modification was to LDB, where the original implementation only evaluated correctness when the final repair loop is finished. We added per-iteration evaluation against the full held-out test suite at every step. For CASCADE, whose primary purpose is detecting inconsistent documentation-method pairs, we extracted only its test-case generation stage and discarded the later inconsistency analysis stages, since the initial test-generation component is the only part that implements a complete iterative repair loop suitable for our study. Crucially, the repair loop control logic and correctness criteria remained unchanged in all tools. The only changes were with respect to measurement and model compatibility. Furthermore, we fixed the temperature for all experiments at 0.2.

For each tool with every backbone LLM we compute the percentage of completed tasks on the respective dataset after the initial generation, step 0, and at each subsequent repair step up to a maximum of ten repairs. Those results are shown in 2, where each panel corresponds to one tool and each curve to a model.

Across all tools the curves share a consistent concave shape. From the initial generation to the first few repair steps the completion rate rises steeply and then flattens, with each additional step resulting in smaller improvements than the last. 2 shows this in concrete numbers, where we calculated the average relative improvements from each repair step to the next. Notably, the largest relative improvement occurs at step 1 and that by step 3 the marginal gains have dropped to single digit percentages or below. This pattern holds across all three backbone models and all tasks including outliers such as Qwen on LDB starting with only 30% completion rate and then improving drastically. This suggests that diminishing returns are a recurring characteristic of the evaluated repair-loop workflows.

When examining where tools differ, the main distinction lies in how quickly the return on repair diminishes. OCI shows only marginal improvements after the first repair step, while the Basic LLM Call and CASCADE are still rising at step 3. Furthermore, within each panel, models may start at different absolute levels but follow the same curve shape. The gap between models is largest at step 0 and narrows with each repair step, visible most clearly in LDB where Qwen starts near 30% and Gemma near 85% yet both curves flatten at roughly the same point. Furthermore, we can observe that each tool, independent of the model backbone, provides a different performance ceiling and a different rate at which repairs approach it.

4 Discussion↩︎

The first three to four repair steps contribute the vast majority of the total achievable gain. Following iterations can still repair additional cases, however, improvements drop to near zero shortly after steps 5 to 7 across all evaluated tasks and tools. Hence we argue that the costs that come with these improvements require a careful trade-off analysis with respect to parameters such as API costs and energy usage. This consideration is increasingly relevant for agent systems, where repair loops are often deeply integrated into the execution workflow and may trigger multiple expensive inference calls per task or even result in infinite loops.

Interestingly, our results indicate that factors such as feedback design and content, orchestration logic, and the validation strategy substantially influence how effective additional repair attempts are at improving generated artifacts. This comes from the observation that completion curves for the same tool have similar shapes across all models, even when the absolute performance levels differ.

The comparison between the two OCI variants particularly highlights this effect. While both variants share nearly identical repair behavior in later iterations, they differ substantially in their initial success rates. The primary difference between the two approaches is that one variant already includes tests during the initial generation step, whereas the other only incorporates the output of the test suite as repair feedback during subsequent iterations. Despite this relatively small architectural difference, the resulting repair trajectories differ noticeably during the early repair stages before converging toward similar trends.

At the same time, model-specific performance characteristics remain visible across tools. For almost all evaluated workflows, the Gemma model achieves the strongest overall performance, while the older GPT variant generally performs worst. However, CASCADE represents a notable exception to this trend. One possible explanation is that CASCADE was originally evaluated and probably optimized around the specific output of GPT-based models. This observation further reinforces that the interaction between tool repair logic and model behavior needs to be examined carefully.

Furthermore, our replication effort revealed that many existing LLM-based SE tools are not easily transferable across models. In practice, substantial modifications to prompts, parsing logic, validation mechanisms, or orchestration strategies are often required when replacing the originally intended backbone model. This raises broader concerns regarding comparability and reproducibility in LLM-based SE research. While a detailed investigation of reproducibility challenges is outside the scope of this work, our findings indicate that LLM tools and specifically repair-loop behavior cannot always be studied independently of the surrounding tool architecture and model assumptions and therefore cannot always be compared directly.

5 Threats to Validity↩︎

5.0.0.1 Internal Validity

Our study does not use the original models employed by the evaluated tools and prior work. In addition, due to computational and financial constraints, we do not perform repeated executions for every experimental configuration. Since LLMs exhibit non-deterministic behavior, repeated runs may produce variance in absolute performance values. However, the goal of this work is not to reproduce exact performance numbers, but to analyze repair-loop trends across different iteration limits. We therefore use the same set of models consistently across all evaluated tools and tasks.

Furthermore, the evaluation generally relies on task-specific automated validation procedures such as compilation and test execution. While these mechanisms provide scalable correctness signals, they may not fully capture semantic correctness or overall software quality, however, they ensure consistency with existing evaluation methodologies.

5.0.0.2 External Validity

Our experiments focus primarily on cost-efficient LLMs, and the observed results may therefore not generalize directly to larger, newer models. More capable models may require fewer repair attempts due to stronger reasoning and generation capabilities.

Furthermore, the selected tasks may not represent the full spectrum of repair-loop-based SE workflows. Nevertheless, we evaluate three substantially different SE tasks across five datasets, providing diversity in both generation objectives and validation mechanisms. Code generation in particular represents one of the most widely studied and practically relevant applications of LLMs in SE, increasing the practical relevance of the evaluated tools and benchmarks. The consistency of observed trends across multiple tasks and datasets partially mitigates this threat even further.

6 Related Work↩︎

Prior work on LLM-based repair can be categorized into three types. The first category is feedback driven generation that only uses an LLM and no information from the external executions [10], [11].

The next category characterizes tools that utilize some form of execution based feedback [6], including runtime and compilation errors [4], [12], [13], natural language [3] and execution graphs [8].

Another category distributes the repair process across multiple agents or structured components. INTERVENOR [7] separates a Code Teacher, which constructs a Chain-of-Repair from compiler feedback, from a Code Learner, which executes the revisions, within three turns. PairCoder [9] combines planning and implementation agents with execution-guided repair within ten iterations.

Finally, our work is also related to empirical studies of repair and self-correction. Critical surveys note that self-correction effectiveness depends strongly on the feedback source and evaluation design, and that unclear protocols can overestimate gains [23]. Closest to our motivation, Olausson et al. [2] compare repair with drawing additional independent samples under comparable compute budgets, while Tang et al. [24] frame repair as an exploration–exploitation tradeoff. In contrast, we ask a complementary question: Given that many LLM-based SE tools already implement repair loops, how much does each additional iteration help? We therefore measure per-iteration completion rates across existing tools, tasks, datasets, and model backbones, shifting the focus from whether to use repair to how iteration limits should be selected, justified, and reported.

7 Conclusion↩︎

Repair loops have become a fundamental component of modern LLM-based software engineering systems, ranging from code-generation tools to autonomous agent workflows. Despite their widespread use, the choice of repair-loop iteration limits is often treated as an arbitrary implementation detail and rarely justified empirically.

In this work, we conducted an empirical study across multiple repair-loop-based software engineering tools, tasks, datasets, and backbone models to analyze the effectiveness of additional repair iterations. Across all evaluated settings, we observe a consistent pattern of diminishing returns: the majority of achievable gains are obtained within the first three to four repair steps, while later iterations can still contribute marginal improvements.

Our results suggest that repair-loop behavior depends more strongly on orchestration logic, validation strategy, and feedback design than on the selected backbone model itself. At the same time, the observed interaction effects between tools and models indicate broader reproducibility and comparability challenges in LLM-based software engineering research.

Overall, our findings suggest that repair budgets should be explicitly reported and justified in future work, as they directly influence evaluation outcomes, computational cost, runtime, and environmental impact. As repair loops become increasingly integrated into autonomous agent systems, understanding and standardizing repair-loop behavior will become even more important for the development of reliable and reproducible LLM-based software engineering workflows. For future work we plan to extend on our results by adding more tools, models and conducting a larger scale reproducibility study for LLM-based SE tools.

References↩︎