Novice Developers Produce Larger Review Overhead for Project Maintainers while Vibe Coding
Syed Ammar Asdaque, Imran Haider, Muhammad Umar Malik, Maryam Abdul Ghafoor, Abdul Ali Bangash
cs.SE
2026-02-27
LUMS 团队分析 AIDev 数据集里 1,719 名 vibe coder 的 22,953 个 PR:低经验组提交量更大(提交数多 2.15 倍),但审阅评论多收 4.52 倍、接受率低 31%、解决时长多 5.16 倍,验证负担全压给了维护者。
AI 编程工具普及后,管理者和开源维护者面前多了一个现实问题:一个经验不多的开发者,靠着 Copilot、Cursor、Claude Code 这类 agent 大量产出代码,能不能顶替一个资深开发者?直觉上答案偏乐观,毕竟 92% 的开发者都在用 AI 工具(论文引的 GitHub 调查),产出肉眼可见地变快。
但产出快不等于产出能用。此前的一项对照实验已经泼过冷水:资深开源开发者用上 AI 助手后,完成任务的时间反而多了约 19%,瓶颈从写代码挪到了验证代码。这篇论文把问题落到仓库层面:按开发者经验分组,量出 AI 生成的 PR 在提交量、接受率、审阅成本、解决时长上的真实差距。作者全部来自巴基斯坦 LUMS,论文发表在软件仓库挖掘会议 MSR 2026。
数据取自 AIDev,一个公开的 GitHub AI 辅助 PR 语料库,收录 Copilot、Codex、Claude Code、Cursor、Devin 等主流 agent 的贡献。作者取其中 100 星以上仓库的 33,596 个 PR、1,796 名用户,过滤掉用户名含 bot 或已知 agent 标识的纯自主账号,剩 1,719 名「vibe coder」(人指挥、AI 执行的工作流)的 22,953 个 PR。
经验度量沿用既有文献的做法:GitHub 全生命周期提交总数除以账号年龄,按四分位分组。上两个四分位的 859 人记为高经验组,下两个四分位的 860 人记为低经验组。每个 PR 提取四组指标:提交数、改动文件数、接受率、解决时长(创建到合并的天数)加审阅评论数。组间用 Mann-Whitney U 检验(接受率用卡方),再做 Benjamini-Hochberg 多重比较校正,全部分析按 PR 类别分层(缺陷修复、功能开发、文档等 11 类)。
| 指标 | 低经验组 vs 高经验组 | 显著性 |
| 每 PR 提交数 | 2.15 倍 | p<0.05,11 类中 10 类显著 |
| 每 PR 改动文件数 | 1.47 倍 | p<0.05,11 类中 5 类显著 |
| PR 接受率 | 低 31% | p<0.05,11 类中 10 类显著 |
| 解决时长 | 5.16 倍 | p<0.05,11 类中 10 类显著 |
| 审阅评论数 | 4.52 倍 | p<0.05,11 类中 6 类显著 |
类别层面的极端例子:功能开发类 PR,高经验组平均 1.58 个提交,低经验组 4.20 个;代码风格类,高经验组平均改 24.29 个文件,低经验组改 70.35 个;文档类接受率 93.06% 对 75.39%;杂务类解决时长 0.61 天对 2.83 天。
方向很清楚:低经验组在 AI 加持下产出的 PR 更大更多,但每单位产出消耗的审阅资源成倍增加,最后被接受的反而更少。作者手动检查了低经验组功能开发类里审阅量最高的 15 个 PR,归纳出两类反复出现的摩擦。一是基础设施错配:AI 生成的代码语法没错,但对 CI 环境的超时、运行时约束不敏感,vibe coder 只能反复提交去调超时参数,等于拿 CI 当调试器(roboflow/inference 的 PR#1350)。二是集成摩擦:功能逻辑生成出来了,却不符合仓库既有的隐私数据结构和集成规范,来回返工(getsentry/sentry 的 PR#94889)。
这是第一篇系统比较「AI 辅助贡献 × 开发者经验」的研究。此前 AIDev 的原论文只说了 AI 生成 PR 整体接受率偏低,这篇把差距拆到了经验维度上,结论对两类读者直接可用。
对工程管理者:用低经验 vibe coder 替换资深开发者的账不能只算产出。在这套数据里,每替换一单位的编写产能,配套要扩大的审阅产能是 4.5 倍评论量、5 倍滞留时长。要么扩审阅容量,要么把新手的培训重心放在「怎么验证 AI 生成的代码」,而不是怎么提问。对开源维护者:AI PR 洪峰里,来自低经验账号的 PR 是成本最集中的一块,自动检查、多审阅人分派这类分流手段应该优先盖在它上面。
对 vibe coding 这个工种本身,这组数字也是一个提醒:AI 填平的是写代码的门槛,没填平的是判断代码该不该进主干的门槛。
作者自己列了四条:vibe coding 定义宽窄会影响结论适用面;经验用提交频率度量,把活跃度当成了技能,线下经验丰富但 GitHub 记录少的人会被错分进低经验组;各仓库审阅政策不同,接受率和评论数受项目因素干扰,只按类别分层没有完全消除;多重比较虽做了 BH 校正,类别层分析里 11 选 10 显著这种模式仍可能有假阳性残留。
读下来还有两点。一是相关不等于因果:低经验组的 PR 更大,也可能因为他们接的任务类型本来就偏大,论文用类别分层部分缓解,但类别标签来自 AIDev 的自动分类,粒度有限。二是经验分组是对半劈的四分位,组内差异被平均掉了;文件改动数是明显的长尾分布,24.29 对 70.35 这种均值对比容易被极端 PR 拉高,中位数会更有说服力,论文图表给了分布但正文只报均值。