AI Coding Agents Add 30% More Code, Not More Finished Software: The Harvard Review-Bottleneck Study

AI coding agents make firms produce roughly 30% more code, but not more finished software. That is the headline of a new Harvard job-market paper on bottlenecks in software production, by researchers Fiona Chen and James Stratton, first reported by Ars Technica and hosted by the authors. After agents arrived, lines of code, commits and pull requests all went up. The rate at which tracked issues and epics got resolved did not move in a statistically significant way. The gap sat in code review.

If you have spent the year watching agents write pull requests faster than anyone can read them, this will sound familiar. What is new is the scale: Jellyfish engineering data covering more than 700 firms, rather than one team's anecdote.

TL;DR: the study in one table

What exactly did the researchers measure?

The authors separate two kinds of tools. Coding assistants autocomplete code that a human mostly writes. Coding agents write and submit changes largely on their own from a prompt. They then compared firms before and after adoption using a difference-in-differences regression across staggered start dates.

The data comes from Jellyfish, a platform that tracks the granular output of engineering teams. Per Ars Technica's summary, it spans about 300 million individual work events, such as commits and pull requests, plus issue-tracker data, for more than 700,000 employees at over 700 software firms between 2021 and March 2026.

The output side: more of everything

When a firm introduced coding agents, the study found an average rise of about 30% in total lines of code, about 20% in commits, and about 23% in pull requests. This is the part everyone already believed. Agents are very good at producing diffs.

The outcome side: finished work does not budge

The researchers then looked at what firms actually track as completed work: issues and epics in tools such as Jira. The resolution rate for those did not change in a statistically significant way after AI introduction. They also checked whether firms simply shifted toward smaller or easier tickets, and found no compositional shift in the size or complexity of the tracked issues. In other words, the flat result is not explained by teams quietly redefining what counts as a task.

Where did the extra code go? Into review

Code review as a narrow funnel slowing a line of AI coding agents pull requests

The authors' explanation, quoted by Ars Technica, is that efficiency gained while coding is "absorbed by downstream constraints in the production process." Code review is the main constraint. According to the paper's reported figures (via a Superpower Daily summary of the Ars piece):

• The average gap between a pull request being submitted and merged grew 49%.
• Comments per pull request rose 35%.
• The share of pull requests sent back for changes nearly doubled.

Those numbers describe elapsed time and rework, not hours of reviewer effort. A pull request can wait longer in a queue without anyone spending more minutes reading it. Still, the pattern matches what many teams report: reviewers are the shared, fixed resource, and agents multiply the number of things waiting for them.

The study also notes that AI is already inside the review loop. By March 2026, the summary says, 80% of measured firms used AI code review, and agents accounted for 23.3% of review comments and 10.8% of pull requests. So the bottleneck is not simply "humans versus machines." It is more output flowing into a pipeline whose slowest stage did not speed up.

Why this finding is not a surprise (but is useful)

Production theory has a name for this: the theory of constraints. Speed up a non-bottleneck stage and the system output stays the same while queues grow upstream of the real constraint. One commenter on the Hacker News thread (user evolve2k) drew the manufacturing analogy, arguing that running machines faster pushes cost into rework and inspection. Another (cyanydeez) argued in this comment that someone has to remain accountable for what ships, which AI coding bots cannot be. These are the commenters' opinions, not findings, and the thread is small (a handful of comments at the time of writing), but they capture the common reading.

What the paper adds is evidence at firm scale that the constraint is real, and a way to see it in standard engineering metrics.

What the study cannot tell you

Magnifying lens inspecting a single change, representing careful reading of the AI coding agents study limits

Be careful about stretching the headline.

1. It is observational. Difference-in-differences controls for a lot, but it cannot prove agents caused every change in review time. Firms that adopt agents may also change other practices at the same moment.
2. Averages hide spread. Firm-level results blend teams that adopted deeply with teams that barely touched the tools. That likely dilutes any average effect, so the estimates describe typical firms, not the best-run teams.
3. The data ends in March 2026. Agent capabilities and review tooling have moved since then. See our coverage of Zuckerberg's admission that agents are progressing slower than expected for how even lab leaders are recalibrating.
4. Jira is a proxy. Resolved issues and epics are the best firm-wide measure available, but they miss quality improvements, avoided incidents, and work that never gets a ticket.
5. "No significant change" is not "zero." The study found no statistically significant improvement, which is narrower than saying agents produce no additional software anywhere.

Jellyfish itself has published earlier joint work with Harvard on the gap between developer speed and business impact, which you can read on the Jellyfish blog. It is worth noting that Jellyfish sells engineering-analytics software, so the data provider has its own interest in the productivity-measurement conversation.

What this means for teams that use coding agents

The practical lesson is not "stop using agents." It is "manage the constraint you just made worse." These steps follow from the paper's logic, not from its experiments, so treat them as hypotheses to test in your own data.

Measure completion, not volume

Lines of code and pull request counts will look great after rollout. Track issue cycle time, merged-to-released rate, rework rate and time-to-merge instead. If code volume climbs and issue throughput stays flat, you have reproduced the paper's finding in-house.

Keep changes reviewable

An agent can emit a 2,000-line diff in minutes; a human cannot meaningfully review it. Cap pull request size, ask agents to split work into stacked changes, and require a written plan up front. Our guides to what an agent harness is explain where those guardrails live, and Claude Code plan mode shows one way to force the plan-before-code step.

Put automated checks before human attention

Tests, linters, type checks and an AI first-pass review should filter obvious problems so humans read only what survives. The study suggests many firms are already doing this; the open question is whether it keeps pace with volume.

Beware more agents, not just more code

Throwing more parallel agents at a backlog amplifies the review queue even faster. In our write-up of the Vals AI test showing agent teams cost up to 5.1x more than one agent for barely better results, the cost side of that trade-off is already visible, and the review cost comes on top.

Watch for reward hacking and weak evals

Code that passes a benchmark or a test suite is not necessarily correct. Cursor's analysis of reward hacking in SWE-bench is a reminder that more passing code is not the same as more correct code, which is exactly what reviewers have to catch.

How this fits the "vibe coding" debate

The paper lands in the middle of a long argument about whether AI-assisted development changes what software teams produce or only how fast they type. Our explainer on what vibe coding is covers the cultural side: prompting your way to working software without reading every line. The Harvard result is a quantitative counterweight. At the level of a firm, reading every line, or deciding not to, is where the time goes.

It also connects to human-factors work such as the Berkeley and CMU study on AI assistance reducing persistence. If assistants make developers less willing to push through hard problems, review quality is one place the effect could show up, though that link is our speculation, not something either study tests.

What we will watch next

• A post-March 2026 replication. Newer agents and better review tooling may shift the numbers either way.
• Team-level and task-level cuts. Which kinds of work (bug fixes, migrations, greenfield features) convert extra code into finished issues?
• Review automation that actually reduces merge time. If AI review lowers the 49% figure, the bottleneck argument weakens; if it adds comments without speeding merges, it strengthens.
• Employment effects. The authors report little evidence that firms reduce employment after adopting these tools, a finding relevant to every hiring debate.

Bottom line

The study does not say AI coding agents are useless. It says that, across more than 700 firms through March 2026, they raised how much code got written without a statistically detectable rise in finished, tracked work, because review capacity did not scale with output. For builders, the takeaway is concrete: the next productivity gain is probably in review, testing and change-sizing rather than in generating more code. Read the paper before quoting exact figures; several numbers here come from press summaries of it.

Related reading

• Zuckerberg admits AI agents are progressing slower than expected
• What is vibe coding? The complete guide
• What is an agent harness?
• AI agent teams cost up to 5.1x more than one agent
• Cursor on reward hacking in SWE-bench
• AI assistance reduces persistence: the 10-minute study
• Claude Code plan mode guide

Figures are as reported by the paper's authors and press coverage on October 12, 2026, and may change in later versions of the working paper.