40% of PRs Now Start With an Agent. Shipping Barely Moved.
GitHub published Octoverse last week, and there’s one line in it I can’t stop thinking about.
By September, more than 40% of pull requests on GitHub started with an agent’s first draft. In March it was 17%. That’s 110 million agent-started PRs in September alone, about six times March’s volume.
That’s a wild curve. It’s also a number about what agents produce. Nobody puts a chart on the slide for what actually got finished.
Back in February I wrote that speed without synthesis is just faster chaos. The argument was a hunch, really: execution got cheap, so the expensive part of the work moves somewhere else. Understanding. Deciding. Checking. I didn’t have data. I had a review queue and a feeling.
Now there’s data.
Fiona Chen and James Stratton at Harvard got access to Jellyfish, an engineering analytics platform, and looked at 720,542 engineers across 655 firms, from January 2021 to August 2026. GitHub activity, Jira, calendars — the whole pipeline. Then they compared firms that adopted AI coding agents earlier with firms that adopted later.
The code numbers go up the way you’d expect. About a year after agent adoption — on top of whatever AI assistants had already done — lines of code added were up 44%. Commits up 36%. Pull requests opened up 35.7%.
And the stuff that represents finished work? Jira issues resolved went up 13.7%, and even that wasn’t quite statistically significant. Their estimates rule out anything bigger than about 31%. Engineering headcount: no detectable change either way.
PRs up by a third. Finished tickets up by maybe a seventh. Where did the rest go?
Into review, mostly.
After agent adoption, the time from opening a PR to merging it went up 56%. Code waited about 60% longer before anyone picked it up, and once someone did, it spent 58.5% longer in active review. Comments per PR went up 38.6%. And only about 63% of the extra PRs got merged at all, against an 86% merge rate before adoption.
The authors read that as two problems stacked on top of each other. More code arrives at the same number of reviewers, so it queues. And each piece of code needs more review than before, which points to a drop in the quality of what’s being submitted. It’s not that nobody thought of AI review, either — 79.1% of the firms had used AI tools in code review, but only 23.3% of review comments came from AI. Humans are still the ones reading.
One engineer they interviewed said it better than any chart:
“People could make a huge number of commits quickly, but code review was still the bottleneck.”
That’s the whole post in one sentence, honestly.
So I looked at the repo I work in, a large open-source project where a lot of my week is reviewing PRs. I pulled the PR data from May 2025 to October 2026 and threw out the bots.
Humans opened about 270 PRs a month in 2025 and about 420 a month by mid-2026. The median PR got about four times bigger, from 56 lines changed to 238. Same team reading them.
You can see where the pressure lands. For outside contributors, the share of PRs that got any human review fell from 44% to 13%, and the median wait for that first review went from about 10 hours to about 116. Nobody decided that. It’s what happens when the queue grows faster than the people reading it. That’s Harvard’s “extra PRs that don’t get merged,” in a repo I can actually see.
And me? Since early 2026 I’ve reviewed 72 to 80 PRs a quarter while opening 45 to 54. About one and a half reviews for every PR I open. I’m the queue too.
Here’s the part that complicates it. Back to Octoverse.
In February, 83% of agent-involved PRs on GitHub merged within two weeks, a touch behind the roughly 86% for everything else. By September, agent PRs were at 90%. Everything else stayed around 86%.
There are two ways to read that. Either the agents got genuinely better — and to be fair, they did; the models people ran in September are not the models they ran in February. Or reviewers started approving agent PRs faster because they look clean, CI is green, and there are forty more right behind it.
I don’t know which one it is. A merge rate can’t tell you whether someone read the diff. And I’m not going to pretend GitHub’s numbers and Harvard’s line up neatly — different populations, different measures, different questions. But both readings point at the same place. If reviewers are reading carefully, review is your bottleneck, which is exactly what the Harvard data shows. If they’re not reading carefully, review is your risk. Either way, the review queue is where the real work moved.
The paper’s own model says the same thing about the future. How much AI eventually adds to output depends almost entirely on whether review gets faster as quickly as coding did. If it doesn’t, output levels off once review is maxed out.
A few honest caveats, because I’d be a hypocrite otherwise. The Harvard study is a job market paper, not a peer-reviewed publication, and the numbers have moved between versions — coverage from earlier this fall quoted smaller figures from an August draft. The data comes from one analytics vendor’s clients who opted in to research, which isn’t a random sample of the industry. And it’s a staggered difference-in-differences design: a serious attempt at a causal estimate, but it leans on the assumption that early and late adopters would have trended the same without AI. It’s not a controlled experiment. The authors also flag that teams may just track Jira less carefully when code moves faster. Same goes for my repo numbers: it’s one repo, not a controlled study, and I can’t reliably tell which PRs an agent helped write. They show the review pressure, not that agents caused it.
None of that changes the shape of the thing. Every chart I see about AI coding measures what goes into the pipe: lines, commits, PRs, “percent of code written by AI.” The number that matters is how much comes out the other end, and the narrow part of the pipe is still a person reading a diff.
We got really good at opening pull requests. Now we have to get good at closing them.