研究显示，编码环节的效率提升会被人工代码审查这一「瓶颈」所「吸收」。

任何哪怕只是与编程有过些许接触的人都知道，如今的 AI 编码助手与代理能够极为高效地生成大量可运行的代码。但真正在用这些工具的程序员也心知肚明：绝不能轻信这些代码的准确性，因此必须投入大量精力去审查 AI 生成的所有产出。

一项针对数百家企业实际编码实践的最新研究发现，人工代码审查构成了 AI 编码工具整体效率的一道显著「瓶颈」，结果是「几乎找不到证据表明企业因此提升了软件产出或减少了用工」。研究者指出，在实际编码阶段所获得的任何效率提升，都会被「生产流程中下游环节的约束所吸收」；具体表现为：代码审查流程显著拉长、合并请求（pull request）更可能需要修改、审查者也会留下更多意见。

Cut once, measure twice

为了得出这些结论，哈佛大学的研究员 Fiona Chen 与 James Stratton 利用了来自 Jellyfish 的汇总分析数据，该平台能够衡量工程团队粒度级别的产出。这些数据涵盖了 2021 年至 2026 年 3 月期间，700 多家相关软件开发公司、超过 70 万名员工所产生的 3 亿条独立「工作事件」（例如提交与拉取请求）以及项目管理软件的相关数据。

为了评估 AI 工具对这些公司的影响，研究人员综合采用了直接测量的 AI 使用情况，以及对 GitHub 活动的分析，以此来判断每家公司是何时开始在工作流程中引入 AI 编程助手（主要帮助自动补全由人类编写的代码）和/或 AI 编码代理（主要根据提示自主编写并提交代码）的。随后，研究人员进行了相当复杂的数学运算，对不同组织在不同时间点引入这些工具前后的关键变量做「双重差分」回归。

从所产生的原始代码量来看，结果清晰而显著。研究人员写道，在一家公司引入 AI 编码代理后，生成的代码总行数平均增加 30%，提交总数上升 20%，拉取请求数量增加 23%。然而，如此大量的额外代码并没有直接转化为公司层面软件产出的提升。相反，在引入 AI 工具之后，由 Jira 等工具追踪的 Issue 与 Epic（即完整的软件功能）的解决率并未出现统计学意义上的显著变化（研究人员还发现，AI 引入前后，这些 Jira 追踪事项的规模或复杂度也没有出现「结构性变化」）。

造成这种落差的原因可以直接在代码评审过程中找到：在引入 AI 编码代理之后，平均而言代码评审耗时明显变长。总体而言，在引入 AI 代理之后，拉取请求从被提交到被合并进代码库之间的平均「评审过程」时间平均膨胀了 49%。研究人员写道，这种影响在更细颗粒度的数据中同样有所反映：随着 AI 代理的引入，「需要修改的拉取请求占比几乎翻倍，每个拉取请求的评论数增加了 35%」。

针对这一变化，研究人员发现，引入 AI 代理之后，从事代码评审的员工占比增加了 14%。他们还写道，在统计 Jellyfish 上活跃员工总数并与这些公司在 LinkedIn 上的数据进行交叉比对之后，「无法将显著的就业变化归因于 AI」。

虽然 AI 理论上也可以用来辅助这一评审过程，但研究人员发现，截至目前这种影响仍然微乎其微。尽管到 2026 年 3 月已有 80% 的被调研公司在使用某种形式的 AI 代码评审，但 AI 代理仅承担了全部评审评论的 23.3% 以及全部拉取请求的 10.8%，这表明人类仍承担着这类工作中绝大部分的工作量。

当然，AI 代理目前仍是编程领域中相对较新的事物，即便自该研究 2026 年 3 月的数据截止以来，它们的输出能力也已经有了显著的更新与升级。虽然在该时间点已有 95% 的被调研公司部署了 AI 编码代理，但无疑其中许多公司仍在经历一个学习过程：究竟何时以及如何最佳地部署它们。随着软件工程团队在针对特定编程问题派出 AI 代理的优劣方面获得更多经验，这类「编码时间 vs. 评审时间」的权衡或许会朝着更优的方向调整。

不过就眼下而言，让 AI 来写你的代码看起来仍是一把双刃剑：编码速度的提升被人类代码评审时间与精力的同等增加所抵消。这样的结果让我们不禁要问：为了让 AI 编码代理运转起来而投入的大量时间与成本，对大多数公司而言是否真的值得。