Fiona Chen、James Stratton · Harvard 工作论文 · 阅读原文
原始来源：Fiona Chen、James Stratton · 作者论文
发现渠道：Ars Technica · Kyle Orland
发现渠道：Hacker News · 原讨论
研究使用 718 家企业、约 3 亿条工程活动记录，数据截至 2026 年 3 月，以错时采用 AI 工具做双重差分。作者估计，Agent 采用后代码行数增加 30%，PR 增加 23%，从提交到合并的时长增加 49%；Jira 事项与项目完成数没有显著增加。它测量企业流程的变化，不是逐个任务随机分配的效率试验。论文版本为 8 月 4 日，本期因新增讨论重访。
可信度 65 · 重要性 83 · 新颖度 66
技术与主题
AI 编程 · 评测与基准 · Coding Agent · Code Review · Difference-in-Differences
radlad
讨论这份研究；个体代码审查体验，未独立复测企业数据。
忠实转述（非原句）：他看到 AI 找出以前漏掉的重要 bug，也看到一长串很少会触发的问题。即使决定记录或忽略，人仍要先理解每一项，所以“找到更多问题”也会带来分流工作。
jefftk
针对同一论文的时效与采用阶段提出异议；其所列模型范围未在本期逐一复核。
忠实转述（非原句）：他提醒读者，论文发表和媒体报道都晚于数据形成，采用初期的流程未必代表团队后来磨合好的做法。本文据原论文保留真实截止日期，没有把这条评论当成研究已被推翻。
KumaBear
同一讨论中的个人项目反例；不用于反驳企业平均估计。
忠实转述（非原句）：他反对把结果扩大到个人软件：一些过去以为没有时间做的项目，现在能够完成。个人新增产出与公司 Jira 完成数测量的是不同对象。
编辑评读
最容易误读的是“审查时间”。论文把它定义为 PR 提交到合并的日历时长，其中既有检查，也有排队和返工。它不能直接换算成审阅者多花了多少小时。若生成速度提高而审阅容量不变，队列就可能变长；若改动更难理解，也可能变长。要区分两种解释，需要人的实际操作时间与缺陷记录，单看合并时间还不够。
双重差分比只问开发者“觉得快了多少”更有约束力，但仍依赖采用前后可比的趋势。采购时点、团队制度和未被检测到的个人使用都可能影响分组。数据来自分析平台客户，结果也不能直接搬给个人项目。没有显著增加不等于效果严格为零，更不意味着十月新模型已被这份研究测过。
Vapi 提供了另一种实际设置：生成之外，把审查也交给能跑复现的 Agent。它的前后变化没有随机对照，却足以让“AI 一定拖慢审查”这句泛化站不住。两份材料更值得共同追问的是：哪类改动适合自动核验，哪类检查只是把更多解释工作转给人。