Your AI Agents Write 30% More Code. Your Team Ships the Same Amount.
An analysis of 718 software firms suggests AI coding agents increase code output without a corresponding rise in completed work, while code reviews take longer.A Harvard study of 718 firms found the bottleneck didn’t disappear. It moved to code reviewPicture the dashboard a few weeks after your…
Annons
Annons
An analysis of 718 software firms suggests AI coding agents increase code output without a corresponding rise in completed work, while code reviews take longer.A Harvard study of 718 firms found the bottleneck didn’t disappear. It moved to code reviewPicture the dashboard a few weeks after your team rolls out coding agents. Lines of code are climbing. Commits are climbing. Pull requests are stacking up faster than they ever did. By every measure of activity, the rollout is working.Then you open the one chart that tracks finished work. It hasn’t moved.That is close to what a Harvard working paper found when it followed 718 software firms through the arrival of AI coding agents. Engineers wrote about 30% more code and opened 23% more pull requests. They did not resolve measurably more issues. And the time it took to get a pull request merged rose 49%.The extra work didn’t vanish. According to the paper, it piled up in the review queue.What the researchers actually measuredThe paper is by Harvard researchers Fiona Chen and James Stratton, and it was widely covered after Ars Technica reported on it in early October. It draws on telemetry from Jellyfish, an engineering analytics platform: roughly 300 million work events from about 700,000 workers, running from January 2021 through March 2026.The authors dated when each firm adopted AI assistants (the autocomplete kind) and then AI agents (tools in the Claude Code, Cursor agent and Devin class), using measured usage and GitHub signals. Then they compared output before and after.One detail matters for how you read everything below. The agent effects are the added effect of agents at firms that already had assistants. This is not a before-and-after of AI from a standing start.Agents also spread fast. The share of firms using one went from near zero in late 2024 to over 95% by early 2026.The numbersHere is what changed after a firm adopted coding agents, per worker per month:Lines of code added: up 30%, about 1,500 more linesCommits: up 20%Pull requests: up 23%Resolved Jira issues: no statistically significant changeTime from pull request to merge: up 49%, roughly 3.5 extra days on a baseline of about 7Pull requests with changes requested: nearly doubledReview comments per pull request: up 35%Share of workers doing review: up 14%Assistants, by comparison, were a smaller story: about 12% more lines of code, 9% more commits and 5% more pull requests, with only the commit change clearly distinguishable from noise. If your rollout plan treats “AI coding tool” as one category, the data says you’re averaging two quite different interventions.Why more code didn’t mean more softwareEvery pull request is a request for someone else’s attention. Agents are very good at producing those requests. They have no idea how much attention is available to answer them.This is the old theory-of-constraints lesson. Speed up a stage that isn’t the constraint, and you don’t get more output. You get a bigger pile in front of the stage that is. Software delivery has always had several steps: write, review, test, merge, release. For a long time, writing was plausibly the slow one. If these numbers hold, agents made writing fast enough that review became the constraint, and the surplus waited in line.Look at how the firms responded. The share of workers commenting on or approving pull requests rose 14%. Teams put more people on review, and merge time still stretched from about seven days to about ten and a half.Why would each review get slower? The paper’s measures offer clues: more comments per pull request, and changes requested on nearly twice the share of them. My reading, and it is only a reading, is that reviewing agent-written code is harder than skimming a colleague’s diff. When the author didn’t type every line, the reviewer can’t lean on the author’s understanding of it. Code that looks plausible still has to be checked for whether it’s right.The AI reviewers aren’t absorbing the load yetThe obvious reply is: let AI review the AI’s code. Firms tried. By March 2026, nearly 80% of the firms in the sample had used AI tools somewhere in code review.But AI generated only 23.3% of review comments, and only 10.8% of pull requests received even one AI-written comment. Having the tool and routing the work through it are different things. For now, the people who read the diffs are still mostly people.The other thing that didn’t move: headcountThere is a second flat line in the paper, and it gets less attention. Firm-level employment did not fall after agents arrived either. The firms weren’t doing the same work with fewer people. They also weren’t doing more work with the same people.That rules out the cleanest version of the optimistic story, where agents absorb the typing and the team shrinks or ships twice as much. It also complicates the pessimistic one. The study doesn’t show agents failing to help anyone. At the level of the individual engineer, it shows exactly what the sales pitch promised: more code, more commits, more pull requests.A rough sense of scale helps. The baseline in the data was about 5,000 lines added per worker per month, and agents added roughly 1,500 on top. On a ten-person team, that is on the order of 15,000 extra lines a month arriving in front of the same reviewers. (That is my arithmetic from the paper’s averages, not a result from the paper. Your numbers will differ.) Nobody planned for that much new reading.The mismatch also explains why the dashboards look so good. Every metric that measures producing code improved. The metric that measures finishing work didn’t. If you only watch the first set, the rollout looks like a clean win right up until someone asks why the roadmap hasn’t moved.What this study can’t tell youBefore anyone builds a strategy on a single paper, some limits.It’s a working paper. Treat it as strong early evidence, not settled fact.Issues are a blunt measure of output. Jira tickets vary wildly in size, and “no statistically significant increase” does not mean “exactly zero.” One summary of the paper notes that gains much above 12% were ruled out, so a modest improvement can’t be excluded.Averages hide the spread. Across 718 firms, some almost certainly have review practices that cope well with agent volume. The study can’t tell you whether yours is one of them.The data stops in March 2026. Tools and habits have moved since, and the authors’ own sample was still adjusting to near-universal agent adoption.None of this undoes the central pattern: more code written, no matching rise in finished work, slower review. It does mean you should check your own numbers rather than borrow these.What I’d change on MondayThese are my suggestions, not findings from the paper.Retire lines of code as a success metric. It went up 30% and told you nothing about delivery. Watch resolved issues and the time from pull request opened to merged.Treat review capacity as a budget. If agents let each engineer open more pull requests than reviewers can read, the surplus just waits. Cap the number of agent-authored pull requests in flight per team.Push checking earlier. Tests, type checks, linters and CI should reject obviously broken agent output before a human spends attention on it.Make pull requests cheaper to read. Smaller diffs, and descriptions that say what the change is meant to do and how it was verified.Measure the queue by cohort. Track review wait, revision rate and comments per pull request, with agent-assisted work separated from assistant-assisted work. The paper found the two behave differently, and your averages will blur them.The question I’d ask your teamThe tempting story about coding agents is that writing code was the hard part, and now it’s solved. This data suggests writing code was never the whole job. Deciding whether the code is right, and whether it should merge, takes human attention, and that hasn’t gotten cheaper.So where does your team’s queue sit right now: before review, in review, or after merge? If you’ve measured it, I’d like to hear what you found in the comments.SourcesHarvard researchers find AI coding agents shifted the bottleneck to code review (ComplexDiscovery)Coding Agents Add 30% More Code, Not More Finished Work (FourWeekMBA)Harvard Study: AI Coding Agents Lift Code 30%, Shipped Output Flat (AI Weekly)Harvard’s field data on coding agents (DEV Community)This story is published under the Generative AI publication. Connect with us on LinkedIn and follow Zeniteq to stay in the loop with the latest AI stories. Let’s shape the future of AI together!Your AI Agents Write 30% More Code. Your Team Ships the Same Amount. was originally published in Generative AI on Medium, where people are continuing the conversation by highlighting and responding to this story.