The Bottleneck Moved

A Harvard study landed this week that put numbers to something a lot of us have been feeling in our gut.

Researchers from Harvard looked at engineering telemetry from 718 companies — roughly 300 million work events — before and after those companies adopted AI coding agents. Not surveys, not self-reported vibes. Actual commit history, pull request data, issue trackers.

The headline numbers are exactly what the vendors promised: 30% more lines of code, 20% more commits, 23% more pull requests. The agents generate. That’s what they’re for, and they’re good at it.

But then the researchers checked the other end of the pipeline — the rate at which teams actually finished work, measured as issues and epics resolved in the project tracker. And nothing moved. No statistically significant change. The factory floor got 30% bigger and produced the same amount of finished software.

Sit with that for a second, because it’s the most important finding in AI productivity research this year. We automated the writing of code and got no more finished work. The output went somewhere. It went downstream.

Average pull-request review time rose about 49%. The share of PRs sent back for changes nearly doubled. Reviewer comments up by a third. We made writing cheap and mailed the bill to whoever has to decide whether the result should be trusted. That would be your senior engineers — the most expensive, least replaceable people on your team.

This is the sequel to what I wrote last week about engineers becoming managers. Fine: every engineer directs an army of agents now. But what happens when a whole org does that at once? The review queue becomes the constraint. Writing was never the bottleneck in a healthy team. Getting something trusted enough to merge was. And we just tripled the input to that gate without touching its capacity.

Atlassian’s own survey this week found that 85% of knowledge workers use AI, but only 6% of executives can point to clear org-wide ROI. Now you know where the ROI went. It died in the review queue.

Line count is now a vanity metric. PR count too. If you want to know whether your agents are helping, stop measuring the writing and start measuring the finishing: cycle time from started to merged, review round trips, the fraction of agent PRs that need rework. The metric that matters is first-pass quality — how often the work arrives ready to trust.

And here’s the part that’s uncomfortable to say: this is mostly a leadership problem, not a tooling problem. Your team can keep their agents. But review capacity has to be budgeted like compute. If agents produce 23% more PRs, someone has to read them, and reading agent output is slower, not faster — you can’t skim a diff whose author you don’t trust. Teams that treat review as a background activity that happens between real work are going to drown in their own throughput.

There’s a corollary for hiring too. The engineers who are good at this are the skeptics I wrote about last week — the ones who read every diff like it’s trying to get away with something. That instinct used to be a nice-to-have. It’s now the single most valuable quality in an AI-heavy team. Find those people, give them the review queue, and protect their time.

The fix isn’t exotic. Tighten the spec so agents produce work that’s actually reviewable. Keep agents on well-scoped work and keep humans on the judgment calls. And instrument the second half of your pipeline: track how often agent PRs need rework, how long they wait for review, how many round trips they take. If those numbers aren’t moving, your agents are generating theater.

The vendors will keep selling you throughput. Their demos always show the writing. Nobody demos the review queue, because the review queue is where the bill comes due. But that’s where the work actually finishes, and finishing is the only part that ever mattered.