论文信息
- 原标题：Novice Developers Produce Larger Review Overhead for Project Maintainers while Vibe Coding
- 主要作者：Syed Ammar Asdaque、Imran Haider、Muhammad Umar Malik、Abdul Ali Bangash、Maryam Abdul Ghafoor
- 研究机构：巴基斯坦拉合尔管理科学大学（Lahore University of Management Sciences）
- 发表会议：23rd International Conference on Mining Software Repositories (MSR '26)
- 发表时间：2026 年 4 月 13-14 日（巴西里约热内卢）
- 引文格式（GB/T 7714）：Asdaque S A,Haider I,Malik M U,et al. Novice Developers Produce Larger Review Overhead for Project Maintainers while Vibe Coding[C]//23rd International Conference on Mining Software Repositories. Rio de Janeiro: ACM,2026.
研究背景与核心问题
时代背景
Software 3.0 范式下 AI 编码工具被 92% 开发者使用，但现有研究对 AI 辅助编程的效果结论不一。部分研究发现高经验开发者用 AI 完成任务耗时增加 19%，且缺乏不同经验开发者的对比分析。
核心疑问
项目管理者能否用低经验 Vibe 编码者替代高经验开发者？开发者经验在 AI 辅助开发中是否仍具重要性？
概念界定
采用精准的 Vibe Coding 定义——人类开发者通过自然语言提示引导、监督 AI 代理，并验证其生成代码的工作流，区别于广义的 AI 辅助编程。
研究设计与数据来源
数据集
采用 AIDev 数据集（GitHub 开源项目的 AI 辅助 PR 合集），过滤掉机器人账户后，最终使用 1719 名 Vibe 编码者的 22953 个 PR，涵盖 Copilot、Claude Code 等主流 AI 编码工具的贡献。
经验划分方法
- 经验值计算：参考现有研究，以 GitHub 总提交数/账户创建时长作为经验评分指标；
- 分组方式：将 1719 名开发者按经验评分分为四四分位，前两个四分位（859 人）为高经验组（Exp_High），后两个四分位（860 人）为低经验组（Exp_Low）。
研究方法
采用三步分析法，筛选研究对象→按经验值分组→提取 PR 指标做统计分析；使用 Python 工具（pandas、scipy 等）开展检验，通过 Benjamini-Hochberg（BH）校正降低多次统计检验的假阳性风险。
核心研究问题
- RQ1：高/低经验 Vibe 编码者在开源项目中贡献的频率和规模是否存在差异？
- RQ2：高/低经验 Vibe 编码者的 PR 合并难度是否存在差异？
核心分析指标
| 指标类型 | 具体指标 | 指标含义 |
|---|---|---|
| 贡献规模指标 | 单 PR 提交次数 | 每个 PR 的代码提交频次 |
| 贡献规模指标 | 单 PR 修改文件数 | 每个 PR 涉及的修改文件数量 |
| PR 合并难度指标 | PR 接受率 | 合并 PR 数/总提交 PR 数 |
| PR 合并难度指标 | PR 解决时间 | PR 创建到合并的耗时（天） |
| PR 合并难度指标 | PR 评审评论数 | 每个 PR 收到的评审反馈评论数 |
核心研究结果
研究通过曼 - 惠特尼 U 检验、卡方检验验证了两组开发者的指标差异均具有统计学显著性（p<0.05），核心结果如下：
RQ1：低经验组贡献规模显著更大
- Exp_Low 的单 PR 提交次数是 Exp_High 的 2.15 倍，在 11 类 PR 中有 10 类呈显著差异，其中功能开发类 PR 差异最明显（Exp_High 1.58 次/PR vs Exp_Low 4.20 次/PR）；
- Exp_Low 的单 PR 修改文件数是 Exp_High 的 1.47 倍，在 11 类 PR 中有 9 类更多，其中样式类 PR 差异最明显（Exp_High 24.29 个/PR vs Exp_Low 70.35 个/PR）。
RQ2：低经验组 PR 合并难度显著更高
- 接受率低 31%：11 类 PR 中有 10 类 Exp_Low 接受率更低，文档类 PR 差异最明显（Exp_High 93.06% vs Exp_Low 75.39%）；
- 解决时间是 5.16 倍：11 类 PR 中有 10 类呈显著差异，日常事务类 PR 差异最明显（Exp_High 0.61 天/PR vs Exp_Low 2.83 天/PR）；
- 评审评论数是 4.52 倍：11 类 PR 中有 6 类呈显著差异，日常事务类 PR 差异最明显（Exp_High 0.13 条/PR vs Exp_Low 0.86 条/PR）。
问题分析与启示
低经验 Vibe 编码者的核心问题
通过人工检视低经验组在功能开发类 PR 中评审评论数前 15 的 PR，发现其核心问题为两类摩擦：
- 基础设施不匹配：AI 生成的代码语法正确，但未考虑构建环境、运行时的专属约束，低经验开发者无法本地复现环境问题，只能通过持续集成（CI）反复提交调试，增加 PR 提交次数。
- 集成摩擦：AI 生成的代码缺乏项目整体系统上下文，难以契合项目的隐私架构、集成标准等要求，需要评审者大量反馈并指导开发者手动调整。
实践建议
针对研究结果，为软件项目管理者、开发团队和研究者提出针对性建议：
- 项目管理层面：需预判低经验 Vibe 编码者带来的更高评审工作量，可为其 PR 分配额外评审人员、增加自动化评审检查，避免评审资源不足；
- 培训与入职层面：针对低经验开发者，强化 AI 生成代码的验证能力培训，重点培养代码正确性、风格、安全性的检验能力；
- 研究层面：本研究的经验分层分析框架为 AI 增强软件开发研究提供了新视角，可拓展至工业场景或纵向研究，为自适应 AI 工具、评审自动化策略设计提供实证基础。
研究的威胁与局限性
- 定义局限：研究结论仅适用于'人类监督 + 验证 AI 代码'的精准 Vibe Coding 定义，无法推广至广义的 AI 辅助编程；
- 经验度量局限：以 GitHub 提交数/账户时长为经验指标，混淆了开发活跃度与实际技术能力，可能将线下经验丰富但 GitHub 提交少的开发者归为低经验组；
- 外部因素局限：项目专属的评审政策、开发规范等因素可能影响 PR 指标，虽已按 PR 类别对比均值缓解偏差，但仍可能存在残余影响；
- 统计风险：多次统计检验存在假阳性风险，已通过 BH 校正确保结果稳健性。
研究结论
- AI 辅助编程（Vibe Coding）让低经验开发者能产出规模更大的代码贡献，但同时带来了巨大的评审验证成本，将验证工作的负担转移给了项目评审者；
- 项目管理者无法安全地用低经验 Vibe 编码者替代高经验开发者，除非大幅提升项目的评审能力；
- 开发团队需结合低经验开发者的针对性验证培训与自适应的 PR 评审周期，平衡 AI 辅助开发的效率与质量；
- 本研究的经验分层分析框架为研究人类-AI 协作的软件工程动态提供了稳健的方法，为后续相关研究奠定基础。
常见问题
Q1：该研究如何界定和划分低/高经验的 Vibe 编码者？
A：研究采用精准的 Vibe Coding 定义；经验划分上，以总提交数/账户创建时长作为经验评分指标，再将 1719 名开发者按经验评分分为四四分位，后两个四分位为低经验组，前两个四分位为高经验组。
Q2：低经验 Vibe 编码者的 PR 在贡献规模和合并难度上，与高经验组相比呈现出哪些核心的量化差异？
A：贡献规模上，低经验组单 PR 提交次数是高经验组的 2.15 倍，单 PR 修改文件数是其 1.47 倍；合并难度上，低经验组 PR 接受率比高经验组低 31%，PR 解决时间是其 5.16 倍，收到的评审评论数是其 4.52 倍。
Q3：基于该研究结果，软件项目管理者和开发团队应采取哪些措施？
A：①资源配置层面：为低经验开发者的 PR 分配额外的评审人员，或搭建自动化评审检查机制；②培训体系层面：开展针对性的培训，重点强化 AI 生成代码的验证技能；③流程设计层面：建立自适应的 PR 评审周期，合理分配评审资源。
开源资源
本研究为支持开放科学，已将复现包开源，地址：https://github.com/AmmarAsdaque/msr-2026-replication-package
