TL;DR
When you ask an LLM to fix a bug in code, the model often rewrites far more than it needs to. This is called over-editing. A simple addition to the prompt, explicitly asking it to preserve the original code and change only what's necessary, noticeably curbs the model's habit of "improving things while it's at it."
The example from the paper says it all: a function had a one-line bug (an off-by-one error), and it really could be fixed by changing a single line. Instead, GPT-5.4 deleted 5 lines and added 60: input validation, type casting, missing-value handling, recalculating the curve. All the tests passed, which means correctness doesn't guarantee minimality: the model behaves as if it had been asked to write "robust production code" rather than surgically fix one specific line.
Adding one sentence to the prompt, "preserve as much of the original code as possible and change only what's necessary," cuts the volume of unnecessary changes by almost a third and even slightly improves fix accuracy.
Method Blueprint
This isn't a multi-step technique; it's one addition to an ordinary prompt:
STEP 1: State the task as usual: "here's the code, here's the bug, fix it"
STEP 2: Add an explicit condition: "preserve as much of the original code as possible, change only what's necessary" → the model switches into targeted-fix mode instead of rewriting
Example in Action
Task: You have a Python script that parses an Amazon order export and calculates discounts. One line has a bug: a comparison uses < instead of <=, so items with the maximum discount don't make it into the report.
Prompt:
Here's a Python function. It has a bug: items with the maximum discount (100%)
don't make it into the final report.
def calculate_discount_report(orders):
result = []
for order in orders:
if order['discount'] < 100:
result.append(order)
return result
Fix this bug, but preserve as much of the original code as possible:
change only what's necessary for the fix. Don't add
extra validation, error handling, or new logic
unless the tests require it.
Result: The model will change < to <= on one line and leave the rest of the function untouched. Without the second half of the instruction, there's a high risk that the model will "while it's at it" add an empty-list check, None handling, and logging, and rename the variables, turning the patch into a refactor that takes ages to review.
Why It Works
By default, an LLM reads the task "fix the bug" not as "make a minimal, targeted change" but as "write good, robust code." Once it spots the bug, the model notices other potential weaknesses along the way (missing checks, sloppy edge-case handling) and fixes those too, even though nobody asked.
The model's actual bug-finding works fine. The problem isn't that it can't see the error; it's that it doesn't keep itself within the scope of the task.
Models respond well to explicit, concrete constraints in the prompt text. The sentence about preserving code changes what the researchers call task framing: the model starts treating the existing code as something to protect rather than a draft to improve.
Control knobs: - Want to see exactly what the model changed and why → ask it to add a short comment to each changed line - Working with text rather than code (a contract, an article, an email) → the same sentence works: "fix only this error, don't rewrite the rest of the text" - If the change really should be large-scale (a refactor, not a bug fix) → leave this instruction out; it'll get in the way
Prompt Template
Here's the {code/text}: {paste the content}
Problem: {description of the bug or error}
Fix this problem, but preserve as much of the original
{code/text} as possible: change only what's necessary for the fix.
Don't add extra logic, checks, or improvements
unless the task requires them.
Put whatever you're working on into {code/text}: a script, a formula, a paragraph of a contract. In {description of the bug}, say what exactly is going wrong.
Limitations
⚠️ Tested only on code: the study looked at short functions (10 lines on average). The effect on large files or complex multi-file edits wasn't studied.
⚠️ It reduces the problem but doesn't eliminate it: over-editing remains, there's just less of it. It's not a complete fix.
⚠️ Newer and "smarter" ≠ tidier: stronger reasoning models don't always make smaller edits. The effect depends on the specific model, not on how powerful it is.
⚠️ Training the model to do this on its own (without a prompt) through reinforcement learning requires code and infrastructure. That doesn't apply in an ordinary chat, unlike a simple prompt addition.
How They Studied It
The researchers took 400 tasks from BigCodeBench and deliberately "broke" the correct reference solutions by injecting a controlled bug at the level of the code's syntax tree. As a result, for each task the minimal patch that restores working code is known exactly: it's simply undoing the injected damage.
They ran more than 20 top models (GPT-5.5, Claude Opus, Gemini, DeepSeek, and others) in two modes: a plain "fix the bug" request and a request with the code-preservation addition. They measured three things: whether the tests pass, how large the edit is compared with the minimal one (computing the token-level distance between code versions), and how much more complex the code's logic became after the edit. Human developers separately confirmed that this over-editing metric matches their own judgment of "is this easy to review" and "was the original intent preserved," with nearly 95% agreement.
The result was surprising: a high test pass rate doesn't guarantee a tidy edit. GPT-5.5 in high-effort mode fixes bugs superbly, but its volume of unnecessary changes is four times that of Claude Opus at similar quality. Adding one sentence about preserving code cut over-editing by almost a third and slightly improved accuracy, and the effect held across repeated runs and different wordings of the same request.
Resources
When Models Edit Too Much: On the Fidelity of Minimal Code Edits. Tongyao Zhu, Wei Hern Lim, Min-Yen Kan, National University of Singapore. Code: github.com/nreHieW/over-editing