Over-Editing: a phenomenon where models modify code beyond the necessary scope

Over-Editing is a phenomenon where, beyond the minimal changes needed to fix a bug, models rewrite functions, add auxiliary logic, or even change signatures, producing huge diffs.

The researchers built an evaluation set by programmatically corrupting 400 BigCodeBench problems, breaking correct solutions by, for example, changing < to <=, or + to -. Since there is only one correct answer that reverts the corruption, minimal editing becomes the standard. Minimality was measured using token-level Levenshtein distance, relative patch score, and Added Cognitive Complexity.

In brown-field tasks where existing code must be preserved, passing tests alone is not enough—the scope of change itself must stay small to maintain reviewability and safety. This problem only becomes visible when edit fidelity is evaluated, rather than just correctness.

• A tendency toward excessive rewriting was confirmed across frontier coding models in general.
• Claude Opus 4.6 showed the best balance between correctness and minimal editing, with Pass@1 0.912, Norm. Levenshtein 0.060, and Added CC 0.200.
• GPT-5.4 made the roughest edits, with Norm. Levenshtein 0.395 and Added CC 2.313 in reasoning mode, and 0.327 / 1.563 even in non-reasoning mode.
• Prompts that explicitly instructed preservation of the original reduced diffs particularly for reasoning models, shifting most models toward more minimal edits.

In training experiments, SFT, rSFT, DPO, and RL were compared. rSFT selected only completions with low Levenshtein distance from self-distillation, while DPO contrasted the best completion against the worst. RL jointly optimized a functional-correctness reward and a Levenshtein-based minimal-edit reward.

In-domain, SFT was essentially perfect, with Pass@1 0.932, Norm. Levenshtein 0.002, and Added CC 0.000, but when the corruption type was changed, Pass@1 dropped to 0.458, revealing behavior close to memorizing the inverse transformation.

Out-of-domain, only RL maintained the balance. RL achieved Pass@1 0.782, Norm. Levenshtein 0.050, Added CC 0.185, and a LiveCodeBench change of +0.006, while SFT suffered a 43% performance drop on LiveCodeBench. rSFT and DPO were somewhat better than the baseline but weaker than RL.

LoRA rank 64 came close to Full RL, and as rank increased, Levenshtein and Added CC decreased monotonically. Applying the same recipe to Qwen3 14B also produced improvements, with Pass@1 0.833, Norm. Levenshtein 0.059, Added CC 0.165, and a LiveCodeBench change of +0.011. An initial bug in the reward function caused reward hacking in some LoRA experiments, which led to a fix in the reward formula. Evaluation at the single-function level is narrower in scope than SWE-Bench Pro, but it serves as a practical starting point for quantifying minimal edits.