Let’s talk about the study that found software teams writing forty-four percent more code and their companies shipping almost none of it.
There’s a line buried in that paper, from one of the interviews the researchers ran. A junior engineer describing a project he worked on. He says only one senior engineer was allowed to approve changes, because that man was the only person who understood the codebase. He was so bandwidth constrained that he could only review the junior’s code once a week.
Then the outages started. AI-generated commits broke production, so the company added a rule: anything AI-generated needs senior engineer approval. Which created even more of a bottleneck, for the same man, in the same week, with the same pair of eyes.
That’s the whole story. Everything after this is just the accounting.
The paper is by Fiona Chen and James Stratton at Harvard. Working paper, current version dated the twenty-eighth of October. They got proprietary data from Jellyfish, an engineering analytics platform, covering four hundred and forty-five million work events — GitHub activity, Jira issues, Google Calendar — for seven hundred and twenty thousand workers at six hundred and fifty-five firms, from January 2021 through August 2026.
Sixty-five five firms. That’s not a survey. That’s the actual exhaust of the work.
Here’s what they found. With AI coding agents, lines of code per worker went up forty-four percent. Commits, thirty-six percent. Pull requests opened, thirty-six percent.
Final software output — measured properly, as Jira issues and epics actually resolved and deployed — moved thirteen point seven percent on issues and eighteen percent on epics, and the issue number is only borderline significant. The authors are explicit: they can rule out an output increase larger than thirty point seven percent of the baseline. Code went up forty-four. Output cannot have gone up more than about thirty.
And where did the rest go? Into the reading.
Time from pull request to merge rose by just under two days — fifty-six percent on a baseline of three and a half days. Time sitting in a backlog waiting for a reviewer: up sixty percent. Time in active review: up fifty-nine percent. Comments per pull request: up thirty-nine percent.
So the machine did exactly what it was sold to do. It made the writing faster. And the company got a queue.
Now — the lazy read of this is “AI coding tools don’t work,” and that read is wrong, and it’s wrong in a way that will cost you money. Read the paper and you’ll see the authors are careful. Flat output doesn’t mean no value. It could mean the same output for less effort. It could mean exploration that never ships. It could mean people who couldn’t write code before, writing some. The study doesn’t measure any of that.
What it does rule out is the specific story that got a lot of procurement signatures this year: that more code means more product. It doesn’t. Not at this stage of the adoption curve, not in this sample.
And one more thing, because it matters and nobody’s saying it. If you read the coverage from a few weeks ago, the numbers were thirty percent and forty-nine percent. The current draft says forty-four and fifty-six. The effect got bigger as the data got better. Which is a good reason to read the paper instead of the thread.
Now the part I actually care about. Why can’t you just hire more reviewers?
Because of one number on page whatever. Eighty-two point eight percent of code reviews happen on a codebase where the reviewer had previously committed code or opened a pull request. If you assigned review at random to someone at the same firm in the same month, that figure would be seventeen percent.
Sit with that. The value of a review is not the hour the person spends. It’s the two years of context in their head that lets them look at a diff and know it’s wrong — not that it fails a test, but that it violates something the tests never encoded. You cannot hire that. You cannot buy it by the seat. You can only grow it, slowly, in a specific person, on a specific codebase.
And the seniority data makes it worse. Senior engineers do seventy-six percent of the reviewing on other senior engineers’ work. Only thirty-three percent on juniors’. Juniors do twenty-four percent of the reviewing of senior code. So the review capacity is concentrated at the top of the ladder, exactly where the people are who are hardest to replace and most expensive to keep.
The machine increased supply at the bottom of the pipeline and increased demand at the top. That’s not a productivity gain. That’s a traffic jam with better marketing.
Here’s the second-order effect, and it’s the one that ought to worry you. Those outages in the junior engineer’s story. The firm’s response was governance — a rule that AI-generated code needs senior sign-off. That’s the correct response. It’s also, mechanically, a decision to route more volume through the tightest gate in the building.
Which means every company doing this seriously is going to hit the same wall: oversight is priced in the same currency as the bottleneck. You cannot add a human check without adding cycle time, unless you change where the check sits. And most companies won’t change where it sits. They’ll just tell the senior engineer to move faster, and he’ll start approving things he didn’t read, and the governance will exist on paper and nowhere else.
That’s the part people are missing. Everyone is measuring the stage before the constraint. Lines of code. Pull requests. Commits. Seats. Tokens. All of it upstream of the place where the work actually gets judged. You can have a beautiful dashboard showing a forty-four percent increase in a number that doesn’t matter, while the thing that determines whether you ship sits in one man’s inbox on a Thursday.
And here’s the commercially uncomfortable version, for anyone selling AI into a business right now. Your client is about to ask you why their release cycle got slower and their best engineer became a queue. If your answer is “adoption takes time,” you’ve lost the account. If your answer is “we automated supply and left demand alone, here’s the fix,” you keep it.
The fix is not exotic. Instrument two numbers before you expand the pilot: time from pull request to merge, and rework per pull request. Those are the two places this cost lands and almost nobody tracks them, because they’re downstream of the demo.
Then put a cheap filter in front of the human gate, so the gate spends its attention on work worth reading rather than volume. Then cap the size of what an agent is allowed to submit in one go — because the revision rate nearly doubled and that’s what happens when you hand someone a change too big to hold in their head. And then protect the senior reviewer’s calendar like it’s a production system, because it is.
One thing I’d add, and this is the part that separates a fix from a costume: give the reviewer the authority to say no without a meeting. If saying no costs him a conversation with a manager who’s measured on velocity, he will stop saying no. And then you’ve built the most dangerous thing in this whole story — a human gate that exists, is staffed, is expensive, and doesn’t gate.
The paper has a number for that too, and it’s quietly reassuring. By July 2026, seventy-nine percent of firms had used AI tools somewhere in the review process. But only twenty-three percent of review comments were AI-generated, and only eleven percent of pull requests got even one AI comment. So firms are putting a model in front of the gate. The gate is still human.
Which is where I land. The review stage is not a bottleneck that AI failed to remove. It’s the last place in the pipeline where a person can look at the work and say, this is wrong, and mean it. That costs time. It’s supposed to. A pipeline that outruns its reviewer isn’t faster. It’s just further away from the truth when it arrives.
So before you buy another seat, go and ask one question: what is our time from pull request to merge, and is it going up?
If nobody knows, that’s your answer. You’re not measuring the business. You’re measuring the noise in front of it.
You’ve got this. Go and look at the queue.