Merged is not shipped. The AI rework tax your dashboard isn't reading.

The team is faster. The PRs are bigger and arriving more often. The dashboard looks healthier than the sprint feels. And three weeks from now, somebody opens the file from a celebrated AI-assisted feature, finds three patterns nobody can explain, and the cleanup gets quietly added to next sprint as "tech-debt."

That cleanup is the part of the system most teams currently don't measure.

What the recent empirical work actually says

Pham and Ghaleb (2026) analysed 33,596 agent-generated pull requests and 6,618 human-authored ones from the AIDev dataset. Two numbers are worth memorising. The median time-to-removal of symbols (functions, classes) introduced by agents is 3 days, against 34 days for symbols introduced by humans. The symbol-churn rate is 7.33% for agents vs 4.10% for humans. Preprint accepted at MSR 2026, open-source GitHub data with AIDev sampling bias.

A meaningful share of agent-generated code does not survive contact with the next thing the team does. The work was merged. The dashboard moved. The code didn't stay.

Agarwal, He and Vasilescu (2026) used a staggered difference-in-differences design on the same AIDev panel. Their causal-design read is that velocity gains from coding agents are large and front-loaded, but only in repositories where agents are the first observable AI tool. Where teams had IDE-based AI assistants already, the throughput gain is minimal or short-lived. Quality risks are different. Static-analysis warnings rise by roughly 18%, cognitive complexity by roughly 39%, and those changes persist after the velocity boost fades. Preprint, open-source repositories only, measured on repository-month aggregates.

Liu et al. (2026) extended the picture to 302.6k verified AI-authored commits across 6,299 GitHub repositories and five AI coding assistants. Static analysis flagged 484,366 distinct issues introduced. Code smells dominate at 89.3%. More than 15% of commits from every AI coding assistant introduce at least one issue. The most useful figure: 22.7% of the AI-introduced issues are still present at the latest revision of the repository. Preprint, open-source repositories only, static-analysis scope.

That last number is not a defect rate. It is a maintenance load. Slow, mostly silent, paid by whoever opens those files next quarter.

Cotroneo et al. (2025) is the peer-reviewed anchor on the defect profile. More than 500,000 code samples across Python and Java, three SOTA LLMs, defect classification using Orthogonal Defect Classification, security vulnerabilities classified by CWE. AI-generated code is simpler and more repetitive but more prone to unused constructs and hardcoded debugging artefacts and contains more high-risk security vulnerabilities. Human-written code carries more structural complexity and a higher concentration of maintainability issues. Different shape of bugs. Different review costs.

The honest counterpoint

The thesis would be too easy without the rebuttal. Xiao et al. (2026) scanned 200,000 GitHub repositories for self-admitted GenAI usage, found 156 of them, and ran longitudinal churn analysis on 151. They report no general increase in code churn after GenAI adoption. Peer-reviewed, with a self-admission selection bias built into the sample.

The two readings can both be true. Projects that admit GenAI usage are, by selection, projects actively managing GenAI usage. Their result is consistent with the orchestration-matters reading: when AI assistance is governed at the workflow level, the rework signal goes away.

Armesto and Kolb (2026) reinforce that reading from the other direction. Across three industrial modernisation programs (a COBOL banking migration of about 30,000 lines, a 400,000-line accounting modernisation, a 30,000-line .NET/Angular mortgage modernisation), they observed validation-stage issue load fall from 8.03 to 2.09 per 100 tasks after introducing acceptance-criteria validation, repository-native review, and hybrid human-agent execution. First-release coverage rose from 77.0% to 90.5%. Single industrial platform with a commercial incentive, small N at program level, and some outcomes are modeled rather than observed. The direction matches the rest of the evidence.

Putting all six papers next to each other, the cleanest read is this. The rework tax is real, conditional, and moderated by PR size and workflow design. Some teams pay it. Some teams don't. The team that doesn't know which one it is, currently is reading half the system.

Why your dashboard is currently reading half the system

Three reasons.

The PR throughput line goes up reliably under AI assistance. That line is also the easiest one to publish. Most leadership reporting now stops there.

Static-analysis warnings, complexity, and reverts are reported per scan, not per PR. So even when they rise, they don't visibly tie back to "the change we shipped on Tuesday." The accountability link is broken.

Maintenance work that cleans up surviving issues from old PRs is logged as "tech-debt" or "refactor," not as rework of a specific change. So the cost of yesterday's velocity is paid in budget that looks like investment.

The mechanism is Reinertsen's, not new. Rework is a queue forming downstream of merge. Cost of delay multiplied by queue length is the economic cost of that queue, and 22.7% surviving issues (Liu et al.) means the maintenance resource is being fed faster than it drains. If review and maintenance utilisation are above 80%, wait time at those resources grows non-linearly with the increase in arrival rate that AI-generated PRs produce. Variance widens. The right tail of cycle time gets fatter. The same sprint stops finishing the same way.

What a Delivery Manager can pull this week

No new tooling. The team's existing static-analysis output and the Git history of the last 100 merged PRs are enough.

1. Symbol-survival proxy. For each merged PR in the last 90 days, count the symbols it introduced. Count the symbols that have since been removed or rewritten. Compute the survival ratio. Look at the AI-assisted PRs separately from the others. The Pham and Ghaleb gap (3 vs 34 days, 7.33% vs 4.10%) is your reference point.

2. Post-merge issue introduction. Use the team's existing analyser (SonarQube, ESLint, Ruff, golangci-lint, whichever already runs). For each merged PR, compute the warning delta on the affected files. The distribution per PR is the actual per-change maintenance contribution.

3. Post-merge issue survival. For each warning introduced in the last 90 days, check whether it still exists at HEAD. Liu et al. found 22.7% across their sample. Your number is the one that matters. If it is rising sprint over sprint, the maintenance queue is growing.

4. Reopens and reverts. For each ticket closed in the last 90 days, count reopens. For each merged PR, count subsequent reverts or follow-up fix PRs that reference it. This is the operational signal of rework, independent of static analysis.

5. PR-size distribution. Median, 85th percentile, and 95th percentile of diff size of merged PRs. Cynthia et al. (2026) is direct on this: PR size is the dominant moderator of agent-introduced quality cost in their sample of 1,210 agent-generated bug-fix PRs. Preprint. A widening 85th percentile is a leading indicator for items (1) through (4).

Put those five numbers on one page per team per quarter. Read them next to throughput, not instead of it. Don't average them across teams, heterogeneity is the point. A team that is rework-stable can keep going. A team where symbol survival is dropping and issue survival is rising deserves a conversation about review policy, PR-size limits, and agent stopping rules before the maintenance queue gets heavier.

When the framing doesn't apply

Three honest exceptions.

A team with very mature static analysis, mandatory pre-merge gates, repository-native acceptance-criteria validation, and a culture of small PRs is probably already inside the Xiao et al. / Armesto and Kolb boundary. The five numbers will be flat. The framing in this article will tell them nothing new. That is fine. They earned the flat numbers.

A team whose binding queue is decision wait, not rework, lives in the territory of the previous article in this series. Read the slowest fifteen items of the last sixty and tag where they actually spent time. If decision wait wins, fix that first.

A team where the codebase itself is the limiting factor (architectural debt, no test coverage, no analyser running) will not get a clean signal from any of the five numbers. The work there is upstream of AI adoption.

What this is and isn't

It is not an argument that AI assistance is the problem. The DORA 2025 amplifier finding (around 5,000 respondents) is clear that mature engineering systems convert AI into real throughput. Pulling AI out blanket-style loses that gain.

It is not a defence of human-written code as inherently better. Cotroneo et al. found a different defect profile, not a better one.

It is an argument that "merged" is not "shipped that survived," and that the dashboard currently in front of most delivery leaders reads only the first half of that sentence. The five-number rework page is twenty minutes of work to set up and reads the second half. It is the same Monday-morning discipline as the AI-cost log, the decision-wait histogram, and the cycle-time distribution. Same family of measurements. Different queue.

The cheap part of the work moved. The expensive part of the work moved too. The question is whether your reporting did.

Sources

• Agarwal, S., He, H., & Vasilescu, B. (2026). AI IDEs or autonomous agents? Measuring the impact of coding agents on software development [Preprint]. arXiv. arxiv.org/abs/2601.13597
• Armesto, M., & Kolb, C. (2026). Orchestrating human-AI software delivery: A retrospective longitudinal field study of three software modernization programs [Preprint]. arXiv. arxiv.org/abs/2603.20028
• Cotroneo, D., Improta, C., & Liguori, P. (2025). Human-written vs. AI-generated code: A large-scale study of defects, vulnerabilities, and complexity. In 2025 IEEE 36th International Symposium on Software Reliability Engineering (ISSRE) (pp. 252–263). IEEE. doi.org/10.1109/ISSRE66568.2025.00035
• Cynthia, S. T., Muttakin, A., & Roy, B. (2026). Beyond bug fixes: An empirical investigation of post-merge code quality issues in agent-generated pull requests [Preprint]. arXiv. arxiv.org/abs/2601.20109
• DORA. (2025, September 23). State of AI-assisted software development 2025. Google Cloud. dora.dev/research/2025/dora-report
• Liu, Y., Widyasari, R., Zhao, Y., Irsan, I. C., Chen, J., & Lo, D. (2026). Debt behind the AI boom: A large-scale empirical study of AI-generated code in the wild [Preprint]. arXiv. arxiv.org/abs/2603.28592
• Pham, D., & Ghaleb, T. A. (2026). Code change characteristics and description alignment: A comparative study of agentic versus human pull requests [Preprint]. arXiv. arxiv.org/abs/2601.17627
• Reinertsen, D. G. (2009). The principles of product development flow: Second generation lean product development. Celeritas Publishing. search.worldcat.org/title/435994279
• Xiao, T., Fan, Y., Calefato, F., Treude, C., Kula, R. G., Hata, H., & Baltes, S. (2026). Self-admitted GenAI usage in open-source software. IEEE Transactions on Software Engineering, 52, 1891–1910. doi.org/10.1109/TSE.2026.3681886