BuildIndependently confirmed2 publishers3 min readPublished
PR review time rose 49% as coding agents added 23% more PRs across 718 firms
A Harvard study of 718 firms found coding agents raised lines of code 30% and pull requests 23% with no detectable rise in resolved Jira work. The review-queue explanation is a dev.to author's inference from the paper's review data.
The Engineer · Build desk
Four figures. Jira issue and epic resolution showed no change the authors could distinguish from zero, and their estimate rules out an output gain above 12%. After teams adopted coding agents, lines of code rose 30%, commits rose 20% and comments per PR rose 35%.
| Figure | Value | Note | Claim |
|---|---|---|---|
| Jira resolution: output gain ruled out above | 12% | no change distinguishable from zero | 6 |
| Lines of code, rise | 30% | 3 | |
| Commits, rise | 20% | 5 | |
| Comments per PR, rise | 35% | 7 |
What happened
- Authors Fiona Chen and James Stratton built the study on Jellyfish data covering about 300 million work events from January 2021 to March 2026.
- Commits rose 20% after teams adopted agents.
- On Jira issue and epic resolution, the authors' estimate rules out an output gain above 12%.
- The paper's review measures all moved up: PR review time 49%, comments per PR 35%, the share of workers reviewing 14%, and the share of PRs with changes requested nearly doubled.
- Total headcount showed a precise zero effect that rules out a decline above 2.9%, and engineering headcount a noisier zero that rules out one above 13.8%.
Why it matters
- decision Before changing licence counts or reviewer rosters, a team can test the review-load reading against its own merged PRs with the post's script.
- cost Total headcount is pinned to within 2.9%, but the engineering-only estimate still admits a cut of up to 13.8%, so it does not show the engineering line held. The author's claim that the spend bought a review backlog is untested by the paper.
- contradiction The post says nobody raised the rate at which review clears work, yet the paper it draws on has the share of workers doing review up 14%. Whether that was enough is the untested part.
- constraint The paper's outcome is Jira issue and epic resolution, so a team that tracks finished work elsewhere cannot reproduce the headline comparison and is left with the review-side measures.
The post's table turns the paper's separate review effects into one team's month. The invented team has 20 people, 6 reviewers, 200 merged PRs, a 10-hour median review, 4 comments per PR and 15% of PRs sent back [10]. Apply the effects and it has 246 PRs, a 14.9-hour review, 6.84 reviewers and a 30% changes-requested rate [11]. Review hours scale as 1.23 x 1.49, which is 83% more PR-hours for 23% more PRs [17]. Comment load per reviewer rises 46% even after the 14% increase in reviewers [18]. Second passes go from 30 a month to 74 [19].
The table is tidy in the way invented teams are. It also has seams. The author concedes that stacking the effects is an illustration and that the paper reports no such result [12]. The table doubles the changes-requested rate to 30%, and the paper says the share nearly doubled [7], so 74 second passes runs slightly high. The table also turns a 14% rise in the share of workers who review into 14% more reviewers. That holds only if headcount stayed flat, and the paper's total headcount effect is a precise zero [8].
The author states the conclusion in two sentences: "Agents raised the rate at which work arrives at review. Nobody raised the rate at which review clears it." [21] We think the first sentence is documented and the second is inferred. The paper has PR volume [4] and four review measures [7] moving up together while Jira resolution stays flat [6]. The same figures also fit extra output that never maps to a ticket.
The post's check is a script over the GitHub API. Its monthly output is three figures: reviewer share, changes-requested rate and time to first review [13]. That clock runs from the moment a PR was last marked ready for review, or from when it was opened if it never went into draft, to the first review anyone submits [14]. The script fetches a timeline for every merged PR, one paginated call each, so run time grows with PR count [15].
The post does not say how the paper defines PR review time. A flat time to first review in your repo would therefore not refute the paper. The changes-requested rate and reviewer share map more directly, because the paper reports both [7].
Jellyfish sells engineering analytics [2]. The author says a finding that work stalls somewhere measurable is not against the company's commercial interest, and asks readers to weigh the source with that in mind [9]. For the 83% to land on your team, review time would have to scale with PR count the way the table multiplies it [17].
What to watch
- Whether the authors, or anyone else, test review load as the cause of flat Jira resolution, since the paper estimates each effect separately.
- Results from teams that run the script: a time to first review or changes-requested rate that does not move after agent adoption would count against the bottleneck reading.
- Whether the 13.8% bound on engineering headcount tightens as more months after adoption are added to a dataset that now ends in March 2026.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence62
- Adoption
- Insufficient
- Hype gap+10
- Incentives35
- Confidence60
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
A Harvard study of 718 firms, by Fiona Chen and James Stratton, was built on Jellyfish data covering about 300 million work events from January 2021 to March 2026.
ReportedSupportedSource: dev.to post describing the Chen and Stratton paper2 sources— create a free account to open themView cited source - [2]
Jellyfish sells engineering analytics.
- [3]
After teams adopted coding agents, lines of code rose 30%.
- [4]
After teams adopted coding agents, pull requests rose 23%.
- [5]
After teams adopted coding agents, commits rose 20%.
- [6]
Jira issue and epic resolution showed no change the authors could distinguish from zero, and their estimate rules out an output gain above 12%.
- [7]
In the same paper, PR review time rose 49%, the share of PRs with changes requested nearly doubled, comments per PR rose 35%, and the share of workers doing review rose 14%.
- [8]
Total headcount showed a precise zero effect, ruling out a decline above 2.9%; engineering headcount showed a noisier zero, ruling out a decline above 13.8%.
- [9]
The author says a finding that work stalls somewhere measurable is not against Jellyfish's commercial interest, so the source should be weighed with that in mind.
ReportedSupportedSource: dev.to post author2 sources— create a free account to open themView cited source - [10]
The author's illustrative team has 20 people, 6 regular reviewers, 200 merged PRs a month, a 10-hour median review time, 4 comments per PR, and 15% of PRs sent back with changes requested.
- [11]
Applying the paper's effects, the author's table gives 246 PRs a month, 14.9 hours of review time, 6.84 reviewers and a 30% changes-requested rate.
- [12]
The paper estimates each effect separately, so stacking them is the author's illustration, not a result from the paper.
- [13]
The author's script pulls merged PRs, their reviews and their timelines through the GitHub API and prints three numbers per month: time to first review, changes-requested rate, and reviewer share.
- [14]
In the script, time to first review starts at the last ready-for-review event (or PR creation, if the PR never sat in draft) and stops at the first submitted review.
- [15]
The script code calls the issue timeline endpoint through gh api --paginate once for each PR.
- [16]
The engineering headcount estimate still admits a decline of up to 13.8%, and the total headcount estimate a decline of up to 2.9%.
- [17]
Stacking the PR count and review time effects gives 1.23 x 1.49 = 1.83, or 83% more PR-hours in review for 23% more PRs.
- [18]
Comments per reviewer rise about 46% after accounting for 14% more reviewers.
- [19]
In the illustrative team, PRs needing a second pass go from 30 a month to about 74.
- [20]
The paper reports the review effects separately and does not claim one caused the other; that review absorbed the extra output is the post author's inference, not the paper's stated finding.
ReportedContestedSource: dev.to post author2 sources— create a free account to open themView cited source - [21]
Agents raised the rate at which work arrives at review. Nobody raised the rate at which review clears it.
ReportedContestedSource: dev.to post author2 sources— create a free account to open themView cited source - [22]
The author argues, and says the paper does not test directly, that what agent licence spending bought was a review backlog.
ReportedContestedSource: dev.to post author2 sources— create a free account to open themView cited source
Sources
2 independent publishers whose own reporting we read for this story.
- arstechnica.comAI coding agents generate more code, but not more software
1 article · October 9, 2026
- dev.to30% More Code, Zero More Shipped Work: Where the Capacity Actually Went
1 article · October 12, 2026
Topics and entities
Follow any of these and your For You feed starts watching them — no settings page required.