Skip to main content
AI & Engineering8 min read

Why Does Agentic Code Require More Corrective Maintenance After Merge?

x

xSquad Team

Why Does Agentic Code Require More Corrective Maintenance After Merge?

Agentic code does not usually fail at the pull request stage. It fails after merge. A 2026 longitudinal study of 182 active open-source repositories found that agentic contributions require 46% more corrective maintenance than human contributions after merge, with a 51% higher bug-fix termination rate. The same study reports that agentic commits introduce high-severity Semgrep findings at 1.51 times the per-source-line rate of human commits, and high-severity dependency vulnerabilities at 1.15 times the per-dependency-line rate. The productivity gain is real, but the cost is deferred. Engineering teams that treat merge as the finish line are discovering that the real work begins once the agent has moved on.

Another large-scale study tracked 304,362 AI-authored commits across 6,275 repositories and found that 24.2% of AI-introduced issues were still alive at the latest repository revision. That is 37.25 surviving issues for every 100 AI-authored commits. The conclusion is not that AI coding agents are useless. It is that generation velocity without a corresponding maintenance discipline creates a backlog that human engineers still have to pay down.

What happens to agentic code after it merges?

Merge is the beginning of a contribution's life, not the end. The longitudinal study compared the post-merge fate of agentic and human lines across a one-year window and found that overall maintenance rates were statistically similar: agentic lines were not uniformly more likely to be touched again than human lines. The headline similarity hides an important composition difference. Agentic code receives 46% more corrective maintenance and 51% more bug-fix terminations, while receiving less feature and style work. In other words, humans and agents maintain agentic code, but much of that maintenance is fixing things that should not have been broken in the first place.

A significant share of that corrective work is performed by the agents themselves. Nearly half of agentic line terminations were made by agentic commits, suggesting that agents tend to operate repeatedly on the same agent-authored regions of the codebase. That pattern can look like high activity, but it can also indicate churn around brittle code. The fact that agentic lines survive at least as often as human lines is not evidence of durability. It is evidence that agentic code is being revisited, patched, and rewritten more than the aggregate numbers first suggest.

A separate benchmark of 2.7 million pull requests, 7.5 million commits, and 83,000 developers adds another layer. In elite organizations, agents author up to 4.7% of PRs, and most of the remaining code is human-agent hybrid. Agentic PR merge rates vary sharply by maturity: 79% in elite organizations, 58% in good organizations, and only 37% in fair organizations. The bottleneck is no longer writing code. It is getting agent-written code through review and keeping it healthy after it lands.

Why does agentic code need more fixes?

The root cause is a generation-review asymmetry. Coding agents are optimized to produce functional output quickly. They are not optimized to produce code that ages well. A 2026 empirical study of 304,362 AI-authored commits found that 89.1% of AI-introduced issues were code smells, 5.8% were runtime bugs, and 5.1% were security issues. More than 15% of commits from every major assistant introduced at least one detectable issue, with rates ranging from 17.3% for GitHub Copilot to 28.7% for Gemini. The pattern is consistent across tools. It is systemic, not vendor-specific.

Code smells are especially dangerous because they do not break builds. They accumulate silently. The same study found that 22.7% of AI-introduced code smells survived at the latest revision, compared with 30.3% of runtime bugs and 41.1% of security issues. Security issues are the most likely to persist, which means the cost of skipping review is not just technical debt. It is exposure. When AI-generated code does fix existing problems, it tends to fix simple, repetitive issues such as formatting or naming. For bugs and security vulnerabilities, agents introduce substantially more than they resolve.

As systems grow, the problem gets worse. A separate audit of multi-agent generated systems found a near-perfect relationship between code volume and architectural decay: total lines of code correlated with architectural smells at Spearman's rho = 0.94, and structural smells at rho = 0.59. The researchers call this the Volume-Quality Inverse Law. More code means more god classes, unstable dependencies, scattered functionality, and redundant implementation. Detailed prompts did not help: increasing requirement specificity had no statistically significant effect on smell counts. The limitation is not the prompt. It is the agent's capacity for architectural foresight.

How does no-review culture make it worse?

The maintenance burden is not random. It clusters in projects with weaker engineering safeguards. The 182-repository study tested which project characteristics predicted higher agentic maintenance burden and found that the no-review merge rate was the strongest individual predictor. Each 10 percentage-point increase in a project's no-review rate was associated with roughly a 6% increase in agentic maintenance burden. Projects with higher baseline technical debt and weaker test infrastructure also showed higher burden, though those effects did not reach statistical significance. The direction is consistent: the less human scrutiny applied before merge, the more post-merge cleanup is required.

This is where the generation-review velocity asymmetry becomes expensive. Agents can produce code far faster than humans can review it, and the natural response is to let more code through with lighter review. The data shows that this tradeoff backfires. The LinearB benchmark found that the most effective near-term intervention is treating AI code review as a station in the delivery pipeline rather than a feature teams switch on. Organizations that did this lifted PR yield by up to 5% over the all-PR baseline and by up to 7% over human-only PRs in lower-maturity organizations. Review is not a bottleneck to remove. It is the cheapest instrument for preventing deferred maintenance.

What can engineering leaders do about it?

The fix is not to abandon agentic coding. It is to surround it with the same factory discipline that xSquad applies to autonomous development squads: standardized inputs, standardized tooling, measurable output, and replayability. In practice, that means four shifts.

  • Protect review before you scale generation. The no-review rate is the strongest predictor of post-merge cost. Every agent-authored PR needs a named human owner, the same board visibility as human PRs, and explicit review gates for security-sensitive changes.
  • Instrument delivery, not just output. Counting generated code is the wrong metric. Leaders should track effective PRs, cost per effective PR, rework rate, and the survival rate of AI-introduced issues. These are the metrics that survive an executive review.
  • Make AI code review a pipeline station. Treat automated review as a first-pass filter that reduces the cognitive load on human reviewers, not as a replacement for them. The best results come from pairing AI review with human ownership.
  • Own the context layer. A software factory only works if the system under the agents holds the state of the SDLC and feeds it back. That context layer is what lets teams trace an incident to the PR that caused it, and a security finding to the review that missed it. Our earlier look at why AI adoption can hurt software delivery performance and the agent-native operating model both point to the same conclusion: speed without stability is not delivery.

Organizations that build this discipline now are the ones that will capture the 25-35% throughput gains that early platform adopters report. Those that skip it will spend the next two years refactoring the code their agents wrote in the next two weeks.

Is agentic code worse than human code overall?

Not uniformly. The 182-repository study found that agentic lines were not significantly more likely to be terminated than human lines in aggregate. The difference appears in the type of maintenance, not the volume. Agentic code receives more corrective work and fewer feature or style commits, while human code attracts a broader mix of maintenance. The fair conclusion is that agentic code is faster to produce and more fragile to keep. It is not worse in every dimension, but it is worse in the dimensions that determine long-term cost.

Do all AI coding tools create the same maintenance burden?

The pattern is consistent, but the rate varies. The 6,275-repository study found that every major assistant introduced issues in more than 15% of commits, with Claude averaging 1.96 introduced issues per commit and Devin averaging 0.87. The gap between tools is smaller than the gap between disciplined and undisciplined usage. No tool is a substitute for review, testing, and architectural oversight.

Can automated review fix the problem?

It helps, but it does not close the gap. The LinearB data shows that AI code review lifts PR yield and reduces human review load, especially in lower-maturity organizations. However, the post-merge study found that agentic code still introduced more security and dependency findings even after accounting for file role and repository. Automated review should be the first station in the factory, not the last. Human judgment remains the binding constraint for consequential architectural and security decisions.

How should we measure AI delivery ROI?

The useful metrics are downstream of generation. Effective PRs are merged PRs with rework discounted out. Cost per effective PR divides total engineering cost by that number. Rework rate captures the code that was merged and then rewritten, which is where deferred maintenance first shows up as a number. The new software delivery factory is not measured by how much code agents generate. It is measured by how much of that code actually ships and stays shipped.

Agentic coding is a powerful accelerant, but acceleration without brakes increases the cost of every mistake. The teams that win the next two years will be the ones that treat post-merge maintenance as a first-class engineering outcome, not an afterthought. That is the difference between using agents and running a software factory.

Ready to Scale Your Development Team?

See how xSquad can help you ship production code in 48 hours, not 6 months.