If your 2027 plan cuts engineers because agent dashboards show more commits, a new firm-level study says you are counting the wrong thing. Across 720,542 engineers at 655 companies, AI coding agents raised lines of code by 44% and pull requests by 35.7%, but resolved Jira issues rose only 13.7% (a borderline result) and engineering headcount showed no detectable change, according to the November 7, 2026 revision of a Harvard working paper by Fiona Chen and James Stratton. Agents produced more code than reviewers could approve.
The practical reading is narrow and useful. Before you buy more agent seats or trim the team, find out how much review capacity you have, who holds it, and how long code already waits for it.
What the Harvard Jellyfish Study Measured
The study is a causal look at what AI coding tools do to a company's output and headcount, using telemetry instead of surveys. Chen, a Harvard PhD candidate in Business Economics, and Stratton drew on Jellyfish, an engineering analytics platform. The dataset covers 445 million work events from January 2021 to August 2026: GitHub commits and pull requests, Jira issues, Google Calendar events, and firm-level usage of GitHub Copilot, Cursor and Claude Code.
It separates two generations of tools. AI coding assistants (first released in late 2022) suggest localized edits. AI coding agents (from late 2024) complete longer tasks semi-autonomously. To estimate causal effects, the authors use a staggered difference-in-differences design, which compares firms that adopted early with firms that adopted later, on the argument that procurement, security review and piloting delay adoption by amounts unrelated to a firm's growth.
The paper has moved since its first version, so news reports disagree with each other. An August version covered 718 firms through March 2026 and reported a 30% rise in lines of code and a 49% rise in review time; Forkast's write-up and InfoQ's coverage on October 22 quote those earlier figures. The November revision adds five months of agent-era data, and most of its effects are larger. The numbers below come from that latest version.
Agents Raised Code Output by 44% and Finished Work by Far Less
Agents added larger output gains on top of what assistants delivered, and most of that extra code never became finished work. Twelve months after adoption, assistants raised lines of code by 30.4%, commits by 16.8% and pull requests by 20.9%. Agents added a further 44.0% in lines of code, 36.0% in commits and 35.7% in pull requests opened, per the paper.
Completed work tells a different story. The authors measure output as resolved Jira issues (a unit of work deployed to production) and resolved epics (larger features). Assistants moved neither: -1.5% on issues and 3.4% on epics. Agents raised issues 13.7% and epics 18.0%, with the issue effect only borderline significant.
You might suspect teams simply started writing bigger tickets. The authors checked by having an LLM and a supervised model predict how long each issue would take from its text. They found no change in average issue size.
Headcount did not move in a way they could measure either. For agents, the estimated effect on active engineers is -2.6%, with a confidence interval that rules out declines larger than 15.6%. That interval is wide. What it rules out is a large cut so far; a modest one could still be hiding in the noise.
Code Review Is Where the Gains Stop
The constraint is code review. After agent adoption, the average time from a pull request's submission to its approval rose 56.1%. Time spent waiting in the backlog for a reviewer rose 59.9%, and time in active review rose 58.5%. The share of changes receiving at least one review comment rose 13.1%, and comments per change rose 38.6%. Assistants showed no significant effect on any of these, which the authors attribute to assistants' smaller effect on code volume.
Two facts about who reviews explain why the queue cannot simply be spread across the team:
- Reviewers review code they know. 82.8% of reviews go to engineers familiar with the code, against 17.2% if reviewers were assigned at random.
- Senior code goes to seniors. Code written by a senior engineer is reviewed by another senior 75.7% of the time, against 32.8% for code written by juniors.
One engineer the authors interviewed described the result: "On one project, only one senior engineer was allowed to approve changes because he was the expert on the codebase." After outages caused by AI-generated commits, the same team added "new rules requiring senior engineer approval for AI-generated code, which created even more review bottlenecks."
AI review tools have not cleared the queue. 79.1% of firms in the sample adopted them, but the paper finds firms "still largely keep humans in the loop," with most reviews and comments written by people. If you bought CodeRabbit or Greptile expecting it to absorb the agent surge, this data says to measure whether it did.
The authors then fit a model of software production to the estimates. It implies agents raise coding productivity by 73.7% and lower review productivity by 7.0%, and that firms responded by moving labour: coding effort fell 22.7% and review effort rose 43.4%. Much of the coding time agents saved has gone into review.
Why Cutting Engineers on Commit Counts Misreads the Data
Commit counts and lines of code measure input to the bottleneck, so a dashboard built on them will overstate what agents deliver. Engineers in the study spend 30% to 40% of their time writing code, by the paper's estimate, validated with a survey of 100 engineers. Speeding up that slice moves work into review, testing and planning, which agents speed up far less.
That matters most for seniority mix. The people who clear the review queue are the senior engineers who know the codebase. A reduction that falls on senior staff, or a hiring freeze that stops juniors from ever becoming familiar enough to review, cuts the scarce resource. The paper's model makes this explicit: if review productivity stays fixed, output rises 57.8% by 2031 and then levels off once review binds.
The model does predict job losses over time, and you should not read the study as reassurance on that point. At a typical software demand elasticity, it projects a 16.1% increase in output and a 13.2% decline in employment. If review productivity keeps pace with coding, output rises 341.4% by 2031 and employment falls 76.2%. The gap between those scenarios comes down to one input: how fast review productivity improves.
The Strongest Case Against Reading Too Much Into It
The study has real limits, and you should weigh them before you rebuild a budget on it. It is an unreviewed job-market paper. The data partner sells engineering analytics, and Jellyfish reviewed the manuscript only to check it did not disclose proprietary information, per the paper's own note. ComplexDiscovery found small inconsistencies in earlier versions, including interview counts. And firms that let an analytics vendor watch their engineering pipeline are probably more process-heavy than average, so review may bind harder for them than for a startup with light approval rules.
Jira issues are also an imperfect output measure. A team that uses agents to pay down tests or refactor may get real value that never closes a ticket.
Other Studies Point the Same Way
Independent data points the same way, from different methods. Faros AI's 2025 telemetry from over 10,000 developers found high-adoption teams merged 98% more pull requests while review time rose 91% and average PR size rose 154%, with "no significant correlation between AI adoption and improvements at the company level." Google's 2025 DORA report, from nearly 5,000 respondents, found AI adoption now correlates with higher delivery throughput but still has "a negative relationship with software delivery stability."
At the individual level, METR's July 2025 randomized trial found 16 experienced open-source developers took 19% longer with AI tools while believing they were 20% faster. METR has flagged those results as out of date for current tools. The Harvard paper is the firm-level, causal version of what these smaller studies hinted at: more code comes out, and the extra flow stops at the people who approve it.
We have seen the same pattern in individual companies. Zalando auto-approves a third of its PRs and found agents made them bigger, and Meta's 50-to-1 span of control experiment reversed because the manager work AI was expected to absorb, review included, stayed.
What to Do Before You Set 2027 Engineering Budgets
Treat review capacity as the line item that decides whether agent spend pays off. Each step below can start this week with data you already have in GitHub and Jira.
This Week:
- Pull median time from PR open to approval for the last 12 months, split before and after your agent rollout. If it rose like the study's 56.1%, you have the bottleneck the paper describes.
- List who approved 80% of merged PRs last quarter. If the list is five senior names, that is your real throughput ceiling, and any plan that cuts or overloads them caps output.
- Ask your GitHub Copilot or Cursor admin for agent-authored PR share, so you know how much of the queue agents generate.
This Month:
- Replace lines-of-code and commit metrics in exec reporting with resolved issues, cycle time and change failure rate. In the study, those two rose 36% to 44% under agents while resolved issues rose 13.7%.
- Measure your AI review tool's real share of review comments and approvals. If people still write most reviews, the tool is a filter, and you should buy on precision and keep the reviewer independent of the code's author.
- Cap agent PR size and require repo rules in agent context. Agents that follow your constraints fail review less often, which lowers the review cost per change the model estimates.
Before Budget Lock:
- Fund reviewer time explicitly. Give senior engineers a measured review allocation and grow the pool of engineers familiar enough with each codebase to approve changes, which means keeping juniors in the pipeline.
- Tie every new block of agent seats to a review-capacity plan. Price the seats with our cost-per-developer comparison, then add the reviewer hours they will consume.
- Make any headcount reduction conditional on cycle time holding flat for two quarters after agent rollout.
The Bottom Line
The paper's own framing comes from a long line of operations and product development research on what happens when one stage of a production line speeds up: queues grow at the next stage. This study puts a number on where that queue sits in software today. It sits with senior engineers who know the code, approving more changes than before, with AI reviewers mostly assisting. The long-run job effects in the paper depend on whether review productivity catches up with coding. Until you have evidence it has in your own repos, budget as if it has not.
Pull your PR approval times before you approve another block of agent seats.
Continue Reading
- Zalando Auto-Approves a Third of PRs. Agents Made Them Bigger.
- Meta Tried 50 Employees per Manager. Now It Wants Managers Back.
- Agent Teams Hit 65 PRs a Week. Nobody Got Time Back.
- Best AI Code Review Tools for a Monorepo: Buy Precision
- Goldman Says New Hires Manage AI Agents Before Learning the Job
- Your Copilot Bill Can Reach $137 a Month at 10 Daily Tasks