AI Coding Agents Write 30% More Code. Shipped Work Barely Changed (Harvard Study)

AI Coding Agents Write 30% More Code. Shipped Work Barely Changed (Harvard Study)

A study of AI coding productivity across 718 companies finds that AI coding agents raise code output by about 30%, with no statistically significant rise in shipped work. Harvard economists Fiona Chen and James Stratton followed these firms on the Jellyfish engineering analytics platform. After a firm adopted agents such as Claude Code or Cursor Agent, its engineers wrote more code, committed more often and opened more pull requests. The number of Jira issues and epics resolved, the closest thing to "features shipped" in the data, did not rise by a statistically significant amount.

The extra code piled up in review. Time from pull request to merge went up 49%, and the share of pull requests sent back for changes nearly doubled. This article covers what the paper measured, which numbers you can quote, what it doesn't show, and what an engineering team can change now. Every figure attributed to the study comes from the paper itself (version of August 4, 2026), read on October 25, 2026.

TL;DR

• More code: agents added 1,494 lines of code per engineer per month (+30%), 4.57 commits (+20%) and 1.22 pull requests (+23%).
• Same output: Jira issues resolved per engineer rose by a statistically insignificant 0.12 a month, about 3%. The confidence interval rules out anything above 12%. Epics show the same null.
• Review is the bottleneck: pull request time to merge went from 7.03 to roughly 10.5 days (+49%), the share of PRs with changes requested went from 13% to about 25%, and comments per PR rose from 1.66 to about 2.24 (+35%).
• Not because PRs got bigger: lines per pull request did not change significantly.
• AI review hasn't fixed it yet: nearly 80% of firms used AI in code review by March 2026, but AI wrote only 23.3% of review comments and touched 10.8% of pull requests.
• No measurable job losses, so far: the authors estimate a precise zero effect on total employment.

What did the Harvard study actually measure?

The paper uses data from Jellyfish, a platform engineering leaders use to track their teams' work. For clients who consented to research use, Jellyfish integrates up to five data streams: HR records, version control (GitHub, GitLab, Bitbucket), issue tracking (Jira, Azure DevOps), calendars, and AI tool usage for GitHub Copilot, Cursor and Claude Code. Not every firm has all five: calendar data, for example, covers 213 firms.

The analysis sample covers 725,938 workers at 718 firms from January 2021 to March 2026, about 300 million work events. That includes 68 million Jira issues, 201 million commits and 49 million pull requests. Total employment comes from LinkedIn profiles.

The design is a staggered difference-in-differences: firms adopted AI tools at different times, so the authors compare firms that had just adopted with firms that hadn't yet. The idea is that procurement steps (security review, legal approval, pilots) take different lengths of time at different companies, for reasons unrelated to how fast each company was growing.

The paper separates three kinds of tool:

Agent adoption moved fast. The share of firms with any agent went from near zero in October 2024 to over 95% by January 2026, with jumps around the launches of Cursor Agent (November 2024) and Claude Code (February 2025).

Why do some articles say 100,000 engineers and 500 companies?

Because they describe an earlier version. The first draft of the paper is dated January 7, 2026, and Jellyfish's own write-up from January 28, 2026 describes a sample of 100,000 engineers across 500 companies. The current version, dated August 4, 2026, covers 718 firms and 725,938 workers, through March 2026. The introduction rounds this to "700,000 workers across 700 firms." If you quote the study, quote one version and say which. Don't mix the January sample size with the August results.

How much more code do AI coding agents produce?

About 20% to 30% more, depending on how you count it. Here are the paper's pooled estimates per engineer per month.

Baselines for assistants differ slightly (3,498 lines, 14.84 commits, 3.78 PRs) because the assistant window is earlier. Source: Chen and Stratton, Section 3.2.

Two details help read these numbers.

1. The treatment is the firm, not the engineer. A firm counts as "adopted" from the first agent signal, but in the median firm only about 20% of engineers were using agents 12 months later (about 60% in the top fifth of firms). The 30% is averaged over everyone, users and non-users, so the effect per user is likely larger. The authors make this point themselves.
2. Pull requests are harder to inflate. Each one has to be reviewed by a teammate, so PR counts are less sensitive to chattier commit habits than lines or commits are.

The estimates sit at the low end of earlier studies, which the authors attribute to the firm-level design.

Did shipped work go up?

No, not measurably. The paper uses two output measures: Jira issues resolved (a bug fix, a feature component, a config change, counted when the code reaches production) and Jira epics resolved (whole features or projects).

The assistant baseline for issues resolved is 2.70.

An obvious objection: maybe teams took on bigger issues, so the same count hides more work. The authors tested this two ways, with an LLM label of issue size and a model predicting how long each issue would take. Neither moved.

Employment didn't change measurably either. For agents, the estimate on total employment is a precise zero that rules out a fall of more than 2.9%. Engineering headcount is noisier but rules out a fall of more than 13.8%. There was no significant change for junior or senior staff when measured separately. The authors stress this is a short-run, partial-equilibrium estimate: it compares adopting firms with firms that hadn't adopted yet. It can't rule out effects that take longer, or that hit competitors.

Where does the extra code go?

Into the review queue. The authors first estimate how engineers spend their time. From Jellyfish activity data, engineers spend 42% of their time writing code. A survey of 100 engineers on Prolific puts it at 30%. The rest is planning, review, testing and meetings. Speed up the 30-40% and the other 60-70% sets the pace.

Then they measure the review stage directly:

Assistant baselines are different: 9.34 review days, 14% of PRs with changes requested, 1.98 comments per PR, and 21% of workers reviewing.

The size row matters most. Pull requests didn't get bigger. Each one got more pushback. More PRs, each needing more revision, is how a 30% gain in writing becomes a 49% longer wait in review.

Firms did respond. They pulled more people into review (+14%) without taking anyone off coding. That's consistent with treating review as the scarce step, and also a sign that the extra code carries a cost in reviewer hours.

The paper's interviews describe what that looks like on the ground. One junior engineer:

"People could make a huge number of commits quickly, but code review was still the bottleneck. On one project, only one senior engineer was allowed to approve changes because he was the expert on the codebase. He was so bandwidth constrained that he could only review my code once a week. After some outages that were caused by AI-generated commits, there were also new rules requiring senior engineer approval for AI-generated code, which created even more review bottlenecks."

Two causes, two different fixes. The paper's model splits the effect into a productivity channel (more draft code to review) and a quality channel (each draft needs more checking). If it's only volume, you fix it by moving people into review. If it's quality, the authors say "alleviation would require improvements in the technology itself." The jump in changes requested and comments, with PR size flat, is what they read as the quality channel.

That last point sits awkwardly with Jellyfish's January summary of the early draft, which said "code quality doesn't seem to be suffering." The August version doesn't measure bugs in production. It does show the share of pull requests sent back for changes nearly doubling after firms adopted agents.

Can AI code review tools fix the bottleneck?

Not yet, on this evidence. By March 2026 nearly 80% of firms in the sample had used an AI tool in code review. But AI wrote only 23.3% of review comments, and only 10.8% of pull requests got even one AI comment. Humans still do most of the reviewing. The authors' conclusion: the bottleneck "is not simply alleviated through adoption of AI code review tools."

A senior engineer quoted in the paper explains why: "The AI tools lack the comprehension of the overview of the entire feature, and what it is supposed to do."

That matches how we position review bots in our comparison of AI code review tools: useful as a first pass that catches mechanical problems, not a replacement for the person who knows what the feature is for.

How does this compare with other AI coding productivity research?

It fits a pattern: gains are large at the keyboard and shrink further down the pipeline.

The Harvard paper's contribution is the firm setting. It can see the whole path from ticket to commit to review to deployment, so it can point to where the gain stops.

What should engineering teams do about the review bottleneck?

The paper's advice to managers is short: measure the whole production process, not lines of code or commits, and invest in the step that becomes the constraint. Here is how we'd turn that into changes. These are our recommendations, not findings from the study.

1. Change what you measure

Lines of code and commits are exactly the numbers that rose without output rising. Put these on the dashboard instead:

• PR open-to-merge time (the paper's 49% number)
• Share of PRs with changes requested
• Issues or epics resolved per engineer per month
• Time from "in progress" to "deployed"

If commits go up and these don't move, you've found your bottleneck.

2. Make the agent do the first review

The extra review load came from more PRs and more revisions per PR, not bigger PRs. You can't do much about the volume if you want the output, so the cheapest fix is better drafts. Before an agent opens a pull request, have it run the tests and linter, then run a review subagent against your team's checklist. In Claude Code that's a hook plus a reviewer subagent in the repo's shared .claude/ folder, so every engineer gets the same gate.

3. Write the spec before the code

Changes get requested when the code does something other than what the reviewer expected. Acceptance criteria in the ticket and project conventions in a shared CLAUDE.md cut that gap before a line is written. Our guide on making Claude Code work for a team covers the file layout.

4. Budget review capacity on purpose

Firms in the study drew more people into review. Do it deliberately: cap open agent PRs per reviewer, rotate review duty, and train mid-level engineers to approve in areas where one senior person is the only gatekeeper. The interview quote above (one approver, reviews once a week) is a single point of failure.

5. Use AI review as triage

Let a bot handle style, missing tests and obvious bugs so the human spends their time on intent and design. Track how often its comments are acted on. If engineers ignore them, they're noise in a queue that's already too long.

6. Gate risky code paths

In one interview from the paper, outages caused by AI-generated commits led to rules requiring senior sign-off on AI code, which made the queue worse. Automated checks on auth, payments and migrations (see our Claude Code security audit guide) let you keep the guardrail without routing every PR through one person.

Agents writing more code than your team can review? We set up Claude Code for engineering teams: shared configs, review subagents, CI gates and the metrics above, then train your engineers to work that way. See Claude Code training for teams or work with our Claude Code developers.

What are the study's limits?

• It isn't peer reviewed. It's a Harvard job-market paper. The numbers may change in later versions, as they already have since January.
• The sample is Jellyfish clients only. Companies that pay for engineering analytics and consent to research use may not be typical.
• It's short run. Most agent adoption happened in 2025, and the data ends in March 2026. Teams may still be adapting their process.
• The estimates are firm-level averages. The design measures what happens to a firm when it adopts, not what a heavy individual user gets.
• Jira is a proxy. Resolved issues and epics are the best output measure available at this scale, but they're not revenue or customer value.
• On independence: the research was funded by the Stripe Economics of AI Fellowship, a Harvard Kennedy School program and Schmidt Sciences. The authors say Jellyfish reviewed the manuscript only to check it disclosed no proprietary information, not for its scientific content.

FAQ

What is the Harvard Jellyfish AI coding study?

It's a working paper by Harvard economists Fiona Chen and James Stratton titled "Artificial Intelligence in the Firm: Bottlenecks in Software Production." It uses Jellyfish engineering data from 718 firms and about 726,000 workers to estimate how AI coding assistants and agents changed coding activity, shipped work, code review and employment. The current version is dated August 4, 2026.

Do AI coding tools increase productivity?

They increase coding output, but in this study that didn't carry through to shipped work. AI agents raised lines of code by 30% and pull requests by 23% per engineer, while Jira issues resolved showed no statistically significant change. Assistants like Copilot autocomplete had smaller effects, mostly not significant.

Why doesn't more code mean more features shipped?

Because writing code is only 30-40% of an engineer's time, and the other stages didn't speed up. After agent adoption, pull requests took 49% longer to merge and nearly twice as many were sent back for changes. The paper calls this a code review bottleneck.

Did AI coding agents cause layoffs in the study?

The study found no measurable effect on employment. The authors estimate a precise zero effect on total employment, ruling out a decline larger than 2.9%, and no significant change for junior or senior workers. They note this is a short-run estimate.

Do AI code review tools solve the review bottleneck?

Not on current evidence. Nearly 80% of firms used AI in code review by March 2026, but AI produced only 23.3% of review comments and appeared on 10.8% of pull requests. Teams that use them well treat them as a first pass, as covered in our AI code review tools comparison.

How should we measure the ROI of Claude Code or other AI coding agents?

Measure the pipeline, not output at the keyboard: PR open-to-merge time, share of PRs with changes requested, and issues resolved per engineer. The Harvard paper shows lines of code and commits can rise sharply while shipped work stays flat. We set up this kind of tracking as part of Claude Code training for teams.

Is the study peer reviewed?

No. It's a job-market paper, first released January 7, 2026 and revised August 4, 2026. Earlier coverage citing 100,000 engineers at 500 companies refers to the January version.

---

Sources: Chen and Stratton, "Artificial Intelligence in the Firm: Bottlenecks in Software Production" (August 4, 2026), Jellyfish, "New Research from Harvard & Jellyfish" (January 28, 2026), METR, early-2025 AI developer productivity study (July 10, 2025)