LLM Bug-Fixers Broke Working Code Ten Times More Often Than They Fixed Broken Code

Turn a language model loose on code that already works and it will, with some regularity, break it. A new report on arXiv puts arithmetic behind that intuition: in one configuration, an automated repair loop damaged correct programs roughly 26% of the time while repairing genuinely broken ones about 2.3% of the time — a ratio of more than ten to one in the wrong direction.

Key takeaways

• Measured on competitive programming submissions, an LLM repair loop damaged working code at a rate of 0.261 while fixing buggy code at only 0.023.
• Left to iterate, the models fell into pseudo-bug-fixing cycles, adding and removing the same edit indefinitely, with search-and-replace edits cycling more than whole-file rewrites.
• Probing found an internal direction that predicts editing propensity with near-perfect separation by layer 19; suppressing it stopped the destructive loop entirely — and stopped all real repairs too.

The measurement

The paper, If It's Not Buggy, Don't Fix It by Xietao Wang-Lin, Anton Isopoussu and Louis Mahon, examines what the authors call blind iterative use: handing a model a program, accepting whatever edit comes back, and repeating. It is a fair description of how a growing number of teams wire repair bots into code review.

The test bed was CodeContests+ — 20 problems, 40 C++ submissions each, averaging 23 test cases per problem — run against Google's Gemini 2.5 Flash-Lite and Alibaba's Qwen2.5-7B-Instruct. With greedy decoding and search-and-replace editing, Gemini's repair rate came in at 0.023 ± 0.002 against a damage rate of 0.261 ± 0.032; a second configuration put damage at 0.293 ± 0.011. The authors' summary is blunt: the damage rate can end up significantly higher than the repair rate.

Two caveats belong next to those figures. The models under test are small, fast ones rather than frontier systems, and competitive programming submissions are not a production codebase with its own test suite, review gates and CI. The benchmark measures a loop with no stopping condition and no human in it, which is the point — but it is not the same as measuring a well-instrumented repair pipeline.

The loop that will not settle

The more unsettling finding is what happens when you let the process run. Rather than converging on a stable version, the models frequently entered what the paper calls a pseudo-bug-fixing cycle: the same change is introduced, removed, and introduced again, with the program oscillating between passing and failing states. Search-and-replace blocks produced significantly more of these cycles, and longer ones, than whole-file edits did.

That matters operationally because a cycling agent looks busy. It generates diffs, it reports activity, it consumes tokens — and, absent a test oracle wired into the loop, nothing in its output signals that it is oscillating rather than progressing.

An internal direction for "this looks buggy"

The mechanistic section is where the paper gets genuinely interesting. Probing the model's activations, the authors constructed a steering vector that tracks editing propensity, with separation rising from an AUC of 0.7–0.8 in early layers to near 1.0 by around layer 19. The implication is that the model carries an internal representation of "buggy code" — and that this representation is being falsely triggered on programs that are perfectly fine, which is hallucination with a concrete address in the network.

Steering against that direction at γ = -0.5 shut the destructive loop down completely, preserving every correct submission. It also fixed nothing. That is not a deployable knob so much as a clean demonstration that willingness to edit and ability to repair are, in these models, entangled — you cannot simply dial down the false positives and keep the true ones.

What this changes for teams running repair bots

The practical reading is not that automated repair is useless but that the stopping condition is the product. A repair tool without a reliable oracle for "there is nothing here to fix" will spend most of its edits on code that did not need them, and the arithmetic above suggests those edits are net negative.

It also lends weight to an architectural trend already visible in shipping tools. Review-and-revise patterns that put an independent critic between a draft and the working tree — including the cross-family critique step in GitHub's newly previewed orchestration layer, which we covered in our report on Project HydraFusion — exist precisely to interrupt the blind loop this paper measures. Bounded iteration, tool-less reviewers and fail-safe patch application stop being conservative design choices once damage outpaces repair by an order of magnitude.

Outlook

Whether these ratios hold for frontier models on real repositories is the obvious follow-up, and nothing here settles it. What the report does establish is that the failure mode is structural rather than incidental: the propensity to edit is represented internally, it activates on healthy code, and iteration amplifies it instead of washing it out. Anyone building fully autonomous repair should be designing around that rather than waiting for the next model to make it go away.

FAQ

Which models were tested in the study?

Gemini 2.5 Flash-Lite and Qwen2.5-7B-Instruct. Both are small, inexpensive models rather than frontier systems, so the reported rates should not be read as measurements of what the largest coding models do.

Does this mean AI code review tools make code worse?

Not on its own. The study measures blind iteration with no stopping condition and no human review, which is the worst case rather than the typical deployment. Its relevance grows in proportion to how autonomously a repair tool is allowed to run.

Can the false bug detection simply be turned off?

Not cleanly. The authors found a steering vector that eliminates the destructive editing loop, but applying it also eliminated every successful repair — suggesting the same internal representation drives both behaviours.