Automated repair tools are increasingly pointed at a file and left running to read the code, name the worst bug, patch it, read the result and repeat until nothing is left to find. Researchers at Warwick and UnlikelyAI ran that loop to its conclusion and measured what repair benchmarks rarely look at, which is what happens when the code handed to the fixer was already correct.
They fed competitive-programming submissions through the loop, some passing all their tests and some not. The model saw only the current state of the file, never the history of its own edits. That is what you get when a developer approves changes without reading them, or when earlier turns fall out of the context window.
Two rates matter here, how often a pass over broken code makes it work, and how often a pass over working code breaks it. Across the setups tested, the damage was at least as large as the repair, and with small targeted edits it was several times larger. The stronger of the two models broke correct programs on 29% of the passes it made over them, close to five times the rate at which it repaired broken ones.
"We find that LLMs are overeager to find (pseudo-)bugs, causing correct programs to fail, while only a minority of incorrect programs get to a passing state."
The edit format mattered more than it has any right to. Asking the model to rewrite the whole file was consistently safer than asking it for one surgical search-and-replace, roughly halving the damage. Targeted edits also drove the loop into cycles, with the same change added and removed forever, some runs flipping between a working program and a broken one indefinitely. The authors suspect the model holds one canonical version of a correct program and loses its footing patching a different but equally correct one. A plausible story, and an untested one, since the data shows what got edited, never why.
Then they found the dial. A probe of the model's internals isolated a direction tracking whether it believes the code is buggy. Turning it down stopped the loop dead.
"Indeed, negative steering completely stops the loop from happening, thus preserving all correct submissions, while not fixing any incorrect submissions."
Which suggests the appetite for editing is a separate faculty from the ability to diagnose. Suppressing it cost almost nothing in repairs, because there were barely any to lose.
This is about stopping conditions. On this evidence, a loop that runs until the model reports no more bugs is asking a component with a documented habit of finding bugs in bug-free code to decide when to quit. Cap the iterations, and where you can, make a green test suite the exit condition rather than the model's own verdict. The same appetite shows up in review bots, where a tool that never comes back with "nothing here" isn't demonstrating thoroughness. And a repair rate quoted without the matching damage rate on already-correct code should prompt a follow-up question, because almost nobody measures the second one.
Resist over-reading the whole-file result, since these were self-contained programs of around forty lines, where a rewrite is cheap. That's not the trade in a live repository.
The larger gap is that the study never gave the model a goal. It was asked to find bugs with no statement of what the code was supposed to do, on two small, inexpensive models. Whether an agent working from a ticket, a specification and a failing test is anywhere near as trigger-happy is the question this design leaves open, and it's the setup most teams actually run.
Sources
- Wang-Lin, X., Isopoussu, A., Mahon, L., "If It's Not Buggy, Don't Fix It: On the Dynamics of Iterative Bug-fixing with LLMs" — https://arxiv.org/abs/2609.10123