Point an LLM at Working Code and It Will Find a Bug. There Is Not One.

Give a language model a program with no bugs in it and ask it to find the bug.

It will find one. It will not be there.

That is the opening finding of a paper submitted on 9 September 2026, and if you have ever run an autonomous review loop you already know the feeling, because you probably blamed your prompt. The paper's contribution is showing the behaviour is consistent, showing what it converges to, and then locating the thing inside the model that causes it.

The three findings

One. They hallucinate bugs in clean code. The phrasing is blunt:

LLMs consistently claim to detect bugs in entirely bug-free programs

Consistently, and across multiple models and multiple repair environments. Not one vendor's quirk.

Two, and this is the one that should change behaviour:

the rate of repair of buggy programs is less than that of the damage to correct programs

Turn that around. Run a bug-fixing loop over a codebase and it breaks working code faster than it fixes broken code. The expected value of pointing an automated fixer at a repository that is mostly fine is negative. Most repositories are mostly fine. That is what being a repository in production means.

Three, the long-run behaviour is a loop. Left iterating, the process

frequently reaches a pseudo-bug-fixing cycle where the same changes are added and removed again ad infinitum

The guard clause goes in. Next pass, the guard clause is redundant, so it comes out. Next pass, the input is unvalidated, so it goes in. Forever, at whatever your per-call cost happens to be. If you have wondered where the token spend on an overnight agent run went, this is a strong candidate, and it pairs badly with what one finished task actually costs.

The part that makes it science

Plenty of people have observed all three. The paper does something harder. Through mechanistic probing it reports finding

the existence of a steering vector which controls the editing propensity, suggesting that LLMs have an internal representation of "buggy code", and that this representation is what is falsely activated to induce pseudo-bug fixing

Unpack that, because it is genuinely satisfying.

A steering vector is a direction in the model's internal activation space that corresponds to some behaviour. Find it and you can turn that behaviour up or down by adding or subtracting it during a forward pass, without retraining anything.

They claim to have found the direction for the urge to edit.

Which means the model carries an internal notion of this code looks buggy that is separable from any actual property of the code. It fires when the code is clean. And the paper's suggestion is that the false firing is the mechanism behind the whole family of behaviours above.

There is something a bit magical about a result of this shape. A complaint everyone has, that felt like vibes and prompt luck, turns out to be a measurable direction in a vector space with a dial on it.

Why it happens, and it is not really about code

Here is the reading that makes the finding useful rather than just funny.

Ask an agent to find and fix the bugs. Consider what it means to comply. It searches, it reasons, it produces a diff. What does success look like if there is nothing wrong?

It looks like doing nothing. And "nothing" is very nearly unreachable, because everything in how these systems are built and trained points away from it. A response that produces no diff looks like a failure to engage. A helpful assistant helps. A tool called for repair repairs.

An agent asked to find problems has no clean way to represent there are none here. The null action is not on the menu, so it takes the nearest available one, which is an edit.

This is the same shape as the model that cannot say I do not know, and the same shape as a benchmark where abstaining scores identically to being wrong. It is the failure mode of any loop whose goal is ambiguous and whose only available move is to act.

The design rule follows directly: every autonomous loop needs an explicit, rewarded no-op. Not permitted, rewarded. "No changes needed" has to be a first-class outcome that the system treats as success, or the loop will always find something.

The authors frame the contribution the same way, as insight towards stopping conditions under ambiguous goals, which is a good deal more general than bug fixing.

The honest caveats

There are no numbers in this piece and that is deliberate. The abstract states every finding above directionally and reports no percentages at all. Less than and consistently are the actual claims. Anyone quoting you a specific figure for how often this happens is reading a body section, and if they are not, they invented it.

It is a v1 preprint and describes itself as a report, so treat effect sizes as provisional until it clears review.

And the direction of the main result is what matters anyway. Damage exceeding repair is a claim about a sign, not a magnitude. The sign is what changes what you should do.

What to do about it

Do not run an unattended fix loop over code you believe is working. That is the specific configuration the paper says has negative expected value. Point it at a failing test, a reproduced defect, a known bad input. Pointed at a symptom, it is a genuinely good tool. Pointed at a codebase and asked to look around, it is a random walk that ratchets.

Give the loop a hard iteration cap. The infinite add-remove cycle does not terminate on its own. It has no internal signal telling it that it has converged, because the thing that would tell it is the same false activation that started it.

Diff the diffs across passes. If pass three reverses pass two, you are in the cycle. That check is trivial and it is the cheapest possible detector.

Make no change needed an explicit, valid, rewarded output, in the prompt and in whatever scores the run. This is the actionable version of the mechanism.

Review autonomous fixes against the failing behaviour, not against plausibility. A hallucinated bug produces a plausible-looking fix, because plausibility is precisely what generated it. The question is never does this diff look reasonable. It is what observable thing does this diff change.

The line worth keeping

The instinct to reach for a tool is the same instinct that makes these systems useful. A model that would rather edit than say nothing is a model that gets things done, right up until there is nothing to do.

The hard problem in autonomy was never getting the system to act. It is getting it to stop.

Source. If It's Not Buggy, Don't Fix It: On the Dynamics of Iterative Bug-fixing with LLMs, Xietao Wang-Lin, Anton Isopoussu and Louis Mahon, submitted 9 September 2026. Every quote above is from that abstract. Related here: the best agent scores 25.6 percent, what one finished task actually costs and half of them built a ray tracer.