代码涨了三成，软件一件没多出来

凌晨两点，一支七个人的团队提交了第四个拉取请求。屏幕上的 diff 已经长到要滚三次才能看完，其中两处是同一类改动。第四个人盯着屏幕上一行 python 的缩进，想不明白这三个小时到底干了什么。他不是在怀疑 AI 写错了，他是在怀疑自己为什么要审这四遍。

这不是个别工程师的抱怨。2026 年 10 月 9 日，Ars Technica 报道了一项由哈佛大学 Fiona Chen 与 James Stratton 做的研究，数据来自 Jellyfish 平台上 700 多家软件公司的工程分析流水。结论被概括成一句话：AI 编程智能体让代码多了三成，而已跟踪的软件交付量没有统计显著的提升。

📊 三个涨的数字，三个没涨的数字

先把这张表摆出来。它比任何论述都更能说明问题出在哪一环。

生产端三项全涨，交付端三项全平。研究团队还检查了一个很关键的替代解释：这些 Issue 会不会只是变小了，变简单了，所以解决率才没涨。答案是规模与复杂度在引入前后没有出现构成性转变，这个解释被排除。

数据的体量需要交代清楚，否则这些百分比没有分量。样本覆盖 2021 年到 2026 年 3 月，700 多家公司、超过 70 万名员工，3 亿个独立工作事件（一次提交算一个，一次拉取请求算一个）。研究者用的是差分中的差分回归，把每家公司引入工具的确切时点作为切割点，这样能把「同期本来就在发生的趋势」和「引入工具带来的变化」分开。

研究还区分了两类工具。编码助手主要帮人类补全自己写的代码，智能体则主要按提示自主写码并提交。研究报告的智能体结果，是上面这组数字。

这张图的结构就是研究的全部戏剧性所在：三个箭头进，一个箭头出，出去的箭头是平的。代码确实产出了，只是产出的位置不在最终结果上。

🔍 瓶颈在拉取请求之后

那多出来的三成代码去哪儿了。研究把视线移到了拉取请求的整个生命周期。

需要小心读这四个数字。「合并间隔增加 49%」不等于审查者多工作了 49% 的时间。合并间隔里还包含排队等待、跑持续集成，以及作者自己补测试失败的时间。研究者用它作为「下游压力变大」的指示指标，而不是「审查效率下降 49%」的直接测量。评论数与需修改比例是更硬的证据，它们说明进入审查队列的东西变得更多也更难改。

公司在应对这件事，方式是调人。审查岗位的员工占比涨了 14%，但总雇佣人数没有可归因于 AI 的显著变化。这里也有一层诚实交代：这项研究是观察性的，它无法证明智能体导致了每一项变化，也无法说明每家团队各自的收益分布。数据截至 2026 年 3 月，此后的模型能力升级不在观测范围内。

🤖 机器审了十分之一

一个自然的追问是：既然 AI 制造了这些负担，AI 能不能自己审掉一部分。

到 2026 年 3 月的观测截止点，研究样本中 95% 的公司已经引入了编程智能体，80% 使用了某种形式的 AI 代码审查工具。但机器实际承担的份额是：

• AI 占全部审查评论的 23.3%
• AI 占全部拉取请求的 10.8%

这两个数字放在一起说同一件事。工具的覆盖率已经接近饱和，进入流程的比例却只有十分之一强。绝大多数机器生成的代码，最终仍然由人来读、来改、来合并。

这解释了一个表面矛盾：为什么工具渗透率如此之高，交付量却没动。覆盖率的提升是决策层面的，吞吐量的提升是流程层面的，两者的瓶颈并不在同一个地方。

🧭 这项研究真正的边界

把它读成「AI 编程没用」是过度解读了。研究者自己的措辞是「未检测到统计显著的提升」，这句话的主语是这项观测研究，不是这项技术。研究给出的是一个更窄也更硬的结论：在被观测的样本与时段内，编码环节的效率增益被下游审查吸收了。

要把它当成定论还缺几块：

• 数据截至 2026 年 3 月，此后一代智能体与 AI 审查工具的能力不在样本里
• 观察性设计无法做因果归因，也无法说明收益在团队之间的分布
• 交付端指标取自 Jira 的 Issue 与 Epic 解决率，团队是否有其他维度的产出未被覆盖，研究未涉及
• 合并间隔这个指标混入了排队与 CI 时间，它的方向可信，幅度不可直接解读

研究团队给出的后续观察点是明确的：看审查工作流能否吸收新增的代码量，看新一代工具能否改变这个平衡。这两个悬念都还没有答案。

⚖️ 一个更要紧的参照系

同一周内还有另一组数字在流传：AI 审查工具在受访者中广泛部署，但生产事故仍在发生。两次合并读下来的画面是相似的。工具已经进了流程，质量与吞吐的约束转移到了别处。

把这两件事与本文开头那个凌晨两点审 diff 的工程师放在一起，一个更朴素的判断浮现出来：编码从来就是整条流水里的一段。把这段的成本压到接近零，会让后面每一段的排队时间更显眼。瓶颈不会因为上游变快而消失，它只会换一个更显眼的位置出现。

研究没有证明 AI 编程是失败的。它证明了瓶颈的位置，而这可能比产出的数字更有用。