More Code, Not More Software

Charts of how much code AI agents write are everywhere. Charts of how much of that code ships are much harder to find.

A new paper from two Harvard economists tries to measure exactly that gap, and the answer is uncomfortable: when firms adopt AI coding agents, code output goes up about 30%, and finished software doesn't measurably go up at all. The extra code piles up in front of the next step in the pipeline, which is review.

I want to walk through what the paper measured, because the headline is easy to over-read, and then say what I think it means for someone like me: a solo developer building iOS, Android and Mac apps with Claude Code, where the "review team" is one person.

The paper

It's called "Artificial Intelligence in the Firm: Bottlenecks in Software Production", by Fiona Chen and James Stratton of Harvard University. Two things to know before quoting it:

• It's a working paper, not peer reviewed. It's labelled a job market paper. The current version is dated August 4, 2026 (first version January 7, 2026). Ars Technica covered it on October 9.
• The data comes from Jellyfish, an engineering analytics company, under a research agreement. The authors say Jellyfish reviewed the manuscript only to check it didn't disclose proprietary information, not for its scientific content.

The dataset is big: roughly 300 million work events from GitHub, Jira and Google Calendar, across 718 firms and around 700,000 workers, from January 2021 to March 2026. The method is a staggered difference-in-differences design: compare firms before and after they adopted AI tools, using the fact that different firms adopted at different times. The bet is that procurement delays (security review, legal, pilots) make adoption timing close to random with respect to how a firm was already growing.

They look at two kinds of tool separately: AI assistants (autocomplete and chat while a human writes the code) and AI agents (tools that write and submit code fairly autonomously from a prompt).

What they found

Code output goes up, especially with agents.

After adoption of…	Lines of code	Commits	Pull requests
AI assistants	+12%	+9%	+5%
AI agents	+30%	+20%	+23%

Only the commits effect is statistically significant for assistants. For agents, all three are.

Finished work doesn't measurably move. The authors measure output as resolved Jira issues (which, in their data, means the work was deployed) and resolved epics (whole features or projects). Both effects are small, positive and not statistically significant, for assistants and agents. For agents, they can rule out an output increase larger than 12% of the baseline. They also checked whether issues got bigger or harder after adoption, which would hide real gains in a flat count, and found no sign of that.

Employment doesn't measurably move either. For agents they estimate a precise zero effect on overall employment, ruling out a decline of more than 2.9%.

Where the extra code goes

This is the part I found most useful. Writing code is only one step: someone scopes the work upstream, and someone reviews and tests it downstream. The authors estimate engineers spend only 30–42% of their time actually writing code (42% imputed from the Jellyfish data, 30% from a survey of 100 engineers). Speed up that slice and the other slices become the constraint.

After agent adoption:

• The time from opening a pull request to merging it rises 49%, from a baseline of about 7 days.
• The share of pull requests where a reviewer formally requests changes nearly doubles, from 13% to about 25%.
• Review comments per pull request rise 35%.
• The share of workers doing code review rises 14%. Firms move people toward review.

Pull requests didn't get bigger, so this isn't just "more lines, more comments". The authors' model separates two effects: agents make people produce more draft code (a productivity effect), and that code needs more correction per unit (a quality effect). Both land on review.

And no, AI review hasn't absorbed it yet. By March 2026 nearly 80% of the firms had used some AI code review tool, but AI wrote only 23.3% of review comments, and only 10.8% of pull requests got any AI comment at all. Humans are still doing the reviewing.

What it doesn't show

I don't want to turn a careful paper into a slogan, so here are the limits as I understand them:

• Not peer reviewed, and one data source. Firms that pay for engineering analytics may not look like your team.
• "No significant change" isn't "zero". The agent estimate allows up to a 12% output gain.
• The data stops in March 2026. Agents and review tools have changed a lot since then.
• It's firm-level adoption, not individual use. A firm counts as "using agents" even if half its engineers ignore them, which the authors note probably makes their estimates conservative.
• Jira issues are a proxy for value, and an imperfect one.

What it does show, clearly, is the shape: the gain shows up where it's easiest to measure, and the cost shows up one step later.

The solo developer version

Here's why this landed for me. In a firm, review is a team activity. A 49% longer review queue means a shared queue, more reviewers, more meetings about it.

When you build apps alone, you are the author and the only reviewer. There's no queue to reallocate people to. Every extra line an agent writes is a line I have to read, or decide not to read. The paper's bottleneck doesn't go away when you're solo; it just becomes my time.

The lesson I take from the paper is to stop measuring the wrong end. Lines of code, commits and pull requests are what's easy to count, and the paper's own advice to managers is that those intermediate metrics can mislead. For a one-person shop the question is simpler: how much of what the agent wrote could I confidently ship this week?

What I'm changing because of it

The paper suggests two levers: more review capacity, or better first drafts. Solo, I can't add reviewers, so both of mine are about making review cheaper.

1. Make the spec the thing I review first. This is the reason I've been moving to spec-driven development, which I wrote about in Part 1 of the Spec-Driven series. Reviewing a half-page spec and a short task list before any code exists is the cheapest review I'll ever do. Then reviewing the diff becomes "does this match what we agreed?", not "what is this and why?"

2. Make machines do the first pass. In the paper's terms, the "changes requested" rate doubled. A lot of what a human reviewer requests is mechanical: formatting, a failing test, a warning. In the setup I'm adopting, those are hooks: format after every edit, and a Stop hook that won't let the agent finish while tests fail. A strict build (warnings as errors) catches more. By the time I read the diff, the machine-catchable problems are gone and I'm only reviewing judgement.

3. Keep diffs small. One task from tasks.md per run. A 40-line diff I actually read beats a 900-line diff I skim. The paper found pull requests didn't get bigger at firms, but solo, nothing stops me letting an agent run for an hour. Small tasks are how I stop myself.

4. Use a second agent as a reviewer, not as the reviewer. A subagent that checks the diff against the spec catches "built something out of scope" well. It doesn't replace me reading the code, and the paper's numbers on AI review suggest nobody else has found a way to make it do that yet either.

None of this makes the bottleneck disappear. It moves review earlier, to the spec, where it's cheap, and it automates the parts that never needed my judgement. That's my reading of the paper's lesson for a team of one: if review is the constraint, put your effort into the constraint, not into making the step before it even faster.

Sources

• Fiona Chen and James Stratton, Artificial Intelligence in the Firm: Bottlenecks in Software Production (working paper PDF, version of August 4, 2026)
• Ars Technica, coverage of the Chen and Stratton study (Oct 9, 2026)