Security , Agentic AI , Software development Aug 05, 2026

Why AI Coding Agents Refuse to Delete Your Code (And What That Costs You in Production)

VECTOR Labs Team

Last updated on: Aug 05, 2026

Engineering leaders evaluating AI coding tools have largely settled on a familiar set of success metrics: task completion rates, benchmark scores, and time-to-merge. Those metrics capture something real, but they are systematically blind to a failure mode that accumulates quietly in production codebases. Models that resolve issues and pass tests are not the same as models that leave code in a state a senior engineer would accept. The gap between those two things has a name, a measurable magnitude, and a commercial cost that most ROI frameworks do not account for.

Companion piece to our broader work on AI coding tool governance. See Why AI-Generated Code Is Making Your Review Process Slower, Not Faster for a practical analysis of how high-volume AI diffs are degrading code review throughput and what process disciplines teams need to reimpose.

The Deletion Problem Is Structural, Not Incidental

When a model edits code to fix a bug or implement a change, the correct patch often requires removing lines, not just adding them. Deletion is the harder half of editing. It requires the model to commit to the judgment that something should no longer exist, rather than hedging by keeping the original code alongside the new version.

Research published in 2026 measured this directly across the five leading models on the SWE-bench Verified leaderboard. Even on tasks that all five models solved, deletion recall against the developer-authored patch reached at most 71.7% (Ebrahimi et al., arXiv 2026). Models located the right file in over 92% of cases requiring deletion, but cut the exact line in fewer than 52% of cases. The capability to find the problem and the willingness to remove it are two separate behaviours, and the second one is consistently underdeveloped.

The mechanism is not mysterious. Models are trained on corpora that reward producing code, not removing it. Deletion carries a higher perceived risk of breaking something, and the training signal for cautious addition is stronger than the signal for confident removal.

Guard-and-Go: The Failure Pattern Your Tests Cannot See

The most commercially significant consequence of deletion avoidance is a pattern the research labels Guard-and-Go. Rather than removing code that should be deleted, the model wraps it in a conditional guard or fallback so the original path is still reachable. The patch passes tests because the new logic executes correctly. The old logic remains because no test checks for its absence.

Ebrahimi et al. found this pattern in 29.0% of passing patches across the five models studied. That is not a rare edge case. It is a systematic outcome that occurs in roughly one in three successful task completions, and it is invisible to standard test suites.

The practical implication is that a model with a high benchmark score can be simultaneously accumulating dead code, unreachable branches, and deprecated logic paths at scale. Each individual instance is minor. Across thousands of agent-authored commits over months of production use, the aggregate effect on codebase legibility and maintainability is material.

What Current Benchmarks Are Not Measuring

The SWE-bench Verified suite is the closest thing the industry has to a rigorous standard for coding agent evaluation. It is genuinely useful for measuring whether agents can resolve issues. It is not designed to measure whether the resolution is clean.

When Ebrahimi et al. retrofitted 34 Verified tasks with tests that specifically fail if the targeted code remains in place, four frontier models dropped from a combined pass rate of 63.2% to 41.9%. The benchmark score did not change. The underlying behaviour did not change. Only the measurement changed, and the measured performance fell by more than a third.

What CanItDelete Reveals

The same research introduced CanItDelete, a benchmark of 200 tasks drawn from real commits where the entire required edit is a deletion. Removing the addition work isolates whether models can commit to removal on its own terms. The best model still failed one task in five. Smaller open-weight models fell to an 18.0% pass rate.

These numbers matter for procurement decisions. A model that scores well on SWE-bench Verified but fails 20% of pure-deletion tasks will produce a codebase that diverges from developer intent in ways that compound over time. The velocity gain from agent-authored commits is real, but the maintenance cost of the accumulated residue is not captured in the headline metric.

The Commercial Calculus Engineering Leaders Are Missing

The standard ROI case for AI coding tools rests on throughput: more issues resolved per engineer per sprint, faster time-to-merge, reduced backlog. That case is not wrong, but it is incomplete. It treats the codebase as a pipeline output rather than a long-lived asset.

Technical debt introduced by deletion avoidance does not appear in sprint metrics. It appears in the cost of the next feature that has to navigate around retained dead code. It appears in the review time spent understanding why a patch added a guard instead of removing the original. It appears in the onboarding cost for engineers who inherit a codebase where the intended state of the code is obscured by layers of conditional fallbacks.

Research on agent-authored pull requests found that maintainers merged already-passing agent PRs at a rate 24 percentage points below the benchmark score, with reviewers citing verbosity and departure from repository conventions as the primary reasons (Ebrahimi et al., arXiv 2026). That gap is a direct measure of the hidden cost: the agent resolves the issue, but a human still has to decide whether the resolution is acceptable, and frequently concludes it is not.

Governance Checkpoints That Catch What Tests Miss

The practical response is not to stop using AI coding tools. It is to instrument the evaluation layer that sits between agent output and merge. Standard CI pipelines check correctness. They do not check deletion completeness, patch verbosity, or the presence of Guard-and-Go patterns.

Engineering leaders should consider three additions to their review governance:

Deletion coverage analysis: track whether the lines a patch was expected to remove were actually removed, not just whether new logic was added.
Patch verbosity review: flag patches where line additions significantly exceed the line delta implied by the issue description, as a signal that guards may have been added instead of deletions made.
Periodic codebase archaeology: audit for unreachable branches and deprecated logic paths that postdate the deployment of coding agents, to establish a baseline for the debt accumulation rate.

None of these checkpoints require new tooling from scratch. They require treating the codebase health dimension of agent output as a first-class measurement concern, with the same discipline applied to correctness today. The research suggests that deletion avoidance is an undertrained behaviour rather than a fundamental model limitation, which means the failure mode will improve as post-training practices evolve (Ebrahimi et al., arXiv 2026). Until it does, the governance layer is the practical mitigation available to engineering leaders now.

FAQs

How do we know whether our current AI coding tool has a deletion avoidance problem?

The most direct signal is to audit a sample of agent-authored patches and compare them against the developer patches for the same issues, counting whether the lines marked for removal in the reference patch were actually removed. A secondary signal is the prevalence of conditional guards added around code that the issue description implied should be removed outright. If either pattern appears consistently, you have a measurable deletion avoidance problem regardless of what the tool's benchmark score says.

Does this problem affect all models equally, or are some significantly better than others?

The research measured deletion recall across the five leading models on SWE-bench Verified and found variation, but no model reached acceptable levels on its own. The best deletion recall observed was 71.7% even on tasks all five models solved, and pure-deletion task performance ranged from roughly 80% for the best model down to 18% for smaller open-weight models. The problem is structural across the current generation of models, not isolated to specific vendors.

Why don't existing test suites catch Guard-and-Go patches?

Standard tests verify that the correct behaviour executes, not that the incorrect behaviour has been removed. A Guard-and-Go patch routes execution through the new logic path, so the test passes. The original code remains reachable via the guard condition, but no test exercises that path specifically to confirm it is gone. Catching this requires tests that are written to fail if specific code still exists, which is not a standard part of test suite design and was not present in the original SWE-bench Verified tasks.

How should we adjust our AI coding tool ROI calculation to account for this?

The adjustment requires adding a debt accumulation cost to the denominator of the ROI calculation. Estimate the rate at which agent-authored patches introduce retained dead code or guard patterns, then apply your organisation's known cost of carrying technical debt per unit of codebase complexity. That cost should be offset against the throughput gain. In practice, most organisations do not have a precise debt cost figure, so a reasonable starting point is to track review rejection rates and time-to-merge for agent PRs versus human PRs, since the gap between those two numbers is a direct measure of the hidden overhead.

Is this a problem that will be solved by better prompting?

Prompting helps at the margins but does not resolve the underlying issue. Research testing four cumulative prompt improvements, up to and including supplying the exact lines to be deleted, moved success rates only modestly until the exact lines were provided, and even then the best result was 80.5%, with the model then sometimes deleting beyond the specified spans or substituting additions for deletions. The evidence points to deletion avoidance being an undertrained behaviour that requires post-training intervention to address properly, not a prompting problem that engineering teams can engineer around in production.

What governance changes are realistic to implement without significant process overhead?

The lowest-overhead starting point is to add a deletion coverage check to the PR review checklist for agent-authored commits, requiring reviewers to confirm that lines flagged for removal in the issue description were actually removed. This does not require new tooling and takes less than two minutes per PR. The higher-value but higher-effort addition is a periodic codebase audit specifically targeting unreachable branches and deprecated logic paths that postdate your agent deployment, which gives you a quantified baseline for the debt accumulation rate and a basis for adjusting your tool evaluation criteria going forward.

A team that understands you

With 20+ years of experience in the world's leading consultancy companies, implementing AI and ML projects in industry-specific contexts, we are ready to hear your challenges.

Talk with an AI expert