People have a well-documented bias toward adding rather than taking away: asked to improve something, we reach for a new part before we think about removing one. A new study finds coding models have picked up the habit, and that the benchmark the industry quotes can't see it.
The researchers compared the five leading SWE-bench Verified submissions, the leaderboard vendors cite when they say their agent resolves real GitHub issues, against the fix the human maintainer shipped. On tasks all five models solved, the models left roughly a third of the developer's deletions sitting in the codebase. They weren't failing to find it: they edited the right file almost every time, and usually the right function, yet cut the exact line only about half the time.
What they wrote in place of the deletion was, of course, an addition. In 29% of passing patches the model kept the logic the developer removed and added a condition routing execution around it, a pattern the authors call Guard-and-Go. Its most common form leaves the retired code as the live default path, the new guard handling only the case in the bug report.
"Such patches preserve a developer-removed path in executable form, so a reader must judge whether both the original and the newly introduced paths remain necessary."
These patches pass because nothing checks. A test suite asserts behaviour is correct; it has no opinion on whether a line is still there. Retrofit those tasks with a check that fails if the target code remains, and a third of the patches the original suites had waved through stop passing.
Resolution rates measure whether tests went green, and Guard-and-Go goes green. Any vendor number sourced from a passing suite is silent on whether the change left the codebase where a maintainer wanted it, however high the number climbs.
The damage is worse than ordinary bloat. Code that's plainly dead can be deleted later by anyone brave enough. Code left behind a guard is reachable, so the next person can't remove it without first proving no input still gets there. Every avoided deletion turns a one-line cleanup into archaeology, handed to a reviewer already working through a patch half again larger than the human version.
Two things follow. When a ticket says remove or deprecate and the agent returns a diff that's almost all additions, review it closely whatever the tests say. And track deletion ratio against what humans remove on similar work: cheap to measure, and more telling about maintainability than acceptance rate.
Where this will get over-read: a retained path isn't automatically a bug. Sometimes a guard is the better repair, and the paper is careful to call the developer's patch a reference, not the only right answer. The problem is that no one in the chain ever asked: not the model, not the tests, not the leaderboard.
Nor is it confusion about the instruction. Stripped down to pure removal, whole file supplied and nothing to build, the best model still failed one task in five. Handing over the exact lines to cut mostly fixed that and produced a new failure: models started deleting past the boundary.
"Deletion fails on both sides: too little when the boundary is uncertain, too much once it is given."
The good news: this looks like a training gap, not a hard limit. Adding deletion examples worth under 1% of a small model's post-training data cut the behaviour and raised its score on general repair work too. One pilot, one small model, so it's a direction rather than a result. But it suggests coding agents don't delete mostly because nobody has taught them to.
Sources
- Ebrahimi, A. M., Hasan, M. M., Bhatia, A. et al., "To Add Is Machine, To Delete Is Human: Measuring and Mitigating Deletion Avoidance in LLM Code Editing" — https://arxiv.org/abs/2607.28887