AI 写代码多 30%，交付零增长：卡在 review

你的 coding agent 这个月多写了 30% 的代码。恭喜——你们团队多交付了零。

这是上周开始流传的一篇哈佛 working paper 的标题级结论。经济学家 Fiona Chen 和 James Stratton 把 Jellyfish 的工程遥测数据和 GitHub 行为数据拼在一起，覆盖 718 家软件公司、70 多万工程师、约 3 亿个工作事件（2021 年 1 月到 2026 年 3 月），问了一个所有技术负责人都在心里问的问题：agent 到底给我们买来了更多软件吗？

答案不太舒服。公司引入 Claude Code、Cursor、Devin 这类工具之后，人均代码量涨约 30%，commit 涨 20%，pull request 涨 23%，全部统计显著（用的是 staggered difference-in-differences，把不同时间引入的公司互相比较）。而作者用来代理"交付软件"的指标——解决掉的 Jira issue 和完成的 epic——纹丝不动。不是"涨得少"，是统计上完全没有显著变化，超过 12% 的增长都可以排除。用工人数也没降：没人被替代，也没人多交付。

30% 去哪了

去下游了。PR 从提交到合并的平均耗时涨了 49%，被打回修改的 PR 比例几乎翻倍，每个 PR 的评论数涨 35%，被拉去做 review 的工程师多了 14%。瓶颈从"写代码"转移到了"看代码"。

最让工具厂商难堪的一个细节：到 2026 年 3 月，样本里 80% 的公司已经在用 AI code review 工具。没用，堵还在。只有 23% 的 review 评论是 AI 生成的，最终合并拍板权还在人类手里。review 队列前再堆一个 agent 解决不了问题，因为最后点头的还是人。

论文访谈的 21 个人里，一位资深工程师说得很直白：agent "两秒钟就能写出 90% 正确的草稿"（常规活）——但难一点的任务它频繁犯错，"最后你花在 review 上的时间反而更多了"。这个不对称就是全部故事：便宜的代码更便宜了，贵的环节——验证难代码——更贵了。

为什么 agent 尤其搞崩 review

这不只是"代码多了 review 自然多"。agent 的产出有三点让 review 特别难受。

第一，有自信的量。一个 agent 几秒钟交出一份又大又整洁的 diff。人类作者花三天写的 diff 自带上下文——commit message 里的推理、走廊里聊过的难点。agent 的 diff 什么都不带，reviewer 每次都从零开始。

第二，错误画像不同。人犯困会写出明显的 bug，agent 写出的是"看起来对"的 bug——代码体面，但对需求的理解在往下两层的地方错了。"看似正确实则错误"是最贵的缺陷类别，没法扫读，必须把意图重建一遍。

第三，任务梯度。agent 最擅长的是常规活（那本来 review 就便宜），最弱的是硬骨头（那本来就是瓶颈）。引入 agent 并没有把 review 负载摊平，而是把更多"最难 review 的代码"推进了队列。

论文里 autocomplete 的对照组把这一点说得更透：纯补全类助手只让代码行数涨 12%，且只有 commit 显著。30% 这个数字专属于 agentic 工具——那些不太需要人类指挥、自己写完自己提交的工具。工具越自主，review 负债越重，自主性和 review 负载是同向 scaling 的。

诚实注脚

转发给团队之前，先看 fine print。这是 working paper（《Artificial Intelligence in the Firm: Bottlenecks in Software Production》，当前版本 2026 年 8 月），没过同行评审。数据来自 Jellyfish 的客户——愿意花钱买工程效能分析的公司，天然偏向更大、流程更重的组织，和中位数 startup 不是一回事。"解决掉的 Jira issue"也是个粗糙的价值代理：很多真实工程工作从不成 ticket，很多 ticket 也不是真实价值。

但这些推翻不了核心结论，甚至让它更有意思：样本恰恰是 review 流程最成熟的那批公司，连它们都消化不了这 30%。至于完全没有 review 纪律的团队——它们不是多交付了 30%，只是多合并了 30% 没人看过的代码，那是另一篇文章。

"投资下游 review 产能"到底指什么

作者的处方只有一句话，也是全文最有用的一句："Realizing the benefits of AI adoption requires complementary investments in downstream review capacity, rather than simply increasing code output."（要把 AI 的收益兑现，得给下游的 review 环节配套投资，而不是只管增加代码产出。）用他们的话说：code review becomes the bottleneck。

"投资 review 产能"听着抽象，落地是四件事：

• 更小的 PR。 杠杆最高的一招。200 行的 diff 会被 review，agent 一次吐的 2000 行 diff 只会被扫一眼点 approve。先给 agent 的产出规模设上限，再让它见人。
• 针对 agent 错误画像的 checklist。 通用 review 清单是为人类的错误写的。agent 的产出需要查"看似正确实则错误"这一类：需求理解错位、看起来没动但行为变了的代码、把 bug 当正确行为断言的测试。
• 系统化的 debug 循环。 review 揪出问题之后，修的环节是失血点。对着 agent 写的代码 ad-hoc debug——原作者根本讲不清当时怎么想的——慢得离谱。可重复的复现-隔离-修复-验证循环，在作者是机器时更重要，而不是更不重要。
• 给 review 排 SLA。 既然 review 是瓶颈，就按瓶颈对待：度量排队时间，专门排人力，而不是谁有空谁看，更别假装它是免费的。

没有一条是新建议，这正是重点。论文没有揭示一个新问题，它只是给一门旧功课标了价——那门功课叫 review 纪律，很多团队在写代码变便宜的那一刻就停了供。

和我们有关的部分

code-review-and-quality 就是为这个世界做的：在人类看到 diff 之前，先让 agent 跑一遍结构化 review 清单和质量门。目标不是替代 reviewer——论文写得很清楚，人类拍板才是硬约束，假装能替代就是那 49% 的来源。目标是让每次 review 更便宜：机械问题自动拦掉，人只花时间在只有人能做的判断上。

而 review 真揪出东西之后，systematic-debugging 是配套的那一块——复现-隔离-修复-验证的固定循环，专为"原作者讲不清自己在想什么"的代码库而生。agent 写的代码，原作者永远讲不清。

诚实注脚：没有任何 skill 能消灭这个瓶颈。一个好的流程能买到的是每个 PR 更少的 review 轮次——而数据说，爆的恰恰就是轮次。赢下 agent 时代的团队，不会是生成代码最多的那批，而是 review 流程消化得掉的那批。

30% 从来不是奖品。奖品一直是能活着走出 review 的东西。

（数字出自 Chen 和 Stratton 的 working paper，转引自本周报道；Ars Technica 10 月 9 日报道了这篇论文。）