Agents wrote more code. Firms shipped little more. Where did your review time go?

On 9 October 2026, Kyle Orland at Ars Technica (archived copy) published a headline that made every founder and staff engineer stop scrolling: “AI coding agents generate more code, but not more software.” Three days later, the story hit Hacker News and drew 365 points and 314 comments. Then, on 1 November, the Harvard authors quietly posted a revised version of the paper that changed most of the headline numbers.

If you use GitHub Copilot, Cursor, or Claude Code every day, you already feel the pressure the paper tried to measure. Across the firms in the study, agent adoption jumped right after Cursor Agent launched in November 2024 and Claude Code followed in February 2025. Twelve months after firms adopted agents, commits per worker rose 36.0% and pull requests rose 35.7%, while the time from submitting a pull request to getting it approved jumped 56.1%.

It looks like the 1952 “Job Switching” episode of I Love Lucy, where Lucy and Ethel work the conveyor belt at Kramer’s Kandy Kitchen. The belt speeds up, the wrappers cannot keep pace, and Lucy and Ethel start stuffing unwrapped chocolates into their mouths and hats so the forewoman will not see what got past them. By the end of this post, you can look at your own last ten reviews and see whether your attention went where the risk was, or whether you are hiding chocolates to keep the belt moving.

What the study measured, and what changed on 1 November

The working paper is “Artificial Intelligence in the Firm: Bottlenecks in Software Production” by Harvard researchers Fiona Chen and James Stratton. It uses engineering telemetry from Jellyfish across consenting client companies, tracking GitHub commits and pull requests, Jira issues, Google Calendar activity, and tool usage for Copilot, Cursor, and Claude Code, paired with 21 qualitative interviews. Using a staggered difference-in-differences design based on when each firm adopted AI tools, the authors follow code from local commits to pull requests, review queues, merges, and deployed Jira issues.

When Ars Technica and twenty other outlets covered the paper in October, they read the 4 August 2026 version, which tracked 718 firms through March 2026. When I opened the PDF on Fiona Chen’s site this week, it had been updated on 1 November 2026. The current version tracks 655 firms, 720,542 workers, and 445 million work events from January 2021 to August 2026.

Two widely repeated claims from October need a correction if you open the PDF today. First, lines of code added rose 29.8% in the August draft, and 44.0% in the November revision, on top of a 38.6% gain from earlier AI assistants, though the new lines-of-code estimate is statistically noisy. Commits (+36.0%) and pull requests opened (+35.7%) are the firmer, statistically significant numbers. Second, finished software did not stay strictly at zero: Jira issues resolved rose 13.7% and epics rose 18.0%, though both estimates are marginally insignificant. As Chen and Stratton write in the current abstract:

“Adoption substantially increases code output but has much smaller effects on final software output and no detectable effect on employment. Code review becomes the bottleneck.”

What about the viral claim that companies “moved 14% more staff into code review”? Even in the August paper, nobody changed job titles. The share of workers who approved or commented on at least one pull request in a month rose by about 4 percentage points on a baseline of 29%. In the November paper, that measure is gone, replaced by a calibrated model estimating that review’s share of engineering labor time rose 43.4% (from 34.3% to roughly 49%), which the authors note they cannot observe directly.

What they do observe directly is the queue. A junior engineer interviewed for the paper put it plainly: “People could make a huge number of commits quickly, but code review was still the bottleneck.” Time from pull request submission to approval rose 56.1% (1.99 extra days on a 3.56-day baseline). Time spent waiting before review started rose 59.9%, and time in active review rose 58.5%.

The extra code also required more cleanup. Comments per pull request rose 38.6%. More telling, only 62.7% of the additional pull requests opened after agent adoption were ever merged, compared with 86.1% of pull requests at baseline. Over a third of the extra submissions never landed.

Why not let AI review the AI’s code? Firms tried: 79.1% of companies in the sample used AI code review tools by July 2026. Yet AI wrote only 23.3% of review comments, and only 10.8% of pull requests received even a single AI comment.

The authors are upfront about their limits. These numbers capture the first 12 to 16 months after adoption inside medium-to-large established firms, where effects may differ from startups. On Hacker News, commenters like dcre asked whether “tickets closed” is even a fair measure of software output. To check whether Jira issues resolved missed larger features across the 73.1 million issues in their sample, Chen and Stratton verified that average issue size did not change, and tracked epics too. They also found no detectable drop in engineering employment, and bug reports per worker did not rise.

Where your review time went: what it says about your judgment

Every article written about this study treats that 56.1% slowdown as a company pipeline problem: set review service-level targets, cap pull request sizes, or buy an AI reviewer. None of them ask the question developers were arguing about on Hacker News. As commenter atleastoptimal wrote:

“My brain is not 10x faster, so either I spend 10x more time reviewing code, or I just opt to accept that AI is probably right based on the complexity of the problem.”

I am not a developer. On this site, I do not do diff checks or look at actual code at all. When my coding agent makes a change, I read the English copy that needs fixing and I test the site as a user. That is my entire review, and so far I have not run into issues doing it that way.

If you are an engineer approving production software for a team, your calculation is harder. The Harvard paper counts minutes, comments, and merges, but it cannot see whether your review time went to the right code. When an agent hands you three times as many diffs, two sensible engineering principles pull you in opposite directions.

One says speed up and stop nitpicking. Google’s Engineering Practices guide states:

“In general, reviewers should favor approving a CL once it is in a state where it definitely improves the overall code health of the system being worked on, even if the CL isn’t perfect.”

The other says slow down and demand proof before you read. As Simon Willison wrote on 18 December 2025, “Your job is to deliver code you have proven to work,” calling giant untested pull requests a dereliction of duty.

Human attention has a hard ceiling. As SmartBear summarizes from its study of a Cisco Systems engineering team (and keep in mind SmartBear sells review tools), developers should review “no more than 200 to 400 lines of code (LOC) at a time” before the ability to find defects diminishes. That limit explains the old joke Hacker News commenter brabel repeated: “a PR with 10 lines changes got 10 comments (all nitpicking), a PR with 1000 lines got just one, LGTM.”

In a September 2026 video watched nearly 390,000 times, Meta Senior Staff Engineer John Kim offers a practical way to split the difference: treat your codebase like a tree. “Trunk” code touches shared state, core routing, or infrastructure where a bug has a wide blast radius. “Leaf” code sits at the edges, isolated in a standalone component or behind a feature gate. Kim skims leaf code when the pull request includes proof that it works as a user, saving his line-by-line reading for the trunk. (In Watching 03, I looked at how Anthropic’s team built review around attention.)

The trouble is that human scrutiny rarely follows risk automatically. Chen and Stratton found that 82.8% of code reviews go to files the reviewer already knows, versus 17.2% if assigned at random, and junior engineers perform only 24.3% of the reviews on senior engineers’ code. We inspect what we understand (for me, the English and the user interface; for a developer, a familiar module) and wave through the rest. And when only 62.7% of extra agent pull requests ever merge, judgment starts even earlier: what you choose to send a colleague is a choice too.

Ultimately, an AI comment cannot sign its name. As Hacker News commenter zmmmmm wrote, the main protection is “a human being willing to put their reputation on the line by saying ‘I understand this change and I approve it’.”

The fair point for the other side

You can read the Harvard numbers and conclude that the slowdown is doing its job.

First, as commenters like jefftk noted on Hacker News, the data covers the first year of agent adoption, mostly on 2025 models. While the 1 November revision extends the window to August 2026 and still finds the bottleneck, teams are still adjusting.

Second, the bottleneck in established firms is often organizational rules rather than individual reading speed. In the paper’s interviews, a junior engineer describes a project where only one senior engineer was allowed to approve changes, and could review their code just once a week. After AI-generated commits caused outages, new rules required senior approval for AI code, which made the queue longer still. Startups without that rule ship faster.

Third, bug reports per worker did not rise after agent adoption. That extra 56.1% in approval time may be earning its keep by filtering out the 37% of extra pull requests that should not ship. Vendors are already racing to compress that queue, as OpenAI pitched in its 12 October product video, “Code review is no longer the bottleneck”. And while the paper includes a model projecting how output and employment might shift in the long run if review speeds up, that is a theoretical calibration, not an observation.

Try it on your last ten reviews

You do not need an analytics platform to see where your own review time went. Take the last ten agent changes you approved or merged (yours or a colleague’s) and take ten minutes to note five things for each:

1. Rough size: How many lines or files changed?

2. Minutes spent: How long did you spend checking it?

3. Trunk or leaf: Does it touch shared code that many things depend on (trunk), or something isolated (leaf)?

4. Asked for a change: Did you push back before approving?

5. The accountability test: Could you say, “I understand this change”?

When my agent checked the last ten code changes on this site, about seven touched shared code, like the sign-up emails and the download page, and three were small, isolated edits. I reviewed all ten the same way: by reading the English and testing the site as a user.

Once you fill out ten rows, look at one thing: did your longest looks go to the riskiest trunk changes, or to the smallest diffs and the parts you already knew best? It can go either way: you may find you over-reviewed safe leaf changes, and that is a finding too.

The study shows where review time went across 655 companies. It cannot show whether your review time went to the right place. That depends on what you chose to accept, and only your own record of those choices can tell you.

What went into this post

We read both versions of Fiona Chen and James Stratton’s Harvard working paper (4 August 2026 and 1 November 2026), Kyle Orland’s 9 October Ars Technica article (archived copy), and all 314 comments on the 12 October Hacker News thread. Every number and link was checked against the primary sources on 2 November 2026. What we are building with Sense is a record of these exact choices, for the person, not the company.