Code-repair LLMs pass the tests but rewrite far more than the bug requires. A one-line preservation clause in the prompt cuts excess edit distance from 0.195 to 0.131 and, in post-training, RL learns the minimal-edit habit while Supervised Fine-Tuning overfits.
You ship an agent that fixes bugs in a customer’s repo. A ticket says “off-by-one in the slicing.” The agent returns a diff that passes CI but also adds input validation, coerces dtypes, and rewrites a helper. Every extra line is something a human reviewer now has to read, approve, and defend if it breaks something outside the test suite.
Today’s coding benchmarks (HumanEval, BigCodeBench, SWE-bench) mostly ask “did the tests pass?” This paper argues that in brownfield maintenance, patch size is a separate axis of quality, and that current frontier models are bad at it by default.
The authors build a controlled repair benchmark. They take 400 problems from BigCodeBench, and for each reference solution, they inject one or two small Abstract Syntax Tree-level corruptions (flip a comparison operator, shift a slice bound, invert a boolean). They keep the example only if the corrupted code fails the original tests. Because the corruption is known, the minimal correct patch is also known: just reverse it.
They then score model repairs on three axes: Pass@1 for correctness, token-level Levenshtein distance from the corrupted input (compared against the gold repair’s distance, so “excess” means the model changed more than needed), and added Cognitive complexity versus the gold repair. Human annotators confirm excess Levenshtein tracks reviewability at 94.8% agreement.
Two interventions are tested. First, prompting: append one sentence, “but keep as much of the original code as possible.” Second, post-training: fine-tune Qwen3-4B on corrupted DeepCoder samples with four objectives, SFT, rejection-sampled SFT, Direct Preference Optimization, and RL with a Group Relative Policy Optimization (GRPO)-style objective whose reward combines execution success with an edit-size penalty.
# RL reward per sampled repair M
if not passes_tests(M) or not parseable(M):
r = -0.2
else:
e = lev(M, corrupted) - lev(gold, corrupted) # excess edits
r = 0.1 - 1.0 * e # penalize edits beyond the minimal patch
The prevailing view is that if a model’s patch passes the tests, the repair is fine, and any remaining quality issue is a correctness problem to be fixed with a stronger model or more reasoning. This paper shows the opposite. Correctness and edit fidelity are separate axes; a model can nail Pass@1 while quietly rewriting half the function, and neither larger models nor more reasoning tokens fix it reliably. The load-bearing evidence is that one added sentence in the prompt moves 40 of 50 frontier settings toward smaller patches, meaning the behavior is a default framing choice, not a capability limit.
The headline finding is behavioral, not a leaderboard number: a single preservation clause in the prompt lowers aggregate excess Levenshtein distance from 0.195 to 0.131, drops added cognitive complexity by 26.6%, and also raises Pass@1 by 2.3 points. It shifts all 50 frontier model-prompt settings leftward on the edit-size axis. The worst over-editor, GPT-5.5 High, nearly halves its excess distance (0.299 to 0.159); already-faithful Claude Opus 4.7 barely moves.
•
Reasoning is not a fix. Enabling reasoning helps some model families and hurts others; DeepSeek V3.2 gets worse on both metrics under the preservation prompt with reasoning on.
•
Scale is not a fix. On Qwen2.5-Coder from 0.5B to 32B, Pass@1 rises with size but excess distance is non-monotonic, actually rising from 0.108 at 14B to 0.127 at 32B under the generic prompt.
•
Post-training: RL wins the trade-off. SFT nearly solves in-domain corruptions (Pass@1 0.932) but collapses out-of-domain (0.458) and drops LiveCodeBench by 14.9 points. RL reaches 0.782 out-of-domain Pass@1 with 0.050 excess distance and gains 0.6 points on LiveCodeBench.
•
The habit is a small adapter, not a rewrite. LoRA at rank 64 recovers essentially all of full RL’s edit-fidelity gains, suggesting minimal editing is a stylistic preference layered on existing coding skill.
•
Transfers to real bugs. On single-method Defects4J Java bugs (unseen language), RL-trained Qwen3 keeps pass rate flat and cuts excess Levenshtein from 0.114 to 0.060 at 4B.
•
What triggers it. A taxonomy over 530 high-excess passing repairs finds two dominant patterns: defensive generalization (adds validation, checks, fallbacks) at 64.2% and data-flow rewrite (re-solves the task instead of patching locally) at 63.2%.
Reach for this when you’re shipping a repair agent, a lint-fix bot, or any code assistant that edits existing files rather than writing from scratch. The cheap intervention is the prompt: append “keep as much of the original code as possible” to your repair instruction. It costs nothing, works across every frontier model tested, and slightly improves correctness on top of shrinking the diff. If you have training budget and open weights, the paper’s RL recipe (execution reward minus a Levenshtein-excess penalty, Group Relative Policy Optimization (GRPO)-style) transfers as a LoRA adapter without hurting general coding ability.
Code is released at GitHub. The benchmark itself is directly usable: 400 BigCodeBench tasks with injected AST corruptions where the minimal patch is known by construction, so you can score any model’s edit fidelity, not just its pass rate. The corruption families and held-out families are enumerated in the appendix, so you can build your own in-domain/out-of-domain splits.
A patch that passes the tests isn’t necessarily a good patch; measure how much the model changed, not just whether it worked. The default frame a model brings to a repair request is “deliver robust code,” which quietly bloats every diff. One sentence in the prompt, or one edit-size term in an RL reward, retargets it to “restore intent” instead.
•
The corruptions are synthetic single-line AST edits on short functions (mean 10 executable lines). Real bug reports involve fuzzier localization, multi-file changes, and cases where a larger rewrite genuinely is the right fix; the paper explicitly excludes refactoring and feature work.
•
Human validation rests on three annotators judging 100 pairs, plus a single-annotator audit of 100 more. Strong agreement, but small scale.
•
The Defects4J transfer is encouraging but absolute pass rates stay low (7-15%) at the 4B-14B sizes trained, so the “minimal editing generalizes” claim is about relative edit shrinkage, not about a deployable Java repair model.