AI Agents Write 30% More Code. Finished Work Hasn't Moved. Review Is Why.

Posted on Oct 15 • Originally published at dromeas.ai

Originally published on the Dromeas blog.

In short: A new Harvard working paper tracked about 700 companies as they rolled out AI coding tools. Once firms adopted coding agents, engineers wrote 30% more lines of code and opened 23% more pull requests. The number of finished tickets didn't significantly change. The authors trace the gap to code review: review time went up 49%, and the share of PRs sent back with changes requested nearly doubled. If you measure AI by commits, you're measuring the wrong step.

Fiona Chen and James Stratton at Harvard used data from Jellyfish, an engineering analytics platform, covering roughly 700 firms and 700,000 workers from January 2021 to March 2026. That's commits, pull requests, Jira tickets and calendar events, about 300 million work events in all.

They compared firms before and after they adopted AI coding assistants (autocomplete-style tools) and AI coding agents (tools that take a task and produce changes on their own). Firms adopted at different times, partly because procurement takes longer at some companies than others, so they could compare adopters against firms that hadn't adopted yet.

It's the biggest look at AI in real engineering orgs I've seen this year, and it's built on what teams actually did, not what they said in a survey.

Here's what changed per engineer, per month, after a firm adopted coding agents:

Assistants showed smaller gains: commits up about 9%, and no significant change in lines or PRs.

The last row is the one that matters. The authors put it plainly: "productivity gains do not fully pass through to changes in software output or employment." Their confidence intervals rule out issue-output gains bigger than about 12% for agents, well below the 20–30% jump in code activity. Epics didn't move either, and tickets didn't get smaller or bigger to hide the effect.

Employment didn't move much in either direction over the period they could measure. So this isn't a story about AI quietly replacing engineers. It's a story about work piling up somewhere.

The paper's answer is the step right after writing. As they put it, "Writing code is only one step in a multi-stage production process."

One junior engineer they interviewed summed it up better than any chart: "People could make a huge number of commits quickly, but code review was still the bottleneck."

The authors' model offers two reasons that stack. First, more draft code simply means more to review. Second, if each change carries more problems, every review takes more rounds. They don't measure defects directly, but more change requests and more comments on same-sized PRs point that way. That matches what I've written about behavioral bugs in AI code: agent-written code tends to look clean, so the problems surface in back-and-forth, not in the first glance.

This part surprised me. By March 2026, nearly 80% of the firms in the sample had used some AI code review tool. Yet only 23.3% of review comments came from AI, and only 10.8% of pull requests got any AI-generated comment at all.

So AI review exists, but it's spread thin, and it hasn't cleared the queue. A senior engineer they interviewed put it this way: "Even with AI tools, you absolutely still need humans involved in the review process."

I agree with that. The question isn't human or AI. It's whether the review step gets the same investment the writing step just got.

Stop using commits as the AI scorecard. The paper notes that "Many managers rely on intermediate productivity metrics, such as lines of code or commits." Those numbers went up. Finished work didn't. If your AI rollout dashboard is lines and PRs, it's measuring the step that was never the constraint.

Measure the review queue. Time from PR open to merge, the share of PRs with changes requested, and review rounds per PR. These are the numbers that told the story in this study, and most teams already have them in their Git host.

Budget for review the way you budgeted for agents. The authors' discussion has the most practical line in the paper: "Realizing the benefits of AI adoption requires complementary investments in downstream review capacity." That can mean people, process or tooling, but it has to mean something. Rolling out agents and leaving review as-is just moves the pile.

Make the reviewer's first pass cheaper. If most of the extra time is rounds of "please change this," then catching those issues before a human opens the PR, and showing the evidence, is where the time comes back. I wrote about how review differs on PRs vs trunk if you're deciding where that check should sit.

Make AI review something people can trust. Nearly every firm in the study tried AI review, yet it touched only about one PR in ten. My guess is that's a trust problem more than a tooling one. Engineers don't skip their own pass because a bot left a comment, and they shouldn't. What builds trust is review that behaves like a good colleague. It uses specialized checks (security, quality, compliance) instead of one generic pass. Several independent models have to agree before something gets flagged, so one model's blind spot doesn't become your problem. And it learns: when your team says "not relevant here," that should stick, so the same noise doesn't come back next week. Review that gets quieter and more accurate over time is review people stop double-checking.

Watch the release, too. Review is the first bottleneck. The release is where all the reviewed changes land together, and it's the next one.

This is the problem Dromeas is built around. Every PR and trunk commit gets reviewed by specialized agents for security, code quality and compliance, and their findings go to a council of models from several providers that cross-check each other before anything is flagged. Each verdict comes with the evidence behind it, so a human reviewer starts from findings rather than a blank diff. When your team silences a finding, Dromeas turns that into a rule and stops raising the same noise, so review gets quieter over time instead of louder. On every tagged release, Dromeas runs readiness checks against the full release scope and issues a verdict with blockers and approvals. More on release management.

Source: Fiona Chen and James Stratton, "Artificial Intelligence in the Firm: Bottlenecks in Software Production," Harvard University working paper (not yet peer-reviewed), version of August 4, 2026. PDF