提交量涨240%，发布只涨30%：多出的代码卡在哪

自主编程智能体加入之后，提交量的累计效应是240%，发布量只涨了30%。两个数字都来自一份NBER工作论文，样本追踪了超过50万名GitHub开发者。

这两个数字之间的落差，是近期关于编程智能体最有用的一份材料。多出来的代码并没有消失，大部分正卡在提交和发布之间的某个环节上。

论文题为《Writing Code vs. Shipping Code: Productivity Effects Across Generations of AI Coding Tools》，作者是Mert Demirer、Leon Musolff和Liyuan Yang，编号NBER Working Paper 35275。第一版2026年5月出炉，PDF在9月修订。

作者把2020年1月至2026年5月的公开GitHub数据，与微软内部关于GitHub Copilot使用情况的遥测数据合并，用匹配事件研究法，把每个采用工具的开发者，与一年前同一周活跃度相近的开发者做对比。

论文摘要的原话是：240%的累计效应，落到项目数量上降到80%，落到实际发布上降到30%。需要说明的是，+240%换算下来是基线的3.4倍，"三倍"是算术换算，不是论文的用词。

30%这个数字还有一处口径问题。论文的明细表没有给出自主智能体单独的发布数字，因为发布"无法拆分为智能体撰写和人类撰写的部分"。单看交互式智能体，发布量上涨19.8%。

多出来的240%去了哪

论文检验了两种解释。一种是范围：也许每次发布的内容变大了。另一种是试验：开发者在成本低的阶段启动更多工作，其中很多永远走不到终点。作者的结论是，范围"只占很小一部分"，落差的大部分"反映的是试验"。

论文也点名了限制代码向上流动的人类环节：跨文件整合改动、审查和合并拉取请求、管理发布，以及质量控制和发布容量。审查在这份清单上，但只是其中一项。

拉取请求这一层把堆积显示得很清楚。交互式智能体让拉取请求上涨86%，发布只涨约20%，进入审查的改动多于以发布形式离开的改动。自主智能体让拉取请求上涨68.5%，略高于提交量的60.7%，论文没有给出可对比的单独发布数字。

Christian Bird在《Why aren't we shipping faster now?》这场基于访谈和问卷的演讲里追问的，正是写代码和发版之间这道口子为什么这么宽。他在Hacker News的讨论中澄清，他的观点并不是团队没有比以前发得更快。

代码卡住的六个位置

• 被重写或删除的代码行
• 没人合并的分支
• 审查队列
• 测试与质量控制
• 集成与协调
• 永远发不出去的发布和项目

采用交互式智能体后，样本中的开发者新增代码行数是原来的7.0倍，删除行数则是12.2倍。大量生成代码是草稿材料，随后被替换掉。作者在这里很谨慎：被放弃的工作不一定质量低，试三个版本留一个可以是正常做法。代价出现在后面——得有人分得清哪个是留下的版本，哪个是草稿。

样本中的开发者在采用交互式智能体后创建的分支多了79%，论文的说法是"探索后来常被放弃的功能"。陈旧分支创建起来便宜，理清楚却昂贵。一个带着半成品智能体改动的分支，携带着没人审查过的上下文，迟早有人要问它能不能安全合并或删除。

审查是测量最直接的堵点，数字来自NBER论文之外。哈佛的Fiona Chen和James Stratton研究了655家公司的720542名员工，论文题为《Artificial Intelligence in the Firm: Bottlenecks in Software Production》，当前版本日期为2026年11月9日。

他们的数据来自工程分析平台Jellyfish。企业采用AI智能体后，代码提交审查到获批的时间上涨56.1%，在3.56天的均值上多出1.99天。在积压中等待的时间上涨59.9%，处于实际审查中的时间上涨58.5%。

审查者每处理一个改动也更费劲。至少带一条审查评论的代码改动占比上升13.1%，每个改动的评论数上升38.6%。更早一代的AI助手，对上述指标没有显著影响。

工具还没有消掉这条队列。Chen和Stratton报告，79.1%的企业已经采用AI代码审查工具，但绝大多数审查和评论仍由人写。NBER论文引用他们的研究，称其发现企业内部"代码审查是约束条件"。

Bird的访谈给这些数字配上了人脸。一位资深工程师在访谈中说："我们不得不审查的速度，已经远远超过我们审查的能力。"

质量控制同样受限于人的容量。Bird和同事在《(When) Should a Software Factory be Lights-off?》中用真实缺陷评测审查智能体，包含1000个开源审查任务，外加某家公司私有仓库的800个任务。

最好的智能体配置在其前五条评论中抓到了71.9%的已知缺陷，五个月前这个数字是47.7%。在私有仓库上、在需要超出代码差异进行推理的缺陷上，表现出现下滑。作者的结论是，"熄灯"运行只适合"范围狭窄、后果轻微的拉取请求"。

不同人和不同智能体写出的代码，仍然要拼到一起。Bird的演讲引用了30场访谈，来自一篇仍在投稿中的论文。一位参与者的说法很到位："如果过去做一个功能要一年，现在一个月就能做完，某种意义上，一年的协作量得在那一个月里发生。"

另一位管理着几十年历史产品的参与者描述："我管理之下的代码，正在被我从没听说过的人改动，我根本没被拉进那个PR。"打字速度压缩了，协调并不会跟着压缩。

在最末端，论文追踪了项目。首月之后毫无活动的新仓库占比，从2021年的60%升到2026年的69%。更多想法开了头，更大比例早早停住。作者还看了四个软件市场，发现"新应用数量急剧增加，但总使用量没有增加"。Bird的受访者描述了同一种拖拽感："就算你一天能把代码写完，离真正部署上线还是得谈30天。"

这些数字也有边界。NBER的样本是带Copilot遥测的开发者公开GitHub活动，"发布"指GitHub发布计数，不是生产部署。两篇都是工作论文。企业层面的智能体提交效应估计，包括Chen和Stratton的，都小于NBER的开源估计，NBER作者认为差距可能反映组织惯性。两篇论文都没有评估任何具体的审查产品，也没有说单一解法能填上这道口子。