More Code, Same Reviewers: Where AI Coding Gains Get Stuck

On 28 October GitHub published its Octoverse report. In September, it says, more than 40% of pull requests on GitHub started with an agent's first draft, up from 17% in March.

If code arrives that much faster, why does finished work grow so much more slowly? A study of 655 companies, updated on 1 November, follows the extra code through review and into production, and the answer matters for anyone deciding who to add to an engineering team next.

Fiona Chen and James Stratton, researchers at Harvard, looked at what happened inside companies after they adopted AI coding tools. Their paper, Artificial Intelligence in the Firm: Bottlenecks in Software Production, uses data from Jellyfish, an engineering analytics platform: GitHub, Jira and calendar activity for 720,542 people at 655 firms, from January 2021 to August 2026. It is a working paper, not yet peer reviewed, and the version we quote is dated 1 November 2026.

After a firm adopted coding agents, pull requests opened per engineer rose by 35.7% and pull requests merged by 26.0%. Resolved Jira issues, one of the authors' two measures of finished work (an issue is marked resolved once the code behind it has been deployed), rose by 13.7%, and the authors call that estimate only borderline significant. Even at the top of their confidence range, finished output grew by less than 31%. They found no detectable effect on engineering headcount so far, though they describe that estimate as noisy.

Some coverage in October quoted an earlier version of the paper with different figures. The numbers above come from the current one.

The authors trace much of the gap between code written and work shipped to review. After agents arrived, the time from submitting a pull request for review to getting it approved grew by 56.1%. Code waited 59.9% longer in the queue before review started, and spent 58.5% longer in active review once it did. Each pull request drew 38.6% more review comments.

Not all of the extra code made it through. Only about 63% of the additional pull requests were merged, against 86% of pull requests before agents, and the authors read the longer reviews and extra comments as a drop in the quality of code sent for review.

Automated review did not clear the queue. By July 2026, 79.1% of the firms had used AI tools in code review, yet only 23.3% of review comments came from AI, and only 10.8% of pull requests got even one AI comment. People still did most of the reviewing.

Review does not spread evenly across a team. In the study, 82.8% of reviews were done by people who had already committed code or opened a pull request in that codebase. If reviews had gone to random pull requests at the same firm, the figure would have been 17.2%. Code written by a senior engineer was reviewed by another senior 75.7% of the time.

A junior engineer the authors interviewed described what that looks like: "On one project, only one senior engineer was allowed to approve changes because he was the expert on the codebase. He was so bandwidth constrained that he could only review my code once a week."

The firms in the study are larger than most of our clients. In January 2023 they had on average about 1,677 employees and 249 active engineers, an average pulled up by a few very large firms, and the authors say their sample leaves out smaller and newer startups. The paper does not test smaller teams, so this part is our own read. In a company of 20 to 50 people, a change to payments or permissions often waits for one senior, because nobody else is trusted to approve it.

If review is where the work waits, another person who only writes code makes the queue longer, whatever their level and whatever their contract. Each new author sends more pull requests to the same one or two people. The person who shortens the queue is the one who learns a part of the system well enough to review changes in it, and that depends more on time spent in that code than on a title.

The authors' model, fitted to their data, points the same way. After agents arrive, firms move labor out of writing code, down 22.7%, and into reviewing it, up 43.4%.

In August we wrote that what limits the growth of junior engineers is senior time. Agents use up more of that time. At a company of 30, often only one or two people can read a change to the billing code and tell whether it is right.

Most of this costs nothing.

Types, tests, linters, architecture checks and an AI review pass should reject a pull request before a person opens it. None of them should be the one that approves it. Our CTO calls review attention a budget. His rule is that a person reads every change to money, access control or migrations.

Keep pull requests small. Ask the agent for one change per pull request and send back anything that mixes a refactor with a feature. A reviewer who has to hold a wide change in their head will either take a week or skim it.

Write down what a reviewer needs to know. An AGENTS.md or CLAUDE.md file that explains how the system works helps the agent, and a second person can start reviewing changes in that part of the code sooner.

Then give a second person one part of the system to own, well enough to review changes in it and, when you are ready, to approve them. Every change that person approves is one your senior no longer has to.

Whoever that person is, check who they are before they get access to that code. We wrote separately about why the risk from a fake candidate starts after the offer.

How many pull requests waited more than a day for their first review last week?

How many people can approve a change to payments or access control?

Who reviews when your main senior is on holiday?

Were any pull requests merged without a review this month?

How many hours did your most senior engineer spend on review last week?

If the first review usually comes within a day and more than one person can approve a payments change, you probably do not need anyone from outside. If the second answer is a single name, start there.

We place vetted mid and senior engineers inside product teams, working on your codebase and inside your review process. When the problem is a review queue, we usually suggest a senior. 70,000+ hours of work, clients in 6 countries, 50+ specialists.

A senior engineer from us starts by writing code in one part of your system, through your normal review. As they learn that part, they review changes in it next to your senior, and whether they ever approve changes there is your decision. In your first month with us, our CTO reviews our engineer's code every week, so your senior is not the only person checking a new engineer's work.

You interview the engineer before you sign, the engagement runs month to month with the rate fixed for the length of the contract, and if the fit is wrong in the first 7 days we replace the engineer at no cost.

We work mainly in Ruby on Rails, React, Next.js, JavaScript, Java, Golang, iOS, Flutter, Python and Rust, and we also place engineers who build AI features into products.

Talk to us about an engineer for your team