报告实证度量

Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity

RCT 实测:2025 年初的 AI 工具让资深开源开发者慢了 19%,但他们自己觉得快了 20%

Joel Becker, Nate Rush, Elizabeth Barnes, David Rein · METR · arXiv · 2025-07 · 被引 181

一句话METR 的随机对照试验:16 名资深开源开发者在自己维护多年的成熟仓库上完成 246 个真实 issue,随机允许/禁止 AI(主要是 Cursor Pro + Claude 3.5/3.7 Sonnet)。允许 AI 的任务平均耗时反而多 19%(CI +2%~+39%),而开发者事前预测快 24%、事后仍坚信快了 20%,ML 专家预测快 38%。

这是什么

AI 编程工具到底让开发者快了多少,几乎所有已有证据都来自 benchmark(SWE-bench 之类)、厂商报告或开发者自述。METR 做了一件更硬核的事:真正的 randomized controlled trial (RCT)。他们招募 16 名资深开源开发者(通常十年以上经验,在参与仓库上平均 5 年、1500 次 commit),从各自维护的成熟大仓库(平均 23k stars、110 万行代码)里挑出 246 个真实 issue,每个 issue 先让开发者预测'用/不用 AI 各需要多久',再抛硬币随机分配 AI-allowed 或 AI-disallowed 条件,全程录屏,完成后走仓库正常的 PR review 流程。时薪 $150 激励参与。

结果与所有人的预期相反:AI-allowed 条件下任务平均耗时多 19%。开发者事前预测 AI 能省 24% 时间,做完之后回顾仍估计自己被加速了 20%;经济学专家和 ML 专家分别预测省 39% 和 38%。也就是说,不仅预测错了,连'用完之后的亲身体感'都和秒表方向相反。这是 2025 年 AI 圈被引用最多的'泼冷水'实证结果之一(S2 引用 181)。

论文花了大量篇幅(20 个 factor 的逐一分析)排查减速是不是实验设计的 artifact,结论是减速效应在各种子集和估计方法下都稳健,更可能由设定本身驱动:开发者对仓库极度熟悉(AI 很难比本人更快)、仓库大且隐性规范多(AI 缺 tacit context)、AI 生成代码可靠性低(只有 <44% 的生成被接受,大量时间花在 review 和清理上)。

全文核心图:纵轴为 AI-allowed 引起的耗时变化(向上为省时)。经济学专家预测省 39%、ML 专家省 38%、开发者事前预测省 24%、事后仍估计省 20%(绿色),而实测结果是多花 19%(红色,CI 约 +2%~+39%)——所有人的预测连方向都是错的。

机制与做法

实验设计:issue 级随机化 + 事前预测做难度协变量

每个开发者自己列出想做的真实 issue(bug、feature,要求单个不超过 2 小时,长的拆开),对每个 issue 先预测 AI-allowed / AI-disallowed 两种条件下的耗时,然后才随机分配条件。事前预测既用来度量'期望的加速',也作为 issue 难度的协变量进入 log-linear regression——这一点很关键:随机化之后 AI-allowed 组恰好摊到了略难的任务,原始均值比是 1.34x,回归校正后才是 +19%。

AI-allowed 条件下开发者可以用任何 AI 工具、也可以不用;AI-disallowed 则禁一切生成式 AI(含 LLM 自动补全)。完成的工作提交 PR、走正常 review、合并进仓库,耗时为自报的 review 前后总实现时间(录屏用于合规检查和交叉验证,自报时间与录屏差 >20% 的会在录屏分析中剔除)。

录屏活动标注(AI-disallowed N=30 vs AI-allowed N=44):允许 AI 时主动编码时间占比从 36% 降到 24%、读/搜信息也下降,但多出约 20% 的时间用于 review AI 输出、写 prompt、等 AI 生成,idle 时间也更高——'管理 AI'的开销解释了时间去向。

录屏细粒度标注:时间去哪了

对 74 个有效录屏(84 小时视频)按约 10 秒分辨率手工打 27 类活动标签。AI-allowed 条件下,主动写代码的时间占比从 36% 降到 24%,读文档/搜索也下降,取而代之的是约 20% 的时间花在 prompt AI、等 AI 生成、review AI 输出上,idle 时间也更高。也就是说 AI 确实替开发者写了代码,但'管理 AI'的开销吃掉了收益还倒贴。

Cursor 后台数据显示开发者接受的 AI 生成代码行不足 44%,多数人报告需要大改 AI 代码才能达到这些仓库的合入标准。

20 个 factor 的排查

作者列出 20 个可能解释减速的因素逐一给证据分级:'可能贡献减速'的有 5 个——对 AI 有用性的过度乐观、开发者对仓库过于熟悉(越熟悉的 issue 减速越厉害)、仓库大而复杂、AI 可靠性低、AI 拿不到隐性上下文;'效应不明'的包括实验导致的 AI 过度使用、任务分布偏短、scope creep 等;其余(如 Cursor 不熟练、学习效应——即使只看研究后半段仍显著减速)被判定为不太可能是主因。作者明确承认不能完全排除实验 artifact,但减速在各种切法下都稳健。

Discussion 里作者自己划了适用边界:结果不代表 AI 对所有开发场景无用,小型 greenfield 项目或不熟悉的代码库完全可能有大幅加速;更强的模型、更好的 elicitation 也可能翻转结论。

关键结果

主结果:AI-allowed 使任务耗时 +19%(回归估计,95% CI 约 +2%~+39%);原始均值比更极端(1.34x),回归用事前预测校正了随机化后的难度不平衡。
感知与现实背离:开发者事前预测省 24%,事后估计省 20%;经济学专家预测省 39%,ML 专家预测省 38%——全部方向性错误。
开发者对'任务要多久'本身校准不错(预测与实际耗时 Pearson r = 0.59/0.64),错的只是'AI 有没有帮我'这一层。
录屏标注(74 个任务、84 小时):AI-allowed 下主动编码占比 36%→24%,约 20% 时间花在 prompt/等待/review AI 上,idle 也上升。
AI 生成代码接受率 <44%,9% 的总时间花在 review/清理 AI 输出;越熟悉的 issue 减速越明显。
METR 2026-02 后续:用 late-2025 工具(Claude Code/Codex 时代)重做实验,原班开发者子集点估计变为加速 18%(CI -38%~+9%),新开发者 -4%;但因严重选择效应(30-50% 开发者拒绝提交'不想徒手做'的任务),METR 自己宣布该轮数据不可靠并停用此设计。

实证核查

扎实数据和回归代码全公开,可复算;论文对 20 个潜在混淆逐一给证据,作者对局限的披露远超同类工作。注意两点:效应量的 CI 很宽(+2%~+39%,刚好显著),且 METR 自己已声明结论限定在'早 2025 工具 + 资深维护者 + 成熟大仓库'这一设定,不能外推到 2026 年的 agentic 工具。

16 名开发者、246 个任务、AI-allowed 136 / disallowed 110,AI 使耗时 +19%。

METR 公开了完整数据集 github.com/METR/Measuring-Early-2025-AI-on-Exp-OSS-Devs(data_complete.csv + regression.py)。实际下载核对:246 行、16 个 dev_id、ai_treatment 1.0/0.0 = 136/110,与论文完全一致;字段含事前预测和 review 前后自报耗时,回归可复算。仓库 issues 仅 3 个且全是 README typo,无人质疑数据本身。

减速效应稳健,不太可能主要是实验设计 artifact。

论文附录对 20 个因素逐一分析并公开子集回归(fig07-fig15):剔除早期非硬币翻转随机化的 issue、换估计器、换标准误设定、只看研究后半段(排除 Cursor 学习曲线)结论都不变。但要注意点估计的 CI 是 +2%~+39%——'慢了'方向可靠,'慢 19%'这个数字精度有限;HN/Medium 上的主要批评(n=16 太小、耗时自报)论文 FAQ 里都正面回应过:CI 已计入样本量,自报时间与录屏做过交叉验证。

该结果说明 AI 在真实开发中的能力可能低于 benchmark 显示的水平。

外推要非常小心:METR 2026-02-24 官方 blog(metr.org/blog/2026-02-24-uplift-update)承认,用 late-2025 工具重做时,原开发者子集点估计已翻转为加速 18%(CI -38%~+9%);同时因为开发者大量拒绝'徒手做任务'(30-50% 的人有选择性提交)、时薪从 $150 降到 $50 引入选择偏差,METR 判定新一轮数据不可靠并放弃该实验设计。即:原论文对 early-2025 的测量扎实,但'AI 让开发者变慢'作为一般性结论已被 METR 自己声明过时。

开发者是在自己极熟悉的成熟大仓库上被减速的(平均 5 年经验、1500 commits、110 万行代码)。

与 tex 源码 macros.tex 中的数值一致(MeanDevExperienceOnReposYears=5、MeanMaintainerCommits=1,500、MeanRepoLoC=1,100,000);公开数据的 per-dev 任务数分布也不由单人主导(最多一人 28/246)。这决定了结论的适用域:论文自己写明结果与'greenfield 项目或陌生代码库大幅加速'并不矛盾。

与我们方向的关系

对课题组做 'AI 加速 AI 研发' 的度量是最直接的警钟:主观报告完全不可信——被试用完 AI 之后仍坚信自己快了 20%,而秒表显示慢了 19%,ML 专家群体错得更离谱(预测快 38%)。任何以问卷、自评、专家预测为依据的 'AI uplift' 结论都应默认存疑,评测必须有客观时间/产出测量,理想情况下有随机对照。

方法论上有两点可直接借鉴:(1) 任务在随机化之前由被试自己定义并预测难度,预测值作为协变量进回归,既控制难度又量化了期望偏差;(2) METR 的后续失败同样有信息量——当 AI 成为默认工作方式后,'禁止 AI' 臂会引发严重的参与/任务选择效应,这类 RCT 设计的窗口期正在关闭,2026 年之后想测 uplift 可能只能靠 observational data 或 fixed-task 实验。