AI Coding Agents Add 30% More Code — Review Eats It All

Your coding agent wrote 30% more code this month. Congratulations — your team shipped nothing extra.

That's the headline from a Harvard working paper that started circulating last week. Economists Fiona Chen and James Stratton paired engineering telemetry from Jellyfish with GitHub activity across 718 software companies — roughly 300 million work events from more than 700,000 engineers, January 2021 through March 2026 — and asked the question every engineering leader is quietly asking: did the agents actually buy us more software?

The answer is uncomfortable. After firms adopted tools in the Claude Code, Cursor, and Devin class, each developer wrote about 30% more code, opened 20% more commits, and filed 23% more pull requests. All statistically significant, estimated with a staggered difference-in-differences design that compares firms as they adopt at different times. Meanwhile the authors' proxy for shipped software — resolved Jira issues and completed epics — didn't move. Not "moved a little." No statistically significant change at all, with any rise above 12% ruled out. Employment didn't fall either: nobody got replaced, nobody shipped more.

Where the 30% went

Downstream. The average time between a pull request being submitted and merged rose 49%. The share of PRs sent back for revision nearly doubled. Comments per pull request climbed 35%. And 14% more engineers got pulled into review work. The constraint moved from writing code to reading it.

Here's the detail that should worry tool vendors most: by March 2026, 80% of the firms in the sample were already running AI code-review tools. It didn't clear the jam. Only 23% of review comments were AI-generated, and humans kept the final sign-off. Throwing a second agent at the review queue doesn't remove the bottleneck when a human still has to approve the merge.

One senior engineer in the paper's 21 interviews put it plainly: an agent "can write a draft in two seconds that's correct 90 percent of the time" on routine work — but on harder tasks it makes frequent mistakes, and "you end up spending more time reviewing." That asymmetry is the whole story. The easy code got cheaper; the expensive part — verifying the hard code — got more expensive.

Why agents break review in particular

This isn't just "more code means more review." Three things make agent output specifically review-hostile.

First, volume with confidence. An agent submits a large, clean-looking diff in seconds. A human author who spent three days on the same diff carries context the reviewer can borrow — commit messages with reasoning, a hallway conversation about the tricky part. The agent's diff arrives with none of that. The reviewer starts from zero, every time.

Second, the error profile. Agent mistakes aren't the kind humans make. A tired engineer writes an obvious bug; an agent writes a plausible one — correct-looking code that misunderstands the requirement two layers down. Plausible-but-wrong is the most expensive category of defect to review because you can't skim it. You have to reconstruct the intent.

Third, the task gradient. Agents are best at routine work, where review is cheap anyway, and weakest at the gnarly tasks where review is already the bottleneck. Adoption doesn't spread review load evenly — it concentrates more of the hardest-to-review code into the queue.

The paper's autocomplete comparison sharpens the point. Plain autocomplete-style assistants raised lines of code 12%, with only the commit effect reaching significance. The 30% figure belongs specifically to agentic tools — the ones that write and submit code with less human direction. The more autonomous the tool, the more review it demands. Autonomy and review load scale together.

The honest caveats

Before you forward this to your team, the fine print. It's a working paper — "Artificial Intelligence in the Firm: Bottlenecks in Software Production," current version dated August 2026 — not peer-reviewed. The data comes from Jellyfish customers, which skews toward companies that pay for engineering analytics: larger, more process-heavy orgs than the median startup. And "resolved Jira issues" is a crude proxy for shipped value; plenty of real engineering work never becomes a Jira ticket, and plenty of tickets aren't real value.

None of that overturns the finding. If anything, the skew makes it more interesting: these are exactly the firms with the most mature review processes, and even they couldn't absorb the output. A team with no review discipline at all isn't shipping 30% more either — it's just merging 30% more unreviewed code, which is a different article.

What "invest in review capacity" actually means

The authors' prescription is one sentence, and it's the most useful line in the paper: "Realizing the benefits of AI adoption requires complementary investments in downstream review capacity, rather than simply increasing code output." In their words: code review becomes the bottleneck.

"Invest in review capacity" sounds abstract. Concretely, it's four things:

• Smaller pull requests. The single highest-leverage change. A 200-line diff gets reviewed; a 2,000-line agent-generated diff gets skimmed and approved. If your agents emit large diffs, cap their scope before they reach a human.
• Checklists tuned to agent failure modes. Generic review checklists were written for human mistakes. Agent output needs checks for the plausible-but-wrong category: requirement misreads, silently changed behavior in untouched-looking code, tests that assert the bug instead of the fix.
• A systematic debug loop. When review catches something, the fix cycle is where teams bleed time. Ad-hoc debugging on agent-written code — where nobody holds the original reasoning — is slow. A repeatable reproduce-isolate-fix-verify loop matters more, not less, when the author is a machine.
• Review SLAs. If review is the bottleneck, treat it like one: measure queue time, staff it deliberately instead of by whoever is least busy, and stop pretending it's free.

None of this is new advice. That's the point. The paper doesn't reveal a new problem — it measures the price of an old discipline that teams stopped funding the moment writing code got cheap.

The part where this gets personal

We built code-review-and-quality for exactly this world: structured review checklists and quality gates your agent runs before a human ever sees the diff. The goal isn't to replace the reviewer — the paper is clear that human sign-off is the binding constraint, and pretending otherwise is how you get the 49%. The goal is to make each review cheaper: catch the mechanical issues automatically so the human spends their time on the judgment calls only a human can make.

And when review does catch something, systematic-debugging is the companion piece — a reproduce-isolate-fix-verify loop for the fix cycle, built for codebases where the original author can't explain what they were thinking. Because with agent-written code, they never can.

An honest note: no skill removes the bottleneck. What a good process buys you is fewer review rounds per PR — and the data says rounds are exactly what's exploding. The teams that win the agent era won't be the ones generating the most code. They'll be the ones whose review process can absorb it.

The 30% was never the prize. The prize was always what survives review.

(Numbers from Chen and Stratton's working paper, via this week's coverage; Ars Technica reported the paper on October 9.)