Over-Editing: Why Your AI Coding Agent Rewrites What Isn't Broken

Last updated: September 7, 2026. The original nreHieW essay is now backed by the EMNLP 2026 arXiv paper, a Hugging Face Papers listing, and the public Apache-2.0 code repository. Google Trends was required for this automation lane, but the current run did not get reliable numeric rows from Trends, so no search-volume numbers are used in this refresh.

The bug you asked to fix is one line. The diff is fifty.#

If you have spent any time with Claude Code, Cursor, Codex, or GitHub Copilot in the past year, you have lived this moment. You point the agent at a simple off-by-one. You ask for the minimal fix. The bug gets fixed. And then you scroll the diff and half the function is gone. A helper you did not request has appeared. A variable has been renamed because the model thought the new name was clearer. Input validation has been bolted onto a path that never needed it. The whole shape of the function has changed.

The idea started as nreHieW's minimal-editing essay. It has now become an EMNLP 2026 paper: When Models Edit Too Much: On the Fidelity of Minimal Code Edits. The paper keeps the useful framing from the original post and turns it into a cleaner benchmark: correctness is not enough for code repair if the model rewrites more than the fix requires.

That makes this more than an annoyance with AI coding tools. It is a measurable code-review failure mode.

What over-editing actually is#

The author defines over-editing precisely: a model is over-editing if its output is functionally correct but structurally diverges from the original code more than the minimal fix requires.

The demonstration example is brutal. The bug is a single off-by-one: range(len(x) - 1) should be range(len(x)). The minimal fix is one character. GPT-5.4 with high reasoning effort responds by rewriting the entire function. It adds None checks that nobody asked for. It converts arrays with np.asarray and explicit dtype=float. It adds finite-value masking. It validates array sizes. It changes the signature of the curve_fit call. It replaces the plotting logic entirely. The output passes the tests. The output is a disaster to review.

This is the kind of failure that tests cannot catch. If the code is functionally correct, every green check still turns green. Pass@1 can stay high. The reviewer is the only line of defense, and the reviewer is now staring at fifty changed lines trying to figure out which one fixed the bug and which forty-nine are new surface area to audit.

Why tests cannot save you#

The default advice for working with AI coding tools is "just write more tests." The logic is that if your tests are good enough, the model cannot ship anything broken past them. That advice is correct but incomplete.

Over-editing is a brown-field failure. The existing code was already understood, was already written the way it was for reasons the team chose deliberately, and was already part of the codebase's shape. The model's job was to fix the bug and nothing else. Instead it made fifty decisions the team did not make and signed your name to them.

Tests verify correctness. They do not verify restraint. They cannot tell you whether the model respected the shape of your code. They cannot tell you whether a refactor snuck in under the cover of a bug fix. They cannot tell you whether the variable names drifted. That verification has to happen in code review, which is already the bottleneck on most teams, and which over-editing makes dramatically more expensive.

Why models do it#

There are three plausible explanations, and my read is that all three are happening at once.

First, training incentive. Most preference data rewards thorough, helpful-looking answers. A diff that adds validation, handles edge cases, and improves the function feels more effortful than a one-character change. Annotators can give it higher marks. The model learns that big diffs win.

Second, reasoning models are worse. The author calls this out directly. High-reasoning-effort settings make the over-editing problem worse, not better. The model reasons its way into additional changes that feel defensible in chain-of-thought but that were never requested. Reasoning without constraint is expansion without permission.

Third, context loss. Models do not always fully load the context of what the existing code is doing before editing. They regenerate the function from scratch, approximating it, and then merge their approximation back. What looks like a targeted edit is actually a regeneration with drift baked in.

None of those causes go away on their own. The open question is whether we can train for restraint.

What the paper measures#

The experimental setup is a clean piece of work. Rather than using another LLM to introduce bugs, the authors programmatically corrupt 400 problems from BigCodeBench. Corruptions are tiny and mechanical: flipping < to <=, swapping + for -, changing True to False. Each corrupted sample remains syntactically valid and is verified to break the corresponding test cases. The ground-truth edit is therefore exactly the reversal of the corruption and nothing more. The minimal edit is defined by construction.

The metric is token-level Levenshtein distance on the Python tokenizer output, not raw character distance. This matters because a rename from add to someotherfunctionname is character-level huge but token-level tiny. Token-level Levenshtein captures the kind of structural change that actually matters for review.

Crucially, the author measures both the model's output against the ground truth and the model's output against the corrupted input. This gives you a clean signal on how much the model diverged from the minimal edit, independent of whether it got the bug right.

The September 2026 paper adds several numbers worth preserving. Across frontier models, high Pass@1 can coexist with unnecessarily large edits and added cognitive complexity. A preservation instruction reduced average excess Levenshtein distance from 0.195 to 0.131, reduced added cognitive complexity by 26.6 percent, and increased Pass@1 by 2.3 points. The authors also report that supervised fine-tuning overfits to seen corruption patterns, while reinforcement learning gives the better out-of-domain trade-off.

That last point is the real update. Minimal editing is not just a prompt hygiene problem. The paper treats edit fidelity as a trainable axis of code-repair quality.

What developers should actually do#

You cannot fix this at the model level. You can work around it at the workflow level, and several of the mitigations are cheap.

First, prompt for restraint explicitly. The instruction "make the minimal change required to fix this bug. Do not rename, refactor, or add validation unless I ask." is not a magic spell, but it measurably reduces over-editing on Claude Code and Cursor in informal testing. Put it in your system prompt or your CLAUDE.md. Do not assume the model defaults to restraint.

Second, review the diff before you review the result. Pass@1 success tells you nothing about how much noise the model produced getting there. Look at the diff size. If the diff is larger than the bug, read it line by line. If the diff is larger than ten lines for a single-character bug, revert and re-prompt.

Third, keep bug-fix commits and refactor commits separate. If the model wants to clean up the function, let it, but in a separate commit that you can review as a refactor. Do not let refactors tunnel under bug fixes into the history. Future you, reading git blame in six months, will thank present you.

Fourth, turn down the reasoning dial. Counterintuitively, lower-reasoning-effort settings often produce cleaner diffs than high-reasoning-effort settings on small bugs. If your agent has a reasoning slider, use it. A maximum-reasoning agent is not always the agent you want on a two-character fix.

Fifth, consider tools that scope the agent's edit surface. The new generation of agent harnesses is experimenting with edit-range constraints, where the agent literally cannot modify lines outside a specified span. That is a more durable solution than prompting and one worth tracking as the primitives mature.

Sixth, add an edit-fidelity check to agent reviews. A pull request from an agent should answer a simple question before anyone reads the implementation: what was the expected minimal change, and how far did the actual diff move from it? This does not need a research-grade Levenshtein metric on day one. A reviewer-facing receipt that lists touched files, changed line count, renamed symbols, new helpers, and added branches catches most of the pain.

That connects directly to agent eval receipts, Dockerless verification, and Harness Handbook's behavior maps. The more autonomy you give a coding agent, the more you need review signals that measure behavior beyond "tests passed."

The deeper point#

Every coding agent we use today is mostly optimized for passing tests. Few are optimized for minimal diffs. The benchmarks that the industry reports are pass rates, not edit distances. Until the scoreboards change, the model behavior will not change.

The nrehiew essay is useful because it argues for a second axis on the scoreboard. Correct and minimal, not correct or maximal. If that framing catches on in the next wave of benchmarks, the shape of the agents we build will follow. In the meantime, the restraint has to come from the prompt, the review, and the commit discipline.

If you are shipping with an AI coding agent in production, this is a problem worth understanding now. Not because it blocks the work, but because it quietly makes every code review, every merge conflict, and every history bisect more expensive than it needs to be.

Read the full essay. It is worth the twenty minutes.

Frequently Asked Questions#

What is over-editing in AI coding agents?#

A model is over-editing if its output is functionally correct but structurally diverges from the original code more than the minimal fix requires. The bug gets fixed, but a helper you did not request appears, a variable is renamed because the model thought the new name was clearer, and input validation is bolted onto a path that never needed it.

Why cannot tests catch over-editing?#

Tests verify correctness. They do not verify restraint. If the code is functionally correct, every green check still turns green and Pass@1 can stay high. Tests cannot tell you whether the model respected the shape of your code, whether a refactor snuck in under the cover of a bug fix, or whether variable names drifted. That verification has to happen in code review.

Why do AI coding models over-edit?#

Three causes are happening at once: training incentive, where RLHF rewards thorough, helpful-looking answers so the model learns that big diffs win; reasoning models are worse, because high-reasoning-effort settings make over-editing worse, not better; and context loss, where models regenerate the function from scratch and merge their approximation back, baking in drift.

How can developers reduce over-editing?#

Prompt for restraint explicitly with an instruction like "make the minimal change required to fix this bug. Do not rename, refactor, or add validation unless I ask." Review the diff before you review the result. Keep bug-fix commits and refactor commits separate. Turn down the reasoning dial, since lower-reasoning-effort settings often produce cleaner diffs on small bugs.

Does higher reasoning effort produce better code edits?#

No. Counterintuitively, lower-reasoning-effort settings often produce cleaner diffs than high-reasoning-effort settings on small bugs. High-reasoning-effort settings make the over-editing problem worse, because the model reasons its way into additional changes that feel defensible in chain-of-thought but that were never requested. A maximum-reasoning agent is not always the agent you want on a two-character fix.

Continue Reading#

• Aider vs Claude Code: 2026 Update
• Best AI Coding Tools in 2026
• AI-Native Development Workflow
• Dockerless Verification Is The Next Coding Agent Bottleneck
• Harness Handbook Shows the Missing Map for Coding Agents
• Diffs vs Whole Files: What Code Editing Agents Should Rewrite - when a coding agent should rewrite the whole file and when a diff edit is safer, routed by task locality

Sources#

• When Models Edit Too Much: On the Fidelity of Minimal Code Edits, arXiv, submitted September 3, 2026 and accessed September 7, 2026.
• When Models Edit Too Much on Hugging Face Papers, accessed September 7, 2026.
• nreHieW/over-editing, GitHub repository, accessed September 7, 2026.
• Coding Models Are Doing Too Much, original research essay, accessed September 7, 2026.
• BigCodeBench, benchmark repository, accessed September 7, 2026.
• Hugging Face July 2026 monthly papers, accessed September 7, 2026.