更多代码，不等于更多软件：瓶颈在人工评审这一步。

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 日前，有独立或同行评审的研究显示公司层面交付产出随智能体采用而上升，或合并时间回到基线，我们会修正。