AI Productivity Paradox: The Work Moves to Review

The AI productivity paradox is that people using AI produce much more, while their companies finish only a little more. The best evidence so far is a Harvard working paper that followed 720,542 software workers at 655 firms. Twelve months after a firm adopted AI coding agents, its engineers made 36% more commits and opened 35.7% more pull requests (code submitted for review). Finished tasks rose 13.7% and finished projects 18%, and the authors call both marginally insignificant. Their own name for it is “the null output result.” Headcount didn’t change in any way they could detect. The extra code piled up in review: the time from submitting code to getting it approved rose 56.1%. AI sped up the step it touches, and the work waited at the next step, where a person has to check it.

I think that finding matters more to a small company than to a big one. The paper studied mostly medium-to-large firms, so that part is my reading: in a team of eight, the person at the next step is usually the owner.

A video called “Harvard Just Discovered AI Isn’t Actually Working” sent me to the paper. The video gets the direction right. Its Harvard numbers come from the paper’s August draft, one finding is credited to the wrong study, and the title says more than the paper does. So I went to the sources, and everything below links to them. Sources read November 14, 2026; the Harvard numbers are from the paper’s November 9, 2026 version.

You should know what I sell. I set up Claude for small teams, so a paper saying AI doesn’t pay would hurt me, and one saying it pays for everyone would help me. This one says it pays where someone can keep up with checking the output, which is roughly what I tell clients anyway. Weigh that.

What the Harvard study measured

The paper, by Harvard economists Fiona Chen and James Stratton, uses data from Jellyfish, an analytics platform engineering teams use to track their work. It covers GitHub activity, Jira tickets and Google Calendar from January 2021 to August 2026, plus which firms used GitHub Copilot, Cursor or Claude Code. Firms adopted AI at different times, often depending on how long their security and legal approvals took, so the authors compare firms that had adopted with firms that hadn’t yet.

The agent numbers sit on top of what the earlier tools already did: the paper measures “the added effect of agent adoption, relative to AI assistant adoption.” Those earlier assistants, autocomplete tools like early Copilot, are starker on their own. They raised pull requests 20.9%, and resolved tasks moved −1.5%, which is nothing. The authors call the effect on finished work “much smaller in magnitude” than the jump in code.

One fair objection is that AI might make each task bigger, so the same count of tasks hides more work. The authors had models estimate how long each Jira task would take from its description, and found “no evidence of an effect on the average predicted length of each issue.”

Two caveats. It’s a working paper, not yet through peer review, and the numbers have moved between drafts: Jellyfish’s January write-up of the first version described 500 companies. And Jellyfish sells the analytics the data comes from. The paper says Jellyfish reviewed it only for proprietary information, and “it was not reviewed for its scientific content.”

Where the saved time went

Writing code was never most of an engineer’s week. From the activity data, engineers spent 40.8% of their time writing code before AI; in a survey of 100 engineers, 30.8%. The rest goes to the work around the code, from planning to review. Even a perfect coding tool can speed up only that slice. Eliyahu Goldratt built a whole novel about a factory, The Goal, on that idea: a plant runs only as fast as its bottleneck.

The paper found the bottleneck in code review. After agents arrived, code waited 59.9% longer before anyone started reviewing it, and review itself took 58.5% longer once it started. Each change drew 38.6% more comments, and the engineers the authors interviewed said AI code needed more correcting in review. That’s the “almost right” problem developers complain about most. One senior engineer put it plainly:

For simple and routine tasks, there’s so much documentation, so the models are very well-trained. With Claude Code, I can write a draft in two seconds and it’s going to be right 90% of the time; I just have to do a little bit of testing myself. There is a huge speed-up, on the order of 100x. But for deeper engineering tasks, it doesn’t really save as much time — it gets stuff wrong a lot, and you end up spending more time in the review process.

Firms can’t just move anyone onto review. People review code they already know (82.8% of reviews were in a codebase the reviewer had worked in), and senior engineers review senior engineers. A junior engineer described the result:

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 reviewers haven’t fixed it yet. Most of the firms (79.1%) had adopted an AI code review tool, and humans still wrote “the overwhelming majority of reviews and comments.”

We run an AI reviewer on our own code, and it eats time in its own way. Once, it and one of our nightly routines argued on a single pull request for 21 hours, through 147 review runs, each one doing exactly its job.

We hit the human version too. Before we split our pull requests into two lanes, the median one took about 4.9 hours to merge (August 1 to September 10). In the five weeks after the split, to October 16, document changes merged themselves in a median of 83 seconds, and the changes that still needed one of us took about 42.6 hours. Only the hard ones are left in that queue, and we put them off.

The authors’ model puts the effect in one line: agents raised coding productivity 73.7%, and firms moved people from writing code to reviewing it.

The same shape outside software

The authors think the shape reaches past software: the split between “implementation” and “management” or “review” is “nearly ubiquitous across knowledge work settings.” They also say effects may differ in other kinds of knowledge work. Medicine has two good studies on it.

A JAMA study followed 8,581 clinicians at five academic health systems, 1,809 of whom got AI scribes that draft the visit note. Per eight scheduled patient hours, scribe users spent 16.0 fewer minutes on documentation and 13.4 fewer minutes in the health record overall. They had 0.49 more visits a week. Time in the record after hours didn’t change significantly. The authors call all of it “modest.”

A smaller simulation in JAMIA Open shows where the time goes. Nine primary care doctors ran simulated visits with and without a scribe. Time spent typing and writing the note fell 69.1%. The part after the patient left, from reviewing the note to finishing the chart, grew from 16.2% to 23.2% of the encounter. That difference falls just short of statistical significance. The authors suggest it “could be attributed to reviewing and editing the AI scribe-generated SOAP note.” Visits overall weren’t significantly longer or shorter. Typing moved to checking, the same as in software.

The video cites that 23.2% as part of the JAMA study. It comes from the nine-doctor simulation. The video also reads it as less time with patients, which the study didn’t test, though its own averages lean that way.

Amazon’s fix was more review

In March, Amazon’s retail site had a run of outages, and Business Insider saw the internal documents. Two incidents stand out, and only one of them involved AI. On March 2, customers saw wrong delivery times, which cost nearly 120,000 orders, and an internal review named Amazon’s own AI tool, Q, as one of the primary contributors. A document about it warned that “GenAI’s usage in control plane operations will accelerate exposure of sharp edges and places where guardrails do not exist.” On March 5, a bigger outage caused “a 99% drop in orders across Amazon’s North American marketplaces, resulting in 6.3 million lost orders.” One key factor, per the documents, was a change deployed without Amazon’s formal documentation and approval process. Business Insider doesn’t tie that one to AI.

The response was a 90-day temporary safety guideline. The executive in charge wrote that it “will introduce controlled friction to changes in the most important parts of the Retail experience.”

The video blames the 6.3 million lost orders on an AI-assisted change and says senior engineers now sign off on all AI-assisted code. The documents tie AI to the smaller March 2 incident. Amazon’s spokesperson went further: only one incident was AI-related, none involved AI-written code, and juniors don’t need senior sign-off for every AI-assisted change. Whichever account is right, Amazon’s fix was more friction at the point where a person approves a change before it ships. That’s a close cousin of the code review the Harvard paper found was already the bottleneck.

What the video gets right and wrong

The video also cites token budgets, Amex and Netflix layoffs, and law and accounting cases I didn’t check, so I’ve left them out.

Will AI cut jobs anyway?

Probably some, and the paper says so, which the video leaves out. The authors fed their estimates into a model of how firms adjust over the next five years. If review stays as slow as it is now, they predict software output rises 57.8% by 2031 and engineering employment falls 10.3%. If AI speeds up review as much as it sped up coding, output rises 341.4% and employment falls 76.2%, which the authors call an upper bound. Whether review stays slow decides most of it.

The big layoffs in the news are a different question. Fortune and the AP both report Microsoft’s buyouts alongside its heavy spending on AI, and neither quotes Microsoft saying AI now does the work of the people leaving. Paying for AI and being replaced by it are two different reasons to lose a job, and the Harvard data only speaks to the second.

What this means for a small team

On a big engineering team, the bottleneck is a senior reviewer who has a queue. On a team of eight, it’s usually the owner, or the one person who knows the client. Here is what I’d take from the paper.

1. Find the reviewer before you buy seats. For every job you hand to Claude, name who checks the output. If it’s you, AI makes more for you to read, and your week sets the pace.
2. Count finished work. Pull requests rose 35.7% and resolved tasks 13.7%. Your version of a resolved task is an invoice sent or a matter closed. Drafts don’t count, and neither do tasks an AI created that nobody finished.
3. Pick jobs where checking is cheap. A month-end close where the totals tie out or don’t is quick to check. A draft reply you can read in a few seconds is quick to check. A contract you’d have to reread clause by clause saves little, because checking it takes as long as writing it. And before any of it, ask whether the job should exist at all.
4. Cut what reaches review. Our end-of-day run created 1,042 tasks in four months, and every one passed through a gate my co-founder and I approve. Most were noise, and at that volume nobody reads the list: in one cleanup, 182 of one person’s tasks had never been touched. The fix was a script, built with Claude, that groups the drafts before they reach us, so there are fewer and better tasks to review.
5. Plan for the checking. Over four months, our company brain surfaced 626 threads where we owed a reply, and a person presses send on every draft. We put that review there on purpose.
6. Keep the people who check. Amazon answered mistakes with more review. If you cut your most experienced person to pay for AI, you cut the step the work is waiting on.

If your team pays for AI and the drafts are piling up in front of one person, that’s the shape this paper describes. The ten-question team check shows where you stand without talking to anyone. When I set Claude up for a team, the first question for each job is who reviews it and how long that takes. Setup starts at $3,997. For the other famous AI statistic, here’s where the 95% failure rate comes from. For the developer side, here’s what METR’s trial found when it timed engineers with and without AI.