If your engineering team adopted Claude Code, Codex or Cursor this year, you have probably seen the same thing everyone else has. Pull requests are up. Commits are up. The board deck has a chart going in the right direction. And yet the roadmap does not feel any faster.
That is not your imagination. A new study from Harvard has put numbers on it, and the numbers explain a lot.
What the study found
In August 2026, Fiona Chen and James Stratton at Harvard published the latest version of Artificial Intelligence in the Firm: Bottlenecks in Software Production. It uses engineering data from Jellyfish, an analytics platform, covering around 300 million work events across 718 companies from January 2021 to March 2026: GitHub activity, Jira issues and calendar data. The authors compare firms before and after they adopted AI coding tools, using the different adoption dates as a natural experiment.
For AI coding agents, the tools that take a task and work through it on their own, they found:
- Lines of code up 30%, commits up 20%, pull requests up 23%. A real, significant jump in coding output.
- Finished work did not follow. Resolved Jira issues and completed epics showed small, statistically insignificant changes. The estimates rule out an increase in output of more than 12%, well below the 30% gain in code.
- Issues did not get bigger. The authors checked whether teams were simply taking on larger tickets. They were not.
- Review got slower and harder. The average time to review a pull request rose by 49%. The share of pull requests with changes requested nearly doubled. Comments per pull request rose by 35%.
- Teams moved people into review. The share of engineers doing code review rose by 14%.
- AI review tools did not fix it. The bottleneck persisted after firms adopted AI code review tools, and human reviewers stayed central.
A few honest caveats. This is a working paper, not yet peer reviewed. The data comes from a commercial partner, though the authors say Jellyfish only checked it for proprietary disclosure. And these are averages across hundreds of firms, so your team may be doing better or worse. But it is the largest look at real engineering data we have seen, and it matches what we see in codebases.
Why more code does not mean more software
Writing code was never most of the job. The study estimates engineers spend 30 to 40% of their time writing code. The rest goes on planning, reviewing, testing and getting things into production.
Coding agents speed up the part that was already the minority, and push more work into the parts that were not. Two things happen at once:
- More code arrives for review. Every extra pull request needs a human to read it, understand it and approve it.
- Each pull request needs more review. First drafts from agents are fluent and plausible, but they are more likely to miss a convention, solve the wrong problem or touch more than they should. The near-doubling in change requests is the signal.
So the queue grows from both ends. Reviewers, usually the most senior people on the team, become the constraint, and everything waits on them. A faster typist does not help a factory whose bottleneck is quality control.
What actually moves the bottleneck
The fix is not to stop using agents. We build with coding agents on our own delivery work and would not go back. The fix is to make review cheaper per change, and to stop asking humans to check what a machine can check. Here is what makes the difference.
1. Keep changes small
A 60-line pull request gets a real review. An 800-line one gets a skim and a thumbs-up, or sits in the queue for days. Agents will happily produce the second kind unless you tell them not to.
Give agents a narrow task, one concern per change, and an explicit instruction to keep the diff small. Split large features into a sequence of reviewable steps before any code is written.
2. Let machines check what machines can
Every minute a reviewer spends spotting a type error, a formatting issue or a missing null check is a minute not spent on whether the change is right. Push all of that into the pipeline:
- Strict TypeScript, so whole classes of mistakes never reach a human.
- Linting and formatting enforced in CI, not in comments.
- Automated tests that must pass before a pull request can be opened, not just merged.
- Preview deployments, so reviewers can click through a change instead of imagining it.
When this is in place, review becomes a conversation about intent and design. That is the part humans are good at, and it is much faster.
3. Make tests the specification
An agent that can run the tests can check its own work before anyone else sees it. An agent working in a codebase with weak tests will produce code that looks right and is wrong in ways only a careful human will catch.
Good test coverage on the parts of the system that matter is the single biggest lever on agent quality we know of. It turns "does this look right?" into "does this pass?"
4. Write down your conventions
A lot of change requests are really "that is not how we do it here". Agents cannot follow conventions nobody has written down.
Most coding agents now read an instructions file in the repository, such as CLAUDE.md or AGENTS.md. Put your architecture rules, naming, folder structure, testing expectations and the things you never want to see in there. Clear module boundaries help too: an agent that can work inside one well-defined module produces changes a reviewer can reason about.
5. Review the plan before the code
The most expensive review comment is "this is the wrong approach", made after the code exists. Ask the agent for a short plan first: what it will change, where, and why. A senior engineer can approve or redirect a plan in two minutes. Unpicking 800 lines built on the wrong idea takes much longer.
6. Measure what ships, not what is typed
If you track lines of code or pull requests, AI will look like a triumph while delivery stays flat. That is exactly the gap the study found.
Measure cycle time from ticket to production, time pull requests spend waiting for review, change request rates and issues shipped. Those numbers tell you where the bottleneck actually is.
7. Treat review as real work
Review is now a larger share of the job, so plan for it. Give it protected time, spread it across the team instead of leaving it all with one or two seniors, and count it when you plan a sprint.
A quick self-check
If you are rolling out coding agents, or already have, these questions will tell you whether you are likely to see the gains or just more code:
- Do most pull requests change fewer than 200 lines?
- Does CI block a pull request that fails type checks, linting or tests?
- Would your test suite catch an agent quietly breaking a core user journey?
- Is there a written instructions file in the repository that an agent will read?
- Do engineers agree an approach with the agent before it writes code?
- Do you know how long pull requests wait for review today?
- Is review time planned into sprints, or squeezed in around them?
Three or more "no" answers and the bottleneck in the study is probably already forming in your team.
What AI-first should actually mean
The lesson from this research is not that coding agents are overhyped. The gains in writing code are real and large. The lesson is that adding agents to an unchanged process mostly produces a longer review queue.
Being AI-first means redesigning the whole path from idea to production around the fact that code is now cheap to write and expensive to verify. Small changes, strong automated checks, good tests, written conventions and review treated as the main event. Teams that do that work get the speed. Teams that only buy the licences get the chart.