Agents Now Open 40% of GitHub's Pull Requests. Harvard Just Measured Where They Pile Up: Code Review, 56% Slower
Half of the pull requests on GitHub now start with an agent. The engineers who have to approve them did not double.
Two documents landed on my desk in the same week. On 28 October GitHub published its Octoverse 2026: in September, more than 40% of pull requests on the platform began as an agent's first draft, about 110 million of them, up from 17% in March. On 1 November, two Harvard PhD candidates, Fiona Chen and James Stratton, posted the current version of Artificial Intelligence in the Firm: Bottlenecks in Software Production, built on Jellyfish data from 655 firms, 720,542 workers and 445 million work events between January 2021 and August 2026. Their headline is the one I want you to keep: after a firm adopts coding agents, the time from a pull request's submission for review to its approval rises 56.1%.
I am not reading this from an analyst's seat. Most weeks I review code that an agent wrote, either for our own platform or inside an app a founder built with Claude Code or Lovable and now needs in production. The paper describes my calendar. Writing code got cheap. Deciding that code is right did not.
Agents add 44% more code and, at most, 31% more software
The paper separates two things most dashboards blur. Intermediate output is code: lines added, commits, pull requests opened. Final output is software: Jira issues and epics resolved, which in these firms means the work was deployed to production.
On the first, agents deliver. Adopting assistants raised lines of code 38.6%, commits 25.5% and pull requests 25.2%. Adopting agents on top of that added another 44.0% in lines, 36.0% in commits and 35.7% in pull requests. At the median firm, lines of code per worker per month went from 3,679 to 6,482.
On the second, the pass-through is thin. Assistants moved issues resolved by 2.0% and epics by 1.7%, neither statistically distinguishable from zero. Agents moved issues by 13.7% and epics by 18.0%, with the issue estimate only borderline significant. The confidence interval is the useful part: even for agents, the data rules out an increase in shipped software larger than 30.7%, well below the 44% gain in code. The authors checked whether issues simply got bigger, by having models estimate task length from the Jira text, and the answer did not rescue the gap.
Employment did not move either. Twelve months after adopting agents, the point estimate is −2.6%, with the interval ruling out anything below −15.6%. Firms are not cutting engineers to pocket the gain. They are absorbing the gain somewhere. The paper says where.
The queue in front of the reviewer grew 60%, and the review itself got 58% longer
The 56.1% is two numbers. Code now waits 59.9% longer in the backlog before anyone picks it up. Once picked up, it spends 58.5% longer in active review. The first is capacity: the same people, more diffs. The second is quality: the share of changes receiving at least one review comment rose 13.1%, and the number of comments per change rose 38.6%. Reviewers are not rubber-stamping more code. They are finding more to say about it.
One of the 21 engineers the authors interviewed put it in a sentence I could have recorded in our own stand-up: people could make a huge number of commits quickly, but only one senior engineer was allowed to approve changes because he was the expert on the codebase, and he could review that engineer's code once a week. After some outages caused by AI-generated commits, the firm added a rule requiring senior approval for AI-generated code, which lengthened the queue again.
That is the mechanism, enumerated. Agents raise the volume of code entering review. The code enters with more defects per unit. Review capacity does not scale with volume, because reviewing is not a generic skill applied to generic text. In the dataset, 82.8% of reviews are done by someone already familiar with that code, against 17.2% if reviewers were assigned at random, and code written by a senior is reviewed by another senior 75.7% of the time. The reviewer is the person who holds the model of the system in their head, and there is no API to add more of them.
AI reviewers have not cleared the queue: 79% of firms already use them
The obvious fix is to point an agent at the review too. Most firms did: 79.1% of the sample had adopted AI code review tools by the end of the period. The bottleneck is still there. When Chen and Stratton fit their production model to the estimates, they recover a coding productivity gain of 73.7% and a review productivity change of −7.0%. Firms responded by moving labour, with coding time down 22.7% and review time up 43.4%.
I read that as the strongest evidence yet for the line I keep repeating: the model is the commodity, the harness around it is the moat. A review tool that flags style and null checks removes the cheap part of review. The expensive part, "does this change do what the issue asked, and what else did it touch", is the harness: tests that encode the behaviour, evals that encode the acceptance criteria, an architecture small enough that one person can hold it. Evals are the only regression suite an AI system has, and a reviewer without them is reading 400 lines with no oracle.
The counter-argument deserves its own paragraph, because GitHub's own report cuts the other way. Octoverse says agent-started pull requests merge more often: 90% within two weeks in September, against about 86% for pull requests without detected agent involvement, up from 83% in February. Both can be true. GitHub measures whether a PR eventually merges; Harvard measures how long approval takes and how much work it costs. Code that merges after 56% more review time still shows up as "merged" in a two-week window. Two caveats go with both numbers: GitHub sells Copilot, so its research is vendor research, and the Harvard paper is a job-market working paper on data from one analytics vendor, not yet peer-reviewed. The direction of the two findings together is still clear. The code gets in. It gets in slower, and it costs the senior engineer more of her week to let it in.
We have seen this movie: the factory did not speed up when the motor did
The authors reach for the 1880s, and they are right to. Electric motors reached factories in that decade; manufacturing output did not transform for four more, until plants were rebuilt around the motor instead of the steam shaft. Solow's 1987 line about seeing computers everywhere except in the productivity statistics is the same shape.
Software has already lived one round of this. The DORA research behind Accelerate found that deploy frequency and lead time moved with practices, small batches, trunk-based development, continuous integration, and not with tooling alone. I wrote about why those four metrics matter more than velocity; agents are now the fastest compiler we have ever bought, and lead time is sitting in the review column. The paper's own simulation makes the stakes explicit. If review productivity stays where it is, output at these firms rises 57.8% by 2031 and then levels off once the review constraint binds. If review keeps pace with coding, output rises 341.4%. The whole difference between those two futures is the step nobody is budgeting for.
What I would do this quarter if I were your CTO
- Split time-to-approval into its two halves and put both on the wall. Backlog wait and active review time move for different reasons, and the paper shows both rising. If backlog is the problem, you lack reviewers. If active review is, you lack tests. Fix the one you measured.
- Make agent PRs earn their review. No agent-authored change enters the queue without the plan it followed, the tests it added and a diff small enough to read in one sitting. LinearB's 2026 benchmarks on 8.1 million pull requests, vendor research too, put AI-assisted PRs at roughly two and a half times the size of human ones and waiting over sixteen hours for pickup against about three. Size is the variable you control today.
- Move your evals in front of the reviewer, not behind. Every acceptance criterion the issue states becomes an eval the agent must pass before a human opens the diff. The reviewer then spends her 58% on design and blast radius, not on whether the function returns the right shape.
- Rotate a reviewer-on-duty and protect the slot. The engineer who holds the system in his head is the constraint. Treat his review hours like on-call: scheduled, visible, not interruptible by feature work.
- Keep the codebase small enough for one person to hold. The 82.8% familiarity figure is the quiet finding. Every module one senior cannot explain is a module that waits a week for the one who can. When we take an AI-built app to production, the first deliverable is a map of what nobody understands, because that is where the queue will form.
Six numbers to carry out of this
- More than 40% of pull requests on GitHub began with an agent in September 2026, about 110 million, up from 17% in March. (GitHub, Octoverse 2026, 28 October.)
- Adopting coding agents raised lines of code 44.0%, commits 36.0% and pull requests 35.7% across 655 firms. (Chen and Stratton, Harvard, 1 November version.)
- Shipped software rose at most 30.7%; the point estimate for issues resolved is 13.7%, borderline significant.
- Time from review submission to approval rose 56.1%: backlog wait up 59.9%, active review up 58.5%.
- Comments per code change rose 38.6%, and 79.1% of firms had already adopted AI review tools.
- 82.8% of reviews are done by someone already familiar with the code. The reviewer does not scale by API.
Agents moved the cost of software from writing it to deciding it is right. The firms that win the next five years are the ones that staff, tool and measure that decision as seriously as they staffed the writing. If you have a repository where an agent wrote most of it and one person can approve it, that is the conversation we have every week. Bring the queue.
