AI Agents Write 30% More Code. Teams Don't Ship More.

AI coding agents make engineers write about 30% more code, but companies don't ship measurably more software. That's the core finding of a Harvard study of 718 firms. The missing gains are stuck in code review: pull requests take 49% longer to review, and the share needing changes nearly doubles. More agents won't fix that. A faster review pipeline will.

The study is "Artificial Intelligence in the Firm: Bottlenecks in Software Production," a job-market paper by Harvard economists Fiona Chen and James Stratton. It uses 300 million work events (GitHub activity, Jira issues, and calendar data) from Jellyfish, an engineering analytics platform, with data through March 2026. It is a working paper, not yet peer reviewed, but the design is careful: a staggered difference-in-differences that compares firms by when they adopted AI tools. If you manage engineers, it is the most useful AI productivity data published this year.

What the numbers actually say

The headline is a gap between individual output and company output.

Agents (tools that complete multi-step tasks on their own) deliver a much bigger jump than autocomplete-style assistants. But when the authors look at what reaches production, measured by resolved Jira issues and completed epics, the effect is small and statistically insignificant. For agents they can rule out an output increase larger than 12% of the baseline, well under the 30% coding gain.

Headcount didn't shrink either. The estimate for overall employment is a precise zero. The "AI will replace engineers" story and the "AI makes every team twice as fast" story both fail the same data.

Where the 30% goes: code review

The paper's explanation is simple. Software is written, then reviewed, then shipped. Agents speed up writing. Review stays human-paced, so work piles up in front of reviewers.

After agent adoption, the paper measures:

• Time to review a pull request: +49%.
• Share of PRs with changes requested: nearly doubles.
• Comments per pull request: +35%.
• Share of engineers doing reviews: +14%. Firms quietly move people from writing code to reading it.

The quality part matters as much as the volume part. Agent-written drafts need more revision, so each PR costs more review effort, not just more PRs arriving. The authors model this as two channels: more code entering review, and more effort per unit of code.

AI review tools have not closed the gap. By March 2026 nearly 80% of firms had used AI in code review, yet only 23.3% of review comments were AI-generated and only 10.8% of pull requests got even one AI comment. Humans still do the reviewing, and humans are the bottleneck. One engineer quoted in the paper describes new rules requiring senior approval for AI-generated code after outages, which "created even more review bottlenecks."

Treat review as the system to optimize

If review is the constraint, then measure it like any other production bottleneck. Start with time to merge, which you can pull from GitHub in one command:

# Median hours from PR open to merge, last 200 merged PRs
$ gh pr list --state merged --limit 200 --json createdAt,mergedAt \
  | jq '[.[] | ((.mergedAt|fromdate) - (.createdAt|fromdate)) / 3600]
        | sort | .[length/2|floor] | floor'

Run it for the quarter before you rolled out agents and the quarter after. If the number rose, you are living inside this paper.

Then work the constraint:

• Cap PR size in CI. Agents happily produce 1,500-line diffs. Reviewers don't review those; they skim them. Fail the check above a threshold you choose and make the agent split the work.
• Set a review SLO. For example, first review within 4 business hours. Put review load on the same dashboard as deploys and incidents.
• Use CODEOWNERS to route, not to gate everything. Senior approval on every agent PR is how the paper's example firm made its bottleneck worse. Require it for risky paths only.
• Let AI do the first pass on every PR. The data shows most firms bought AI review but barely use it. Run it on every PR so humans start from a cleaner diff. We compared options in AI code review tools.
• Make the author own verification. An agent PR should arrive with tests that ran and a short "how I checked this" note. Reviewing unverified code is where the doubled revision requests come from.

A simple size gate looks like this:

# .github/workflows/pr-size.yml
name: pr-size
on: pull_request
jobs:
  size:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
        with:
          fetch-depth: 0
      - run: |
          CHANGED=$(git diff --numstat origin/${{ github.base_ref }}...HEAD | awk '{s+=$1+$2} END {print s+0}')
          echo "Changed lines: $CHANGED"
          if [ "$CHANGED" -gt 600 ]; then echo "PR too large to review well; split it." && exit 1; fi

Pick the threshold from your own merged-PR data, not from this example.

What this means for engineering leaders

Three implications are worth saying out loud in your next planning meeting.

First, lines of code and PR counts are now vanity metrics. Agents inflate both. Measure lead time to production and issues resolved.

Second, review capacity is your real throughput. Hiring, onboarding, and tooling for reviewers buys more shipped software than another agent license. The 14% shift of engineers into review shows firms already sense this; most just haven't planned for it.

Third, the paper covers data through March 2026. Agent quality and review tooling are both moving fast. The bottleneck may shrink, but only for teams that deliberately redesign review rather than bolt agents onto the old process. Some teams are rethinking the pull request itself, which we looked at in whether pull requests are obsolete.

Questions people ask

Do AI coding agents increase developer productivity?

Yes, at the individual level. The Harvard study found agents raise lines of code by 30%, commits by 20%, and pull requests by 23% per engineer. But that productivity does not fully pass through to shipped software: resolved Jira issues and epics showed no statistically significant increase, because code review slowed down.

Why don't AI coding gains show up in company output?

Because review became the bottleneck. After agent adoption, time to review a pull request rose 49%, the share of PRs needing changes nearly doubled, and comments per PR rose 35%. More code arrives, each change needs more revision, and reviewers are still mostly human, so finished work stays roughly flat.

Did AI coding tools reduce engineering jobs?

Not in this data. The study estimates a precise zero effect on overall employment for AI agents, ruling out a decline larger than 2.9%, and finds no significant change in engineering headcount. Firms instead moved more engineers into code review, with the share of reviewers rising 14%.

The decision, concretely

• Rolling out agents to more teams? Measure time to merge first, then again after; expand only if review keeps up.
• Reporting AI ROI with PR counts? Stop. Report lead time and issues shipped instead.
• Already paying for AI review? Turn it on for every PR so human review starts from a cleaner diff.
• Seeing giant agent PRs? Add a PR size gate in CI this week.

The call we'd make

Keep the agents, and treat code review as the production system it has become. Cap PR size, set a review SLO, route by risk, and make agents ship evidence along with code. The teams that win the next year won't be the ones generating the most code. They'll be the ones that can review it fastest without lowering the bar.

Sources

• Chen and Stratton, "Artificial Intelligence in the Firm: Bottlenecks in Software Production" (PDF)
• Jellyfish: Harvard and Jellyfish research on AI and developer speed