研究问的是什么
Ars Technica 周五报道，哈佛大学研究者 Fiona Chen 和 James Stratton 看的是公司里的实际开发，不是实验室题。编程智能体让代码变多。用议题衡量的软件交付没有同步变多。他们把差额记在人工审查变长上。
[1]
数据从哪来
两人使用 Jellyfish 的汇总数据。其中有 3 亿条工作事件，例如提交和拉取请求，以及议题管理软件里的记录，覆盖 70 多万名员工、700 多家软件公司，时间从 2021 年到 2026 年 3 月。
他们用直接测到的人工智能使用情况，加上对 GitHub 活动的分析，判断每家公司何时开始使用编程助手或编程智能体。助手主要补全人写的代码。智能体主要根据提示自己写代码并提交。随后他们做了 Ars 所称的 difference of differences 回归，比较不同公司在引入这些工具前后的差异。
[1]代码多了，交付没有同步多
引入编程智能体之后，代码行数平均增加 30%，提交数增加 20%，拉取请求增加 23%。用 Jira 一类工具追踪的 Issue 和 Epic，解决率没有统计学上的显著变化。这些议题的规模和复杂度，也没有出现报道所说的结构性变化。
审查变长。从拉取请求提交到并入代码库，平均审查时长增加 49%。要求修改的拉取请求占比将近翻倍，每条拉取请求的评论数增加 35%。做代码审查的员工占比增加 14%。研究者对照 Jellyfish 的在职人数和这些公司的 LinkedIn 数据后写道，不能把显著的就业变化归因于人工智能。
到 2026 年 3 月，被测公司中有 80% 使用了某种人工智能代码审查。即便如此，人工智能智能体只写下全部审查评论的 23.3%，只涉及全部拉取请求的 10.8%。人仍然承担大部分审查。
[1]不能从这篇报道推出的
Ars 没有给出论文标题或预印本链接，本文也不编一个。测量窗口止于 2026 年 3 月。Ars 同时写道，此后工具还有更新，研究中的公司有 95% 已经用上编程智能体，许多团队仍在学习何时该用。文中没有单独标出这 95% 的统计日期。审查变长和议题解决率，是这项研究在上述样本上的平均结果，不是每一家公司的个别结论。
[1]