Accuracy is the only thing anyone measures on a code repair, and it hides a second failure that costs you every time you read a diff. On 400 functions where the correct fix is known to be tiny — 50.2% are a single token and none of them exceeds two lines — frontier models routinely return a rewritten function instead, and the tests go green either way. The cheapest correction turns out to be a clause. Appending keep as much of the original code as possible cut the excess edit distance from 0.195 to 0.131 across 50 model-and-prompt settings, trimmed the complexity the repair added by 26.6%, and raised the pass rate by 2.3 points rather than lowering it. Training the preference in works too, but only reinforcement learning carries it to bugs it has not seen.
The usual problem with judging a patch's size is that nobody knows what size it should have been. This benchmark removes that. Take 400 problems from a Python function benchmark, corrupt the reference solutions at the syntax-tree level, keep only the cases where the corrupted version now fails the original tests, and you have a repair task whose minimal correct patch is known exactly: it is the reversal of the corruption you injected.
The scale of the correct answer is the thing worth holding on to. Half the tasks are fixed by changing a single token. Nine in ten are fixed by changing at most two. Not one of them needs more than two lines, in functions that average ten executable lines to begin with. Whatever a model returns beyond that, it chose to.
With a known gold patch you can define the overshoot directly. Measure how far the corrupted code is from the gold repair, measure how far it is from what the model returned, and subtract. Zero means the model changed exactly as much as the fix required. Positive means it changed more. The paper calls it excess edit distance, and runs the same subtraction on a structural complexity score to catch repairs that add branching rather than characters.
The two numbers move independently, which is the point. The strongest passer in the set is not the tidiest editor: one model clears 82.3% of the tests while overshooting by 0.299, and another passes 76.0% while overshooting by 0.074 — four times less. High accuracy and unnecessarily large edits sit happily side by side, because nothing in the scoring has ever penalised the second.
Before trusting the metric, the paper checks it against people. Asked which of two repairs is easier to review, human majority agrees with the lower excess distance in 94.8% of the cases where reviewers reached a decision, at a Cohen's kappa of 0.897; on which repair is more faithful to the original intent, 96.9% and 0.939. This is a proxy, but a well-behaved one.
The generic prompt says: fix and complete my function. The preservation prompt says the same thing and adds but keep as much of the original code as possible. That is the whole treatment. Pooled over 50 model-and-prompt settings it takes the excess edit distance from 0.195 to 0.131, a third less, and cuts added complexity by 26.6% — while the pass rate goes up by 2.3 points.
The size of the effect depends on how badly the model was overshooting to begin with. The model that already returned near-minimal patches barely moves, 0.074 to 0.070 — there was nothing to take away. The worst offender roughly halves, 0.299 to 0.159. If your model is already tidy the clause is free; if it is not, it is the largest single change available to you and it costs one line of prompt.
If a clause helps, training should help more. The paper trains a 4B model four ways on 4,141 examples and evaluates on two splits: 400 problems using corruption types the training saw, and 400 using corruption types held out. The gap between those two columns is the entire result.
Supervised fine-tuning produces the most impressive-looking row in the table and the least useful one. It reaches 0.932 on corruption types it has seen, with an excess of 0.002 — essentially perfect minimal editing — and then falls to 0.458 on held-out types, while dropping 14.9 points on general coding ability. It memorised the corruptions. Reinforcement learning gives up the headline number, holding about 0.78 on both splits with an excess near 0.05, and it is the only method that does not damage the model at everything else: plus 0.6 points on the general set.
Rank one is not enough — the model passes less and overshoots three times as much as rank sixty-four. From rank sixteen upward the curve flattens, and full-parameter training buys nothing over a rank-64 adapter. Minimal editing is a small preference to install, not a capability to grow.
Three interventions come out of this paper at three different prices, and the cheapest one is available to everyone reading. Pick where you are.
The second half of it is measurement. Excess edit distance needs a known-good patch, which you do not have in production — but the same shape of check works on what you do have: how much of the diff touches lines the failing test never exercised, or how far the patch reaches outside the function named in the issue. Pick a scenario and compare the two habits.
The scenarios are illustrative — the paper measures function-level repairs on a benchmark, not pull requests on your repository. What it measures is the premise underneath them: the pass rate does not tell you the patch is small, the two come apart badly on frontier models, and one clause moves the second without costing you the first.