Coding agents add 30% more code, but not more shipped work

You asked your coding agent for a feature and had it done in an afternoon. You opened the pull request so someone on the team could review it, and there it sat: four days waiting. When someone finally looked at it, it came back with six comments, half of them about things the agent changed without you asking. The afternoon you saved was lost over the following week.

It isn’t just you. A study by two Harvard economists, which became one of the most discussed topics among developers on October 12, measured it across 718 companies: with coding agents people write 30% more code, but teams don’t finish more work. Below are the numbers, why the gain gets lost in review, and five things you can do before sending each change. They’ll take you about fifteen minutes per pull request, and they’re the minutes that pay off most in the whole process.

What the study measured

The study is called “Artificial Intelligence in the Firm: Bottlenecks in Software Production” (opens in a new tab). Its authors, Fiona Chen and James Stratton, worked with data from Jellyfish, a company that sells a system for measuring engineering team activity. They gathered about 300 million work records from roughly 700,000 people, between January 2021 and March 2026: what code each person pushed to GitHub, which tasks they closed in Jira (the system where a project’s tasks are organized), how much time they spent in meetings.

The comparison is easy to follow. Each company adopted AI tools at a different moment, depending on how long its security and procurement teams took to approve them. So you can compare the companies that adopted them earlier with the ones that hadn’t yet, and see what changed.

The study separates two kinds of tool, and the difference matters:

• An assistant completes code as you type, like Copilot’s autocomplete. You keep writing; it saves you keystrokes.
• A coding agent, like Claude Code, Cursor, or Codex, takes a task, opens files, runs commands, and hands back the finished change.

The numbers

First, what happens to the code written. A commit is each time a change is saved to the project’s history, and a pull request is the formal request for that change to be merged into the main code, which someone on the team has to review and approve.

Per person, per month	With assistant	With agent
Lines of code	+12% (not significant)	+30%
Commits	+9%	+20%
Pull requests	+5% (not significant)	+23%

With agents, each person adds about 1,500 more lines a month. So far, the promise holds.

Then, what matters: does more work get finished? The authors measure it by the tasks and projects closed in Jira, which get closed once the code is running in production. There the effect is so small it can’t be told apart from zero. At most, finished work goes up 12%: less than half of the extra 30% of code. The number of people employed at those companies didn’t change either, junior or senior.

Where the time went

Writing code is only part of the job. According to the same study, a developer spends between 30% and 42% of their time writing. The rest goes to planning, reviewing other people’s code, and testing. If you speed up just one stage, work piles up at the next one.

And it piled up in review. With agents:

• A pull request used to take an average of 7 days from submission to approval. It went to about 10 and a half: 49% more.
• Pull requests that come back with a formal request for changes went from 13% to 25%. Nearly double.
• Comments per pull request went up 35%.
• The share of the team spending time on review grew 14%.

There’s one fact that changes how to read all of this: pull requests didn’t get bigger. They have the same number of lines as before. So the problem isn’t only that more changes arrive, it’s that each change needs more fixes. The model the authors propose puts it this way: AI changes how much code gets written, but also how many errors that code carries, and each error is extra work for whoever reviews it.

Besides the data, the authors interviewed engineers at different companies and quote some of their answers in the paper. This one is from a junior developer:

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.

AI review didn’t fix it

The obvious answer is to have AI review what AI wrote. Companies tried: by March 2026, nearly 80% were using some automated review tool. But those tools write only 23% of the comments, and barely 11% of pull requests get one. The person who approves is still a person, and the bottleneck is still there.

Five things you can do before sending the change

The study doesn’t say agents are useless. It says the time saved gets lost in review, and a large part of that review depends on how the change arrives. This is what’s in your hands:

1. Review it yourself first, as if someone else wrote it

Before asking for review, open your own pull request and read the changes line by line, on the same screen your teammate will see them. You’ll find files the agent touched for no reason, odd names, leftover debugging code. Everything you fix yourself is one less comment and one less round trip. This article has the list of what to look for.

2. Remove what you didn’t ask for

Agents tend to “improve” things along the way: they reorder imports, rename a variable in another file, reformat an entire function. That bloats the change and forces the reviewer through lines that have nothing to do with the task. If the agent touched something that wasn’t part of the request, revert it. And next time, tell it explicitly what not to touch: a good spec saves you this step.

3. Show that you tested it

“It should work” forces the reviewer to check on their own. Run the tests before sending it and say in the description what you tested by hand. “I tried the form with an invalid email and with an empty one; both show the error” saves your teammate from doing the same.

4. Explain the why and where to look

A short description changes how a change gets reviewed. It doesn’t need to be long; this is enough:

## What changes
Orders with an expired coupon are now rejected before charging.

## Why
Today we charged the full price and the customer complained afterwards.

## Where to look carefully
- `validateCoupon()`: the date comparison uses the server's time zone.

## What's mechanical
- The changes in `types.ts` are just the new field.

## How I tested it
- Automated tests pass.
- Expired, valid, and no coupon, by hand in the local environment.

The “where to look” section is the one that pays off most: it tells the reviewer where to focus and where they can move quickly.

5. Separate the mechanical from the important

If the change includes a mechanical part (renaming something across thirty files, moving folders) and a part with new logic, send them as two separate pull requests. The mechanical one gets approved in five minutes; the important one gets reviewed carefully. Mixed together, the important one gets buried in noise.

If you run the team

The study leaves two conclusions for whoever leads a team. The first: counting lines or commits doesn’t measure what AI delivers, because those numbers go up even when nothing more gets shipped. What’s worth measuring is how long a change takes to get approved and how many come back with changes requested.

If your repository is on GitHub, you can see the first number today. This command uses gh, GitHub’s official command-line tool, and jq, a program for processing JSON data. It computes the average number of days the last fifty merged pull requests took:

gh pr list --state merged --limit 50 --json createdAt,mergedAt \
  | jq '[.[] | ((.mergedAt | fromdate) - (.createdAt | fromdate)) / 86400] | add / length'

Run it today and again in a month. If it goes up, review is getting stuck.

The second conclusion: if one stage speeds up, the bottleneck moves to another, and people have to move there too. In practice, that means treating review as planned work, with hours assigned every week, and not as something done in the gaps between tasks.

Now what’s scarce is whoever reads

For years, a team’s limit was how much code it could write. Agents moved that limit, and now the limit is how much code the people approving it can read and understand. That isn’t fixed by writing faster. It’s fixed by sending changes that can be reviewed quickly: small, tested, and explained. That part is still done by a person, and it’s what decides whether the afternoon you saved with the agent turns into something that reaches production.