More code, not more software: review is the binding step.更多代码,不等于更多软件:瓶颈在人工评审这一步。

AI coding agents now add roughly 30% more code at the firms that adopted them — yet no measurable increase in shipped software, because the human reading the code, not the writing of it, is what caps delivery.
A Harvard working paper by Fiona Chen and James Stratton (August 2026) tracked about 300 million work events at 718 software firms and some 726,000 workers from 2021 to March 2026, using Jellyfish engineering data. After teams adopted coding agents in the Claude Code, Cursor and Devin class, each engineer added about 1,494 extra lines a month on a 5,017 baseline, with 20% more commits and 23% more pull requests.
Finished work did not follow. Jira issues and epics resolved barely moved: plus 0.12 on a 3.67 baseline, statistically indistinguishable from zero.
Here is where the time went. Pull-request open-to-merge rose 49%, about 3.45 days on top of a 7.03-day baseline. Formal change requests nearly doubled, up 12 points from 13% of PRs. Comments per pull request rose 35%. Firms even pulled 14% more people into reviewing.
The mechanism is simple once you see it. Generating code got cheap, so agents emit more of it. Reviewing code did not get cheap: one person can carefully judge far fewer pull requests than an agent can open. After AI-written commits caused outages, some firms added senior-approval rules — more review, not less. Review bots did not absorb the load either; only 10.8% of pull requests got even one AI comment.
The second-order effect: when new code is nearly free, the incentive is to open more and bigger PRs, while reviewer attention stays fixed. The faster tool can make shipping slower. The agents made writing code cheap; shipping software still costs a human reading it.
The strongest counter: this is a job-market paper, not peer-reviewed, and firm-level correlation is not a clean experiment. Task-level speedups are real — LinearB's data on 8.1 million PRs shows AI-assisted pull requests clearing review faster once started, 3.2 hours against 4.2. That wins where review capacity is elastic. Our claim is narrower: firm-level output over quarters, where the human gate is fixed — and LinearB's own 30-day merge rate, 32.7% against 84.4%, points the same way.
If you lean on coding agents, stop grading them by lines or PR count. Track cost and time per resolved issue that actually ships, and cap PR size so review doesn't quietly become your bottleneck.
This breaks if an independent or peer-reviewed study shows firm-level shipped output rising with agent adoption, or merge times returning to baseline, by June 30, 2027.
AI 编码智能体让采用它们的公司人均代码量增加约 30%,却没有带来可衡量的更多已交付软件——因为真正限制交付的是读代码的人,而不是写代码。
哈佛的 Fiona Chen 与 James Stratton 的一篇工作论文(2026 年 8 月,求职市场论文,尚未经同行评审)用 Jellyfish 的工程数据,分析了 718 家软件公司、约 72.6 万名员工、约 3 亿条工作事件(2021 年 1 月至 2026 年 3 月)。在团队采用 Claude Code、Cursor、Devin 这一类编码智能体后,人均每月多约 1,494 行代码(基线 5,017 行),提交多 20%,拉取请求(PR)多 23%。
可真正交付的工作没有跟上。已解决的 Jira 问题与史诗任务几乎没动:在 3.67 的基线上只增加 0.12,与零在统计上无法区分。
时间去了哪里?PR 从提交到合并的耗时上升了 49%,在 7.03 天的基线上多了约 3.45 天;正式返工请求几乎翻倍,从占 13% 的 PR 上升了 12 个百分点;每个 PR 的评论增加 35%;公司甚至多抽调了 14% 的人去做评审。
机制一旦看清就很简单:生成代码变便宜了,智能体就产出更多;评审没有变便宜——一个人能认真判断的 PR,远少于智能体能开的数量。在 AI 写的提交引发线上故障后,有些公司加了资深工程师审批规则,评审反而更多。评审机器人也没接住:只有 10.8% 的 PR 收到过哪怕一条 AI 评论。
二阶效应:当新代码几乎免费,人就倾向开更多、更大的 PR,而评审的注意力是固定的;更快的生成工具反而可能让交付更慢。智能体让写代码变便宜了,但交付软件仍然要有人把它读完。
最强反方:这是一篇工作论文而非同行评审,公司层面的相关性也不是干净的实验。任务层面的提速是真的——LinearB 对 810 万个 PR 的数据显示,AI 辅助的 PR 一旦开始评审反而更快,3.2 小时对 4.2 小时。在评审产能有弹性的地方,这一面成立。我们的判断更窄:季度尺度、评审产能大致固定的公司层面产出——而 LinearB 自己的 30 天合并率(32.7% 对 84.4%)与论文方向一致。
含义:如果你依赖编码智能体,别再用代码行数或 PR 数给它打分。盯住“每个真正上线的已解决问题”的成本与时间,并限制 PR 大小,别让评审悄悄变成你的瓶颈。(这是衡量方法,不是效率承诺。)
证伪:若 2027 年 6 月 30 日前,有独立或同行评审的研究显示公司层面交付产出随智能体采用而上升,或合并时间回到基线,我们会修正。
Sources来源
- Primary source: fion.ac原始来源:fion.acfion.ac ↗


