Large language models increasingly write and repair production code, yet evidence is mounting that their test-passing patches leave codebases harder to maintain. We identify one concrete source: deletion avoidance, the systematic tendency to retain code that an intended edit requires removing. Across the five leading models on the official SWE-bench Verified leaderboard, deletion recall against the developer patch reaches at most 71.7% even on tasks all five solve, and models reach the right file for over 92% of required deletions but cut the exact line in under 52% of cases. Instead, 29.0% of passing patches wrap the targeted code in a guard or fallback, a pattern we call Guard-and-Go. Such patches pass because the original tests rarely check removal: when we retrofit 34 Verified tasks with tests that fail if the targeted code remains, four frontier models spanning closed and open weights fall from 63.2% to 41.9%. Because real repairs mix removal with addition, we curate CanItDelete, a benchmark of 200 tasks mined from real commits whose entire required edit is deletion. Even with the addition work gone, the best model still fails one task in five, and smaller open models fall to 18.0%. We then ablate GPT-5.6 Sol under four cumulative prompts; success moves little until we supply the exact lines, which nearly eliminate incomplete deletion yet raise success only to 80.5% because the model then deletes beyond the spans or adds code instead. Finally, through a pilot study we show one potential fix: teaching deletion during post-training reduces deletion avoidance and improves broader code-editing performance, suggesting the behavior is undertrained rather than beyond reach.
Alex: Welcome to another episode of ResearchPod. Today, we're looking at a study about how AI models write and fix computer code. It turns out that even when these models successfully repair a program, they often leave behind a lot of unnecessary, outdated instructions.
Sam: That's right. The researchers identified a specific problem they call "deletion avoidance." It's a consistent bias where an AI model chooses to keep old, obsolete code in a project instead of just deleting it, even when the task clearly requires removal.
Alex: So this paper is basically asking why AI models struggle to clean up after themselves? And the core problem is that they prefer to keep "junk" code rather than deleting it?
Sam: Exactly. Think about what a program actually is: a set of instructions a computer follows, line by line. When you fix a bug, sometimes the old, broken instructions need to go entirely. But the researchers found that these AI models often can't bring themselves to do that. Instead, they wrap the old code in a kind of bypass—a conditional statement that says "if this condition is false, skip this part." The code is still sitting there, it's just being routed around. The researchers call this pattern "Guard-and-Go." It's like an editor who refuses to erase a typo, instead writing a note in the margin saying "ignore this word." The manuscript looks corrected, but it's actually getting messier with every fix.
Alex: So the program still runs correctly, but the actual file becomes bloated and harder for a human to maintain later on?
Sam: Precisely. The code passes the automated tests—the checks that verify a program does what it's supposed to—so the system marks the task as "resolved." But because the old code is still sitting there, the codebase becomes fragile over time. The researchers tested this directly by creating stricter tests that would fail if any obsolete code remained. When they did that, the success rate of these models dropped significantly.
Alex: Wait— so the failure mode was hiding inside the testing process itself? If the models are passing the original tests, why don't those catch the problem?
Sam: Because original tests are usually only checking one thing: does the program produce the right answer at the end? They don't ask whether the code is clean, or whether there's dead weight sitting inside it. It's like grading a student's essay only on whether the conclusion is correct, without checking if the body of the essay is full of contradictions and crossed-out sentences. To dig deeper, the researchers built a new evaluation called "CanItDelete"—a set of 200 real-world tasks where the entire goal was just to remove code. No new features to add, no complexity to introduce. Just deletion.
Alex: And the models still struggled, even with all that complexity stripped away?
Sam: They did. The models often failed in two ways. Some deleted too much, removing code that was still needed. But more commonly, they added new code instead of just finishing the removal—as if they couldn't resist the urge to write something. That points to what the researchers call an "additive skew." These models are trained on enormous amounts of text and code where the goal is almost always to produce something. Writing, generating, completing. Deletion is the opposite of that, and it seems to run against the grain of how they've learned to operate.
Alex: So it's not just a technical glitch—it's more like a deeply ingrained habit?
Sam: That's a fair way to put it. The researchers tested this further using what they call a "diagnostic ladder." They gave the models progressively more help—first pointing to the general region of code to remove, then the specific lines. Even with that level of guidance, some models still failed by over-editing or adding unnecessary logic. The problem isn't that they can't find the right code. It's that the act of deleting feels unnatural to them.
Alex: That's a meaningful concern if we want AI to help maintain large, complex software systems. Is there any evidence this can actually be fixed?
Sam: There is, and it's encouraging. In a pilot study, the researchers added a small amount of deletion-focused training to one of the models—essentially teaching it that removing code is a valid and valuable action, not just a last resort. The model became noticeably better at clean removal, and that improvement carried over to tasks it hadn't specifically practiced. So deletion isn't beyond these models. It's just a skill that hasn't been prioritized in how they're built and trained.
Alex: You mentioned earlier that some models "over-delete" when they try to fix this. Are we just trading one error for another?
Sam: That's a significant observation from the pilot study. While incomplete deletion dropped, the models started removing too much code in some cases. It suggests that knowing when to delete and knowing exactly where to stop are actually two distinct skills. The model is learning to act, but it hasn't yet mastered the precision of knowing what to leave alone. It's a bit like learning to use a scalpel—first you have to overcome the hesitation to cut at all, and then you have to learn the boundaries.
Alex: So it's not just about getting them to remove code. It's about teaching them the nuance of what to leave alone.
Sam: Precisely. And that nuance matters enormously in real software. A codebase that's been "fixed" by an AI that deletes too aggressively can be just as broken as one that's been left cluttered. The researchers' broader point is that subtraction needs to be treated as a first-class skill—something worth training for explicitly—if we want these models to genuinely maintain and refactor software, rather than just patch it and move on.
Alex: It's a useful reminder that the way we measure success shapes the behavior we get. If we only reward AI for making programs run, we shouldn't be surprised when it ignores everything else. Thanks for listening to ResearchPod.