AI Writes 30% More Code, Ships None Extra: Harvard Study of 718 Firms Exposes AI Coding's New Bottleneck

For the past two years, AI coding tools have all marketed themselves with the same sentence pattern: "our model is X% faster, code generation up Y%." A study that circulated on October 11–12, 2026 just poured cold water on that pattern with real data from 718 companies: AI coding agents lifted code volume by 30%, while the amount of software actually shipped barely budged.

This is not a vendor's internal pilot or a survey of a few dozen developers. Harvard economists Fiona Chen and James Stratton got their hands on full telemetry from the engineering-analytics platform Jellyfish — 718 software firms, 725,000 engineers, roughly 300 million work events, spanning January 2021 to March 2026. Using the standard staggered difference-in-differences design from economics, comparing the same firms before and after AI adoption, they concluded: the bottleneck has moved from writing code to reviewing it.

The working paper is titled Artificial Intelligence in the Firm: Bottlenecks in Software Production. It may be the largest empirical study to date of AI coding tools' real-world enterprise impact, and it deserves a careful read from everyone who writes code with AI every day.

1. What the study actually did

First, why this study carries unusual weight. Past evidence on "does AI coding actually help" came from three sources: vendors' own productivity reports (drawn from their own users, structurally optimistic), developer surveys of dozens to hundreds of people (subjective, thin on hard data), and isolated big-company pilots (small samples, narrow scenarios).

Chen and Stratton took a different road. Their Jellyfish data is engineering telemetry — GitHub commits, PRs, Jira issue states — machine-recorded behavior, not survey self-reports. The 718 firms adopted AI tools at different times, and that staggered timing lets researchers strip out confounders like "teams that were already improving." Three hundred million work events give the statistical conclusions a completely different level of footing.

The study also draws one crucial distinction: autocomplete-style assistants and fully agentic tools behave nothing alike. Autocomplete tools raised lines of code by about 12%, with only the commit count reaching statistical significance; truly agentic tools — the kind that write code and open PRs on their own — delivered +30% lines of code, +20% commits, and +23% PRs, all statistically significant. In other words, the more autonomous the tool, the more inflated the output.

2. The headline finding: 30% more code, zero more software

Line the study's core numbers up side by side and the story tells itself:

Above: after AI coding agent adoption, every output metric rose and review burden rose with it — but finished software did not follow. Source: the Harvard working paper.

Metric	Change	Note
Lines of code	+30%	agentic tools, statistically significant
Commits	+20%	statistically significant
Pull requests	+23%	statistically significant
Resolved Jira issues / epics	no significant change	study explicitly rules out output gains above 12%
Avg. PR review time	+49%	direct evidence from the review stage
Share of PRs sent back for changes	nearly doubled	quality friction is rising
Comments per PR	+35%	reviewers working harder to find flaws
Share of employees doing review	+14%	firms forced to reassign people to review duty

The contrast between the first three rows and the fourth is the entire paper: more code entered the pipeline, more commits and PRs flowed through it, but the work items marked "done" stood still. The authors' wording is restrained — "little evidence that firms increase software output." The data is not: review time up 49%, send-back rates doubled. That can't be hand-waved as "AI writes bad code"; it's a systemic capacity mismatch.

One detail deserves attention: the study statistically ruled out even output gains above 12%. This isn't "maybe it grew a little but we couldn't measure it" — it's "it couldn't have grown by much." For practitioners used to hearing vendors pitch "10x engineers," that's a jarring result.

3. Anatomy of the bottleneck: why review got slower

Code review was never designed for the AI era. Reviewing a colleague's PR, you can assume they understood the requirement, tested the obvious edge cases, and wrote something roughly matching team conventions. You're checking "did this person make a silly mistake." Reviewing AI-generated code is a different checklist entirely: does it actually solve the stated problem? Did it introduce a subtle security flaw? Did it reinvent logic that already exists in the codebase? Will the person maintaining this in six months curse your name?

AI turned review from "checking whether a colleague made a mistake" into "verifying what the machine actually did" — two completely different cognitive burdens.

That scrutiny is more expensive, and it doesn't scale the way generation does. In the time an agent produces ten PRs, a human reviewer may carefully get through one. When PR volume rises 23%, review queues lengthen even if each individual review takes no longer than before. The paper's data confirms the mechanism: review time +49%, and firms already added reviewers (+14% of employees doing review) without clearing the queue.

The 21 interviews in the paper are the most persuasive part. One senior engineer's account, roughly: tools like Claude Code can "write a draft in two seconds that's correct 90 percent of the time" for routine work, but "make frequent mistakes" on harder tasks — and "you end up spending more time reviewing." That punctures an illusion: AI saves typing time and takes on trust debt, and the interest on trust debt is paid at the review stage.

One easily missed finding: the bottleneck persisted even at firms that had already adopted AI code-review tools, because the human reviewer kept final sign-off. AI can triage and summarize a PR, but no company's process dares hand "can this merge to main" entirely to a machine. The review bottleneck is therefore not a temporary "tooling hasn't caught up" phenomenon — it's a hard constraint rooted in how organizations assign responsibility.

4. A counterintuitive result: no layoff wave

The paper has another finding worth pulling out on its own: firms that adopted AI coding agents saw no significant change in total employment or engineering headcount.

That directly contradicts two years of "AI will kill junior developers" panic. The picture in the data: companies didn't cut staff because AI could write code; they reallocated the freed-up (or newly created) capacity into review, testing, and rework. Headcount stayed flat, but the ratio of "people who write code" to "people who review code" shifted.

My read: AI didn't eliminate software engineering work — it squeezed work from the "production" stage into the "verification" stage. That's good news for employment in the short term; in the longer term it raises a sharper question — if verification costs refuse to come down, is AI delivering a productivity revolution, or an expensive "code inflation"? I want to use that phrase deliberately: when money is over-issued, each unit buys less; when code is over-issued, each line is trusted less, and review is the process of repricing that trust.

5. That same week, vendors were already voting with their feet

Interestingly, the product moves from big vendors in the very week the paper circulated read like footnotes to it:

• Microsoft redesigned Copilot (Home / Code / Autopilot): the new Code tab has agents build and test inside a sandbox before anything reaches a shared repo; Autopilot gives agents their own identity and Outlook accounts — both answers to "how do we make agent output more trustworthy and auditable."
• Microsoft moved billing to per-seat-plus-consumption: under flat per-seat pricing, agents could generate unlimited code at no marginal cost; now every generation has a price. That's a price mechanism forcing teams to "think before generating" — a direct hedge against code inflation.
• GitHub Copilot CLI's computer-use entered public preview (Oct 1): agents can now operate desktop apps, more autonomy — which, by the paper's logic, tightens the review choke point further unless triage tooling keeps pace.
• Google's CodeMender and similar tools that do only security-finding triage are being positioned on their own: don't touch generation, specialize in the layer right before review.
• Anthropic added Mods to Claude Code (customizable TypeScript functions): the idea is to make agent behavior more predictable and better fitted to team conventions, cutting rework at the source rather than piling tools after review.

October's release calendar from vendors is converging on a single point: generation is fast enough; the next contest is review throughput and delivery certainty.

See the shift: 2024–2025's competitive keywords were "generation speed" and "benchmark scores"; October 2026's are "sandbox," "audit," "triage," and "consumption billing." The paper merely said out loud, with 718 firms of data, what vendors already knew.

6. Five suggestions for vibe developers

If you're a solo developer plus AI, or lead a small team, this paper isn't bad news — it's an action guide. As the bottleneck moves from generation to review, competitive advantage moves from "who writes fastest" to "who ships most reliably." Five concrete things to do:

1. Slice PRs small — small enough to review at a glance. Much of that +49% review time comes from AI dumping enormous diffs at once. An 800-line AI-generated PR gets skimmed; four 200-line PRs each get genuinely read. Having the agent commit in small steps is the cheapest trust-building there is.

2. Give the agent a "reviewer agent" for pre-screening. Keep final sign-off human, but let a second model triage first: summarize what changed, flag risks, run security scans. The paper found the bottleneck persists even with AI review tools — but that's about final sign-off, not pre-screening. Pre-screening relieves cognitive load; sign-off assigns responsibility. Different jobs.

3. Move testing earlier, not later. AI made code cheap, so verification must get cheap too, or the pipeline stays clogged at review. Tools like Meticulous — which auto-generate thousands of user flows and diff at the pixel level (it coincidentally just raised a $15M Series A last week) — sell exactly this: let the agent finish testing before a human ever sees the PR. The more deterministic the tests, the faster reviewers dare to go.

4. Put a price on generation. Microsoft's consumption billing is a signal: every agent call will soon have a marginal cost. Small teams can start doing the accounting now — token budgets for agents, requiring trade-off explanations when it generates competing drafts. Free generation breeds bad engineering habits.

5. Track rework rate, not generation volume. Stop counting how many lines your agent wrote today. Count its PR first-pass rate, send-back count, and submit-to-merge time. Those are the metrics the paper actually links to "delivery" — and they're the north star for your personal workflow.

7. My take

The paper's real impact isn't the "30%" number — it's that it retires a narrative: the equation "faster generation = faster delivery" is officially dead. The industry spent four years optimizing generation speed; the next years' competition will be fought over review throughput, verification cost, and delivery certainty.

For the vibe coding community, that's good news. Solo developers never won on "writing code faster than big companies" — AI flattened that. The real edge is end-to-end ownership: requirements, generation, testing, review, and release all in one person's hands, where the review bottleneck is naturally small. While big companies agonize over +49% review times, an indie developer who owns 100% of their code is standing in a surprisingly advantageous spot.

In the age of code inflation, code is no longer scarce. Trust is. And trust is exactly what small teams are best at producing.