Coding models are judged almost entirely on whether the code works. Researchers at the National University of Singapore asked something else. When a model fixes a small bug in code that already exists, how much of the surrounding implementation does it leave alone?
The setup is clean. They took 400 working Python functions and broke each one deliberately, half the faults a single token. Because they planted the bugs, they knew the smallest correct fix for each, and could measure how far past it every model went.
Frontier models went a long way past it. One off-by-one error needing a single line came back as 60 lines of input validation, type coercion and missing-value handling that nothing had asked for. That patch passed every test the task had. So did the one-line fix.
"Over-editing is therefore a maintenance failure mode: unlike an incorrect answer, a gratuitously large rewrite can still pass tests, making it largely invisible to correctness-only evaluation."
Some of that surplus does damage. Sorting the worst offenders into categories, about a third had changed the function's outputs, side effects or mutation behaviour, and passed anyway. A blinded audit judged the extra code unnecessary in 82% of the cases it could call; the rest were valid alternative fixes.
One sentence recovers much of it. Appending "keep as much of the original code as possible" to the request shrank edits across nearly every model tested, cut added complexity by roughly a quarter, and nudged success rates up rather than down.
"Over-editing is therefore a default editing behavior, not an unavoidable capability limit."
What doesn't help is buying a better model. Reasoning modes improved some families and hurt others, and in one open-weight series the largest model over-edited more than a mid-sized one. On this evidence, the upgrade cycle is not a plan for diff size. Rising pass rates are what a vendor puts in front of you, and they say nothing about how much of your file was rewritten to earn them.
The authors read this as a framing mismatch, in which the model behaves as though asked to harden the code rather than repair it. It's a reasonable guess, but nothing in the setup can confirm it. The study logged what the model wrote, not the reasoning behind it.
Nothing here shows the extra code caused harm, either. Reviewability was settled by three annotators comparing patches side by side, not by anyone reviewing a real pull request or living with the result. That big diffs hide regressions is the study's premise, not its finding.
Two things follow anyway. Put the preservation clause in the system prompt; it costs a line. And resist over-reading the rest, since these were short standalone functions with injected faults, a setting where the smallest fix is the right one by construction. In a real repository those come apart, and a model trained to always change as little as possible will under-fix. The demonstrated default is rewriting too much. That isn't an argument for timidity.
Sources
- Zhu, T., Lim, W. H., Kan, M.-Y., "When Models Edit Too Much: On the Fidelity of Minimal Code Edits" — https://arxiv.org/abs/2609.04061