AI Coding Productivity Study: 30% More Code, 12% More Work

8 min read

Came here from Instagram, LinkedIn, X or YouTube? Here is the full source list you came for. Everything below is built from these, nothing else.

The report

• InfoQ: Study Finds AI-generated Code Fails to Boost Productivity Due to Downstream Bottlenecks, by Sergio De Simone, Oct 22 2026

The developer reactions (Reddit, quoted in the same report)

• Comments from Prime_1, markehammons and enigmamonkey, via InfoQ, Oct 22 2026

Picture a restaurant kitchen on a busy night.

The owner buys the line cooks a machine that preps food much faster. Onions, sauces, everything. Prep output goes way up.

But every plate still has to pass one counter where the head chef tastes it, checks it, and either sends it out or sends it back. That counter did not get a machine. So the plates pile up there. More of them get sent back, because fast prep is sloppier prep. The chef starts pulling cooks off the line to help taste.

At the end of the night, the kitchen made a lot more food. Customers got only a little more of it.

That kitchen is what a new Harvard study found inside software teams using AI. The prep machine is your coding agent. The tasting counter is code review. And the gap between "more food made" and "more food served" is the gap between 30% more lines of code and 12% more finished work.

Let me walk you through the concept, the numbers, and a small model you can use on your own team.

Key takeaways

• A Harvard study of 718 firms, built on Jellyfish data, covered about 300 million work events from 700,000 workers between January 2021 and March 2026.
• AI agents raised lines of code by 30%, commits by 20% and pull requests by 23%. Resolved Jira issues rose only 12%.
• AI coding assistants raised resolved issues by nothing measurable. Only their effect on commits was statistically significant.
• Engineers spend just 30 to 40% of their time writing code. The rest is planning, review, testing and deployment.
• Review got heavier: 49% longer time to review per PR, 53% more comments per PR, and twice the share of PRs needing changes.
• 14% more workers ended up doing code reviews, and using AI to help with reviews did not improve things.

What did the Harvard study of 718 firms actually find?

The researchers used the Jellyfish analytics platform, which connects data from tools like GitHub and Jira to measure engineering performance. They pulled from HR records, version control, issue trackers, calendars like Google Calendar, and the AI tools themselves, including GitHub Copilot, Cursor and Claude Code.

They measured coding output three ways: lines of code added, commits, and pull requests. Then they measured finished work as Jira issues and epics resolved per worker per month. An issue is one unit of engineering work. An epic is a bigger project or feature.

Here is the headline split between the two kinds of AI tool.

Measure	AI coding assistants	AI coding agents
Lines of code	+12% (not significant)	+30%
Commits	+9% (significant)	+20%
Pull requests	+5% (not significant)	+23%
Resolved issues	No increase	+12%

Read the agent column top to bottom. Code goes up 30%. Finished work goes up 12%. Something between writing the code and closing the ticket is eating more than half the gain.

Why doesn't more AI-generated code mean more finished work?

Because writing code was never most of the job.

The researchers estimated how engineers split their time from the Jellyfish data, then checked it with a survey of 100 engineers on Prolific. The answer: 30 to 40% of time goes to writing code. The other 60 to 70% goes to what they call complementary tasks: scoping features, reviewing code, testing, deploying.

In their words:

When AI raises productivity in code writing, complementary steps may serve as bottlenecks.

This is the whole concept. If you speed up one stage of a pipeline, the pipeline only goes as fast as its slowest stage. And if your fast stage also creates extra work for the slow stage, you can end up barely faster at all.

Here is a ceiling you can work out yourself from the study's own range. Suppose AI made writing code instant, zero hours. If coding was 40% of the week, the remaining 60% caps you at about 1.67 times the output. If coding was 30%, the cap is about 1.43 times. That is the best possible case, and it assumes the other stages do not get heavier.

The study found they did get heavier.

How does the review bottleneck work, step by step?

Here is the chain the study describes, in order.

1. The agent writes more code. Lines of code up 30%, pull requests up 23%.
2. Every one of those PRs lands in the review queue. Nothing about the agent changes the fact that a human has to read it.
3. Each review takes longer. Average time to review a PR rose 49%.
4. Reviewers find more to say. Comments per PR rose 53%.
5. More PRs bounce back. The share of PRs that needed changes doubled. Every bounce sends work back to step 1 and then through review again.
6. More people get pulled into reviewing. The share of workers doing code reviews rose 14%. Those hours come out of something else.
7. AI review did not save it. Adopting AI to assist with reviews brought no improvement.
8. Finished work rises a little. Resolved issues up 12%.

One detail matters a lot here. The authors checked whether reviews got harder simply because PRs got bigger. They did not. The extra review effort could not be explained by larger PRs. Same size PR, more time, more comments, more rejections.

So it is not volume alone. Per PR, AI-written code needs more human attention before anyone trusts it.

Why would AI code need more review per PR?

The study reports the effect. The developers reacting to it on Reddit offered some reasons, and they match what you probably feel at work.

Reddit user Prime_1 put it in one line: "every line of code is a potential liability".

markehammons pushed that further, pointing at hallucinations:

Doubly so when you're dealing with an untrustworthy actor, and agents are more untrustworthy than most actors. They can do the most messed up stuff without any hint of malice, and in a misguided attempt to pursue the task given to them.

That is the tasting counter again. The head chef cannot assume the plate is right just because it came out fast. They have to check it, and checking takes the same time whether the plate took one minute or ten to make.

And enigmamonkey raised the cost that shows up later, after merge:

If your engineers are writing and understanding less and less of the code they ship, I imagine issues become more frequent and more complicated to resolve. Particularly as the codebase scales… and it will scale.

Their suggestion was that mean time to recovery could become a more important metric for judging AI's impact. That is an opinion, not a study finding, but it is a sensible thing to start watching.

When should you use AI coding agents, and when not?

This is my read of the numbers, not advice from the paper.

Agents look worth it when:

• You measure finished work, not code. In this data agents moved resolved issues 12%. Assistants did not move them at all. If you are paying for a tool, that is the number to check.
• Your review capacity has slack. If reviewers are already idle half the day, extra PRs fill a gap instead of forming a queue.
• Coding really is your slowest stage. For some solo builders and small teams, writing code is most of the week. The study's 30 to 40% figure is an average across hundreds of firms, not a law.

Be careful when:

• Review is already your bottleneck. If PRs wait days for a reviewer today, an agent mostly makes that line longer.
• You are tracking lines of code or PR count as success. Those went up 23 to 30% in this study while finished work went up 12%. The dashboard will look great while delivery barely moves.
• You plan to fix review with more AI. In this study, AI-assisted review did not help.
• Nobody on the team understands what was merged. That is where enigmamonkey's recovery worry lives.

The practical move is simple. Before you add more code generation, look at the stage right after it. Measure how long PRs wait, how many get sent back, and how many people are reviewing. If those numbers climb after an AI rollout, you have found your tasting counter.

A small model you can run on your own team

First, the pipeline as a diagram in words:

plan  ->  write code  ->  review  ->  test  ->  deploy  ->  issue resolved
          [AI speeds      [same humans,
           this up]        more PRs,
                           more rework]
                              |
                              +--> changes requested --> back to write code

Now the arithmetic. This Python snippet takes the study's 30 to 40% coding share (I use the 35% midpoint) and asks: if coding gets faster but downstream work grows, how much more finished work do you get per week?

CODING_SHARE = 0.35            # study: 30-40% of time is writing code
OTHER_SHARE = 1 - CODING_SHARE # planning, review, testing, deploy

def extra_output(coding_speedup, downstream_growth):
    hours_per_task = (CODING_SHARE / coding_speedup
                      + OTHER_SHARE * (1 + downstream_growth))
    return 1 / hours_per_task - 1

for speedup, growth in [(2, 0.0), (2, 0.10), (2, 0.25), (1000, 0.0)]:
    print(f"coding {speedup}x faster, downstream +{growth:.0%}: "
          f"{extra_output(speedup, growth):+.0%} finished work")

Output:

coding 2x faster, downstream +0%: +21% finished work
coding 2x faster, downstream +10%: +12% finished work
coding 2x faster, downstream +25%: +1% finished work
coding 1000x faster, downstream +0%: +54% finished work

The speedups and growth rates here are made-up inputs, not figures from the study. The point is the shape. Doubling your coding speed is worth about 21% if nothing else changes. Let review, testing and rework grow by just 10% and you are down to 12%. Let them grow by 25% and the gain is close to zero.

Swap in your own numbers. Pull your average time to review and your share of PRs with changes requested from before and after your AI rollout, and turn that into a rough downstream growth figure. It will tell you more than any lines of code chart.

FAQ

Does AI actually make developers more productive?

In this study of 718 firms, AI coding agents raised resolved Jira issues by 12%, while AI coding assistants did not raise them at all. Agents raised raw code output by 20 to 30%, so most of the visible gain did not turn into finished work. Productivity went up a little with agents, far less than code volume suggests.

Why did code review take longer with AI-generated code?

The study found average time to review a PR rose 49%, comments per PR rose 53%, and the share of PRs needing changes doubled. The authors found this could not be explained by PRs getting bigger. Developers reacting on Reddit pointed to trust: agent code can be wrong in unexpected ways, so reviewers have to check it more carefully.

Are AI coding agents better than AI coding assistants?

On output, yes. Agents raised lines of code 30%, commits 20% and pull requests 23%, all significant, and lifted resolved issues 12%. Assistants raised lines of code 12%, commits 9% and pull requests 5%, with only the commit effect significant, and no increase in resolved issues.

What should engineering teams measure instead of lines of code?

The study itself measured finished work as Jira issues and epics resolved per worker per month. Alongside that, watch the review stage: time to review, comments per PR, and the share of PRs sent back for changes. One Reddit commenter also suggested mean time to recovery as a metric worth tracking as more code gets AI-written.

This week, pull your team's time to review from before and after your AI rollout and run it through the model above. While you are at it, try the free tools on Art of Code, or if review skills are what your team is short on, look at who is hiring on Art of Code jobs.

Written by Adithya Guttha, Founder of Art of Code.