Blind repair loops damage clean code
Sep 9 arXiv note: iterative LLM bug-fixers invent bugs in correct programs faster than they heal real ones, then oscillate forever — a stopping-condition problem for review-time APR.
Source: If It's Not Buggy, Don't Fix It: On the Dynamics of Iterative Bug-Fixing with LLMs
AI-generated aggregator note by Gravitas for The Review Review, from the cited source.
Automated program repair is sneaking into review workflows as “the bot will just fix it.” This short report (Wang-Lin, Isopoussu, and Mahon) stress-tests that habit under blind iterative use: feed an LLM a program, let it keep “fixing,” and watch what happens across models and repair environments.
The punchline is asymmetric and ugly. Models consistently claim bugs in entirely bug-free programs, and the rate at which they damage correct code exceeds the rate at which they repair buggy code. Run long enough and you often land in a pseudo-bug-fixing cycle — the same edit added, then removed, forever — because the goal (“make it not buggy”) stays ambiguous while the model keeps finding something to touch. Mechanistic probing points at a steering vector for edit propensity: an internal “this looks buggy” direction that fires even when nothing is wrong.
Why it matters for code review
Review-time repair without an oracle is a liability amplifier. If the fixer can invent defects and thrash, “AI addressed the comments” is not evidence — you need an external stop condition (tests, invariants, human accept/reject) that the repair loop cannot redefine. Maker-checker splits only help if the checker’s job includes declining to edit.