RESEARCH · OCTOBER 21, 2026 · 6 MIN READ
AI Agents Ship More Code. Review Is Where It Dies.
A Harvard working paper on 718 firms finds AI coding agents raise code output 30% but push PR change-request rates from 13% to 25%, making review the new bottleneck.
AI Agents Ship More Code. Review Is Where It Dies.
A Harvard working paper released in August 2026 put field numbers on the problem engineering teams have been describing for months. Fiona Chen and James Stratton, Harvard Ph.D. candidates, analyzed 300 million work events across 718 firms and 725,938 workers spanning January 2021 through March 2026, using engineering analytics data from Jellyfish. The conclusion is direct: AI coding agents raise code output sharply, and that gain does not reach production, because review absorbs it.
What the Study Actually Measured#
The dataset covers 200.9 million commits, 49.1 million pull requests, and 68.3 million Jira issues. Jellyfish clients opted into research use; the average firm had 1,652 workers, 241 active engineers in January 2023, and was 19.3 years old. This is not a startup sample.
Chen and Stratton ran a staggered difference-in-differences design, comparing each firm's outcomes before and after its own agent-adoption month against firms that adopted earlier or later. Adoption timing, driven by procurement cycles that ranged from one day to six to twelve months depending on legal and security approval processes, is their argument for why early and late adopters are comparable.
One methodological note worth tracking: the agent effect is measured as the added effect of agent adoption at firms that had already adopted AI coding assistants. The numbers represent what agents add on top of assistants, not the full step up from an unaided baseline.
The Numbers, Row by Row#
After agent adoption, lines of code added per worker-month rose by 1,494 against a baseline of 5,017, approximately 30 percent. Commits rose 20 percent. Pull requests rose 23 percent. PR size did not change: lines added per pull request moved by -68 on a baseline of 1,168, with a standard error of 127, statistically indistinguishable from zero.
Finished work did not follow. Jira issues resolved moved by 0.12 per worker-month on a baseline of 3.67, with a standard error of 0.17. The 95% confidence interval rules out any gain above roughly 12% of baseline. The authors also checked whether engineers shifted to larger tasks, labeling a 0.5% sample of issues by size using GPT-4o and extending labels via text embeddings. Average issue size did not change. The escape route was tested and closed.
Where the Code Accumulates#
Submit-to-merge time rose 3.45 days on a 7.03-day baseline, a 49% increase. The share of PRs receiving a formal change request rose by 12 percentage points from a baseline of 13%, ending near 25%. Review comments per PR rose 35%, from 1.66 to approximately 2.2. The share of workers doing any code review rose 14% from a base of 29%.
The paper's model offers two explanations. First: faster drafting sends more code to a fixed reviewer pool, a volume problem that can be addressed by reallocating labor. Second: the rise in change requests and comments, which volume alone does not predict, points to lower-quality drafts. That is a quality problem, and it requires different spending than a staffing reallocation. A junior engineer quoted in the paper described it plainly: "People could make a huge number of commits quickly, but code review was still the bottleneck." After outages attributed to AI-generated commits, the same engineer's firm added rules requiring senior engineer approval for AI-written code, which the engineer said created even more review pressure.
The paper's design cannot cleanly separate the two channels. The right question for any team is which one dominates in their data.
AI Review Tools Are Not Closing the Gap#
By March 2026, nearly 80% of the 718 firms had used an AI code review tool. The tools tracked include CodeRabbit, Greptile, GitHub Copilot Reviewer, Cursor Bug Bot, Graphite, and Bito. Despite near-universal adoption, AI generated only 23.3% of review comments, and only 10.8% of pull requests received even one AI-generated comment. The authors state explicitly that the review bottleneck persists after firms adopt these tools.
Coverage, not comment count, is the number that matters. A tool that comments on 10.8% of PRs is not a throughput solution. It is a selective sampling mechanism, and the sample it covers is not necessarily the high-risk tail.
Why Autonomous Fix Matters More Than Autonomous Comment#
The review surface is where the numbers break down. More code, more PRs, more change requests, more comments per PR, more reviewers pulled in, yet no measurable increase in resolved issues and no decrease in merge time. That pattern has a specific shape: the work arriving at review is harder to approve, not just more abundant.
AI review tools that generate comments add to the volume reviewers must process. A comment is not a resolution. Hyrax takes a different position in this pipeline: it identifies a finding, writes the fix, runs 13 verification steps in an isolated worktree, and submits a PR. The human decision is whether to merge, not whether to investigate and then write a fix. That distinction matters directly in the scenario this paper describes, where reviewer time is the binding constraint and adding more findings without resolving them makes the constraint worse.
The six agent domains Hyrax scans, security, code quality, reliability, API and data, ops, and UX, map to the categories reviewers are now catching more of, per the study's change-request signal. The point is not to replace review but to arrive at it with fewer open questions.
What Engineering Teams Should Configure Now#
The study's data suggests two distinct interventions, and conflating them produces the wrong answer. If the bottleneck is volume, the fix is capacity: more reviewers, better triage, faster tooling. If the bottleneck is quality, the fix is earlier detection, before the PR is submitted. Most teams do not know which problem they have, because they are measuring keystrokes and commit counts rather than change-request rates and reviewer hours.
Concrete steps worth configuring before the next agent expansion:
- Track change-request rate as a per-team metric, not just total PR count. The study's baseline was 13%; if a team is above 20%, the quality channel is likely dominant.
- Require CI gates that run static analysis and dependency checks before a PR enters the review queue. Catching obvious findings pre-submission reduces reviewer load without reducing throughput.
- Audit AI review tool coverage. 10.8% of PRs receiving at least one AI comment means the tool is not operating at queue scale. Configuration, not just adoption, determines coverage.
- For AI-generated code specifically, the paper's interviews suggest that post-outage policies requiring senior approval compound the bottleneck. The better control point is pre-merge automated verification, not post-incident approval rules.
The paper's data cuts off in March 2026, and a revised version could move the estimates. What it already establishes is the measurement frame: change-request rate, submit-to-merge time, and reviewer share are the numbers that tell whether a team's review process is holding.
Hyrax is live at hyrax.dev.