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

AI coding agents make engineers write far more code, but companies ship only a little more software. In a Harvard study of 655 firms, agents raised lines of code 44% while resolved issues rose about 14%. The missing gains are stuck in code review, where time to merge rose 56%. 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 445 million work events (GitHub activity, Jira issues, and Google Calendar data) for 720,542 workers from Jellyfish, an engineering analytics platform, with data from January 2021 to August 2026. An earlier draft with data through March 2026 put the agent gain in lines of code at about 30%; the October 31, 2026 revision reports larger effects on both sides, and the numbers below are from that revision. 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 much smaller. For agents the issue effect is 13.7% and only borderline significant, and they can rule out an output increase larger than 30.7% of the baseline, well under the 44.0% coding gain.

Headcount didn't measurably shrink either. For agents the employment estimate is -2.6% twelve months after adoption, a noisy zero. The "AI will replace engineers" story and the "AI makes every team twice as fast" story both fail the same data, at least so far.

Where the extra code 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 from review submission to merge: +56.1% (from a baseline of 3.56 days).
• Time waiting in the review backlog: +59.9%; time in active review: +58.5%.
• Comments per pull request: +38.6%.
• Share of PRs formally blocked with requested changes: +38.5%, though that estimate is marginally insignificant.

The authors' calibrated model goes further: agents raise coding productivity by 73.7%, and firms shift labor from coding (-22.7%) to review (+43.4%). 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 July 2026, 79.1% 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. The paper finds PRs averaged about 1,200 added lines before and after agents arrived. Reviewers don't review diffs that size; 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:

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 modeled 43% shift of labor into review shows firms already sense this; most just haven't planned for it.

Third, the paper covers data through August 2026, and its estimates moved between drafts. 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 code-writing level. The Harvard study found agents raise lines of code by 44.0%, commits by 36.0%, and pull requests opened by 35.7%. But that productivity does not fully pass through to shipped software: resolved Jira issues rose 13.7%, a borderline significant effect, and the authors rule out gains above 30.7%, 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 from review submission to merge rose 56.1%, time in active review rose 58.5%, and comments per pull request rose 38.6%. More code arrives, each change needs more revision, and reviewers are still mostly human, so finished work grows far less than code output.

Did AI coding tools reduce engineering jobs?

Not measurably in this data. The study estimates a -2.6% employment effect twelve months after agent adoption, statistically a zero, though noisy enough that it only rules out declines larger than 15.6%. Instead, the authors' model shows firms moving labor into code review, which rises 43.4%, while its long-run simulation predicts some employment decline if review stays the bottleneck.

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)
• GitHub CLI manual: gh pr list
• GitHub Docs: About code owners