Understanding debt: more AI code, no clear gain in delivery

Adopt AI coding agents and the amount of code grows visibly. Whether the amount of finished work grows with it is much harder to see. Two reports covered in October answer that question with numbers: a paper by two Harvard researchers (version dated August 4, 2026), and a survey that Coleman Parkes ran on behalf of Undo. They use different methods and look at different people, but what happens downstream of the extra volume points in the same direction.

Code grew by about 30%, but completed work did not clearly grow#

The paper uses data from Jellyfish, which sells engineering analytics tools. It covers 718 companies and about 300 million work records from January 2021 to March 2026. It compares before and after adoption, using the fact that companies adopted AI tools at different times. AI usage is observed for GitHub Copilot, Cursor, and Claude Code.

At companies that adopted AI agents, the numbers changed as follows.

Metric	Change after adoption
Lines of code added	Up 30%
Commits	Up 20%
Pull requests (PRs)	Up 23%
Jira issues and features (epics) resolved	No significant change

According to the paper, a Jira issue is resolved when the coding work is deployed to production. In other words, the amount of work that reached production did not increase significantly. The paper estimates that any increase in resolved issues is no more than 12% of the baseline, at the 95% confidence interval. Nothing matching the 30% growth in code was found.

The authors also checked whether issues simply got bigger, so that output grew while the count stayed flat. They found no change in the size of each issue. For autocomplete-style AI assistants, code grew less: 12% in lines, 9% in commits, and 5% in PRs, and only the commit increase was significant.

What grew was review time and rework#

The paper interprets the gap as code review becoming the main bottleneck. Engineers spend 30–42% of their time writing code (the paper’s estimate). If the rest of their time, such as reviewing and coordination, does not change, speeding up only the writing step does little for completed work.

After AI agents were adopted, the average time from opening a PR to merging it grew by 49% (baseline: 7.03 days). The share of PRs that received change requests nearly doubled (baseline: 13%), and review comments per PR rose by 35%. The share of engineers doing code review rose by 14%, so companies were moving people onto review.

AI review is spreading, but people still do most of it. As of March 2026, about 80% of companies had used AI for review, yet AI wrote only 23.3% of review comments, and only 10.8% of PRs got even one AI comment.

Code that reaches production without being understood (Undo’s survey)#

The second report is a survey commissioned by Undo. It covers 300 senior engineering leaders responsible for mission-critical software at large companies with revenue of $250 million or more, and 93% of them work with C/C++. The survey ran in July and August 2026. InfoQ covered it, and the figures are on Undo’s report page.

Here are the main results. 35% of AI-generated code reaches production before the team fully understands it. In a typical week, respondents spend an average of 9.8 hours writing code and 16.9 hours debugging. Debugging breaks down into 9.7 hours during development and 7.2 hours on production issues found by customers, which is 42% of a 40-hour week. 79% said code generation has become much faster, but their release cycles are no faster than before. In the past six months, 93% had at least one case of chasing the wrong root cause because of an incorrect AI diagnosis, and 81% had at least one production incident or outage.

The survey also asked how teams cope. When using AI agents to understand or debug code, the most common technique was having a human approve the agent’s actions, at 66%. Next was adding information about what happened at runtime to logs and source analysis, at 55%. Having a human form the hypothesis and the agent test it, rather than letting the agent hunt for the cause, was 48%, and having a second agent check the work was 40%. The approach that keeps verification entirely within agents was the least common of the four.

Neither report uses the term “understanding debt”. I find it a clear way to connect the two results. When AI writes the code, the work of understanding what it does tends to be skipped. That work does not disappear: it costs time later, in review back-and-forth and in tracking down causes during incidents. The longer reviews in the paper and the debugging hours in Undo’s survey can be read as two different places where that load shows up.

The two reports differ as follows.

	Harvard paper	Undo survey
Method	Analysis of work records (before and after adoption)	Survey of leaders
Sample	718 companies	300 people (large companies, 93% C/C++)
What it measures	Output, review time, rework	Debugging time, incidents, degree of understanding
Caveat	Data runs to March 2026	Undo, which commissioned it, sells a recording tool for debugging

Undo’s survey is self-reported, and the sample leans toward large, mostly C/C++ shops. Its conclusions also overlap with what Undo’s product is used for. Read its numbers as a trend.

What to measure instead of volume#

Lines, commits, and PRs measure only the writing step. In the paper, all three grew by 20% or more, while completed work showed no significant increase. If you measure the effect of AI with these, it looks bigger than it is.

DORA’s software delivery metrics are a starting point for replacements. DORA’s guide lists these five:

• Throughput: change lead time (time from commit to production deployment), deployment frequency, and failed deployment recovery time
• Instability: change fail rate (the share of deployments that need immediate intervention) and deployment rework rate (the share of unplanned deployments made in response to a production incident)

When changes go through PRs, lead time includes the wait for review, so speeding up only the writing step does little for the number. Change fail rate and rework rate may pick up the effect of code that shipped before it was fully understood. DORA’s research finds that speed and stability move together for many teams.

There are caveats. DORA notes that when a metric becomes a target, teams find it easier to game, and that no single metric should be used to measure a complex system. The metrics are meant to be read together.

To get closer to understanding debt, I suggest adding two things. The first is the time from opening a PR to merging it, in days, and the share of PRs with change requests. The paper used these, and you can pull them from GitHub data. The second is recording, in incident reviews, whether anyone on the team could explain the cause, and how many days it took to find it. Both are my own suggestions, and I have not tested whether they work.

I also touched on judging quality and cost side by side in the post on Agent Experience (AX).

Limits to keep in mind#

The Harvard paper’s data runs to March 2026. Ars Technica points out that agent output has improved since then, and that companies that have learned to use agents may find a different balance between reviewing and writing. The paper’s estimates come from observational data, so on their own they cannot tell whether reviews got longer because code quality dropped or because review standards changed.

Even so, judging adoption by writing speed alone misses the load that moved to review and incident response. If you want to look at your own team, you can start by putting PR time to merge and change-request rate side by side, before and after adopting agents.