AI辅助编程时代，新手真能替代资深开发者吗？这份实证研究给出答案

论文信息

1. 原标题：Novice Developers Produce Larger Review Overhead for Project Maintainers while Vibe Coding
2. 主要作者：Syed Ammar Asdaque、Imran Haider、Muhammad Umar Malik、Abdul Ali Bangash、Maryam Abdul Ghafoor
3. 研究机构：巴基斯坦拉合尔管理科学大学（Lahore University of Management Sciences）
4. 发表会议：23rd International Conference on Mining Software Repositories (MSR ’26)
5. 发表时间：2026年4月13-14日（巴西里约热内卢）
6. 引文格式（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.

一段话总结

该研究由巴基斯坦拉合尔管理科学大学的学者完成，聚焦AI辅助编程（Vibe Coding） 背景下不同开发经验水平开发者的贡献差异，分析了AIDev数据集里1719名Vibe编码者的22953个GitHub拉取请求（PR），将开发者分为低经验组（Exp_Low）和高经验组（Exp_High），发现Exp_Low提交的PR在提交次数（2.15倍）和修改文件数（1.47倍）上均多于Exp_High，但前者PR接受率低31%、解决耗时是后者的5.16倍、收到的评审评论数是后者的4.52倍，核心原因是低经验开发者存在基础设施不匹配和集成摩擦问题，研究指出项目管理者无法用低经验Vibe编码者替代高经验者，需配套针对性培训和自适应PR评审机制，同时也指出了研究在定义、经验度量等方面的有效性威胁。

---

思维导图

---

详细总结

本研究是针对AI辅助编程（Vibe Coding） 时代不同开发经验开发者贡献差异的实证研究，发表于2026年第23届挖掘软件仓库国际会议（MSR ’26），由巴基斯坦拉合尔管理科学大学团队完成，核心探究低经验Vibe编码者能否替代高经验开发者，以下是详细研究脉络与结果：

一、研究背景与核心问题

1. 时代背景：Software 3.0 范式下AI编码工具被92%开发者使用，但现有研究对AI辅助编程的效果结论不一，如部分研究发现高经验开发者用AI完成任务耗时增加19%，且缺乏不同经验开发者的对比分析。
2. 核心疑问：项目管理者能否用低经验Vibe编码者替代高经验开发者，开发者经验在AI辅助开发中是否仍具重要性。
3. 概念界定：采用精准的Vibe Coding定义——人类开发者通过自然语言提示引导、监督AI代理，并验证其生成代码的工作流，区别于广义的AI辅助编程。

二、研究设计与数据来源

1. 数据集：采用AIDev数据集（GitHub开源项目的AI辅助PR合集），过滤掉机器人账户后，最终使用1719名Vibe编码者的22953个PR，涵盖Copilot、Claude Code等主流AI编码工具的贡献。
2. 经验划分方法
   • 经验值计算：参考现有研究，以GitHub总提交数/账户创建时长作为经验评分指标；
   • 分组方式：将1719名开发者按经验评分分为四四分位，前两个四分位（859人）为高经验组（Exp_High），后两个四分位（860人）为低经验组（Exp_Low）。
3. 研究方法：采用三步分析法，筛选研究对象→按经验值分组→提取PR指标做统计分析；使用Python工具（pandas、scipy等）开展检验，通过Benjamini-Hochberg（BH）校正降低多次统计检验的假阳性风险。
4. 核心研究问题
   • RQ1：高/低经验Vibe编码者在开源项目中贡献的频率和规模是否存在差异？
   • RQ2：高/低经验Vibe编码者的PR合并难度是否存在差异？
5. 核心分析指标

   指标类型	具体指标	指标含义
   贡献规模指标	单PR提交次数	每个PR的代码提交频次
   贡献规模指标	单PR修改文件数	每个PR涉及的修改文件数量
   PR合并难度指标	PR接受率	合并PR数/总提交PR数
   PR合并难度指标	PR解决时间	PR创建到合并的耗时（天）
   PR合并难度指标	PR评审评论数	每个PR收到的评审反馈评论数

三、核心研究结果（含关键数字）

研究通过曼-惠特尼U检验、卡方检验验证了两组开发者的指标差异均具有统计学显著性（p<0.05），核心结果如下：

1. RQ1：低经验组贡献规模显著更大

   • Exp_Low的单PR提交次数是Exp_High的2.15倍，在11类PR中有10类呈显著差异，其中功能开发类PR差异最明显（Exp_High1.58次/PR vs Exp_Low4.20次/PR）；
   • Exp_Low的单PR修改文件数是Exp_High的1.47倍，在11类PR中有9类更多，其中样式类PR差异最明显（Exp_High24.29个/PR vs Exp_Low70.35个/PR）。

2. RQ2：低经验组PR合并难度显著更高

   • 接受率低31%：11类PR中有10类Exp_Low接受率更低，文档类PR差异最明显（Exp_High93.06% vs Exp_Low75.39%）；
   • 解决时间是5.16倍：11类PR中有10类呈显著差异，日常事务类PR差异最明显（Exp_High0.61天/PR vs Exp_Low2.83天/PR）；
   • 评审评论数是4.52倍：11类PR中有6类呈显著差异，日常事务类PR差异最明显（Exp_High0.13条/PR vs Exp_Low0.86条/PR）。

四、低经验Vibe编码者的核心问题分析

通过人工检视低经验组在功能开发类PR（数据集最常见PR类型）中评审评论数前15的PR，发现其核心问题为两类摩擦：

1. 基础设施不匹配：AI生成的代码语法正确，但未考虑构建环境、运行时的专属约束，低经验开发者无法本地复现环境问题，只能通过持续集成（CI）反复提交调试，增加PR提交次数。
2. 集成摩擦：AI生成的代码缺乏项目整体系统上下文，难以契合项目的隐私架构、集成标准等要求，需要评审者大量反馈并指导开发者手动调整。

五、研究启示与实践建议

针对研究结果，为软件项目管理者、开发团队和研究者提出针对性建议：

1. 项目管理层面：需预判低经验Vibe编码者带来的更高评审工作量，可为其PR分配额外评审人员、增加自动化评审检查，避免评审资源不足；
2. 培训与入职层面：针对低经验开发者，强化AI生成代码的验证能力培训，重点培养代码正确性、风格、安全性的检验能力；
3. 研究层面：本研究的经验分层分析框架为AI增强软件开发研究提供了新视角，可拓展至工业场景或纵向研究，为自适应AI工具、评审自动化策略设计提供实证基础。

六、研究的威胁与局限性

1. 定义局限：研究结论仅适用于“人类监督+验证AI代码”的精准Vibe Coding定义，无法推广至广义的AI辅助编程；
2. 经验度量局限：以GitHub提交数/账户时长为经验指标，混淆了开发活跃度与实际技术能力，可能将线下经验丰富但GitHub提交少的开发者归为低经验组；
3. 外部因素局限：项目专属的评审政策、开发规范等因素可能影响PR指标，虽已按PR类别对比均值缓解偏差，但仍可能存在残余影响；
4. 统计风险：多次统计检验存在假阳性风险，已通过BH校正确保结果稳健性。

七、研究结论

1. AI辅助编程（Vibe Coding）让低经验开发者能产出规模更大的代码贡献，但同时带来了巨大的评审验证成本，将验证工作的负担转移给了项目评审者；
2. 项目管理者无法安全地用低经验Vibe编码者替代高经验开发者，除非大幅提升项目的评审能力；
3. 开发团队需结合低经验开发者的针对性验证培训与自适应的PR评审周期，平衡AI辅助开发的效率与质量；
4. 本研究的经验分层分析框架为研究人类-AI协作的软件工程动态提供了稳健的方法，为后续相关研究奠定基础。

---

关键问题

问题1（研究设计类）：该研究如何界定和划分低/高经验的Vibe编码者，采用的经验度量指标是什么？

答案：研究采用精准的Vibe Coding定义——人类通过自然语言提示引导、监督AI代理并验证其生成代码的工作流；经验划分上，先通过GitHub GraphQL API获取开发者的全量提交历史，以总提交数/账户创建时长作为经验评分指标，再将1719名开发者按经验评分分为四四分位，后两个四分位（860人）为低经验组（Exp_Low），前两个四分位（859人）为高经验组（Exp_High）。

问题2（研究结果类）：低经验Vibe编码者的PR在贡献规模和合并难度上，与高经验组相比呈现出哪些核心的量化差异（含关键数字）？

答案：贡献规模上，低经验组单PR提交次数是高经验组的2.15倍，单PR修改文件数是其1.47倍；合并难度上，低经验组PR接受率比高经验组低31%，PR解决时间是其5.16倍，收到的评审评论数是其4.52倍，且上述差异多数在PR类别中具有统计学显著性（p<0.05）。

问题3（实践应用类）：基于该研究结果，软件项目管理者和开发团队应采取哪些措施，来缓解低经验Vibe编码者带来的评审负担？

答案：① 资源配置层面：为低经验开发者的PR分配额外的评审人员，或针对其PR搭建专属的自动化评审检查机制，提升评审能力；② 培训体系层面：为低经验开发者开展针对性的培训，重点强化AI生成代码的验证技能，包括代码正确性、风格、安全性的检验，以及项目构建环境、系统架构的适配能力；③ 流程设计层面：建立自适应的PR评审周期，对低经验开发者的PR实施更精细化的评审监督，同时可通过监控PR评审评论数的异常波动，合理分配评审资源。

研究背景

当下软件开发已迈入Software 3.0时代，AI编码工具（Copilot、Claude Code、Devin等）成为开发者的标配——调查显示92%的开发者都在使用AI辅助编程，大家普遍认为这些工具能节省精力、提升开发效率。

在传统的Software 2.0时代，开发者的经验直接决定开发效率：资深开发者能高效驾驭复杂代码库，新手则只能处理简单任务，且资深开发者提交的代码贡献质量更高、合并通过率也远高于新手。但AI工具的出现，让这一传统认知受到了挑战：新手也能借助AI快速生成大量代码，这就让项目管理者和开源维护者产生了一个核心疑问——低经验的AI辅助编程者（Vibe Coder），能否替代资深开发者完成开发工作？

与此同时，现有研究也呈现出矛盾的结论：有研究发现资深开发者使用AI工具后，完成任务的时间反而增加了19%；也有研究指出AI生成的代码合并通过率远低于人工编写的代码，但这些研究都有一个共同的短板——没有系统对比不同经验水平开发者，在AI辅助编程下的实际贡献差异。正是在这样的背景下，该研究团队针对“AI辅助编程中开发者经验的价值”展开了实证分析，填补了这一领域的研究空白。

创新点

1. 首次系统对比不同经验水平Vibe Coder的贡献差异：此前研究要么只关注AI工具对开发者的整体影响，要么未区分经验层级，本研究首次将低/高经验开发者分组，从贡献规模和合并难度两大维度做量化对比，结论更具针对性。
2. 明确Vibe Coding的精准定义：摒弃了广义的“AI辅助编程”定义，采用“人类通过自然语言引导、监督AI代理，并验证其生成代码”的精准定义，让研究边界更清晰、结果更具参考性。
3. 结合量化分析与人工检视：在通过统计方法得出量化结论后，进一步人工分析高评审负担的PR案例，挖掘出新手AI辅助编程的核心问题，让研究结论不仅有数据支撑，还有实际原因分析，为实践建议提供了更坚实的依据。
4. 提出经验评分的量化指标：参考现有研究并结合GitHub平台特性，用总提交数/账户创建时长作为开发者经验评分标准，让经验划分更客观、可复现。

研究方法和思路

本研究采用实证分析方法，基于GitHub开源项目的真实AI辅助编程数据展开研究，整体思路分为数据准备、分组划分、指标提取、统计分析、案例验证五大步骤，具体拆解如下：

步骤1：确定研究数据集

选用AIDev数据集（GitHub开源项目的AI辅助PR合集），该数据集包含33596个PR和1796名用户，涵盖Copilot、Codex、Claude Code等主流AI编码工具的贡献，且仅选取星数超100的仓库PR，保证数据的代表性。

步骤2：筛选纯人类Vibe Coder

为排除全自动化AI代理的干扰，过滤掉用户名含“bot”或匹配AI工具标识（如Copilot）的账户，最终保留1719名人类Vibe Coder的22953个PR作为研究样本。

步骤3：划分低/高经验开发者分组

1. 通过GitHub GraphQL API获取每个开发者的全量提交历史，从账户创建日开始统计总提交数；
2. 计算经验评分=总提交数/账户创建时长，量化开发者的开发经验；
3. 将1719名开发者按经验评分分为四四分位，后两个四分位（860人）为低经验组（Exp_Low），前两个四分位（859人）为高经验组（Exp_High）。

步骤4：提取核心分析指标

从每个PR中提取贡献规模和PR合并难度两大维度的4个核心指标，作为对比分析的依据：

指标维度	具体指标	指标含义
贡献规模	单PR提交次数	每个PR的代码提交频次
贡献规模	单PR修改文件数	每个PR涉及的修改文件数量
PR合并难度	PR接受率	合并PR数/总提交PR数
PR合并难度	PR解决时间	PR创建到合并的耗时（天）
PR合并难度	PR评审评论数	每个PR收到的评审反馈评论数

步骤5：开展统计检验与分组对比

使用Python工具（pandas、scipy、matplotlib等）对两组开发者的指标进行组间统计检验，采用曼-惠特尼U检验、卡方检验验证差异的统计学显著性，并通过Benjamini-Hochberg（BH）校正降低多次检验的假阳性风险；同时按PR类别（bug修复、功能开发、文档等11类）做细分对比，确保结论的全面性。

步骤6：人工检视案例，挖掘核心问题

针对低经验组评审评论数最高的15个功能开发类PR（数据集最常见PR类型）做人工分析，挖掘出新手AI辅助编程的核心问题，为研究结论提供原因支撑。

主要成果和贡献

一、核心量化研究成果

本研究围绕两个核心研究问题，得出了具有统计学显著性（p<0.05）的量化结论，且所有结论均在多数PR类别中成立，具体如下表所示：

研究问题	对比维度	核心结论（Exp_Low vs Exp_High）	关键细分差异案例
RQ1：低/高经验Vibe Coder的贡献规模是否有差异？	单PR提交次数	Exp_Low是Exp_High的2.15倍，11类PR中10类呈显著差异	功能开发类PR：Exp_High1.58次/PR vs Exp_Low4.20次/PR
RQ1：低/高经验Vibe Coder的贡献规模是否有差异？	单PR修改文件数	Exp_Low是Exp_High的1.47倍，11类PR中9类更多	样式类PR：Exp_High24.29个/PR vs Exp_Low70.35个/PR
RQ2：低/高经验Vibe Coder的PR合并难度是否有差异？	PR接受率	Exp_Low比Exp_High低31%，11类PR中10类呈显著差异	文档类PR：Exp_High93.06% vs Exp_Low75.39%
RQ2：低/高经验Vibe Coder的PR合并难度是否有差异？	PR解决时间	Exp_Low是Exp_High的5.16倍，11类PR中10类呈显著差异	日常事务类PR：Exp_High0.61天/PR vs Exp_Low2.83天/PR
RQ2：低/高经验Vibe Coder的PR合并难度是否有差异？	PR评审评论数	Exp_Low是Exp_High的4.52倍，11类PR中6类呈显著差异	日常事务类PR：Exp_High0.13条/PR vs Exp_Low0.86条/PR

核心反直觉发现：低经验开发者借助AI能产出规模更大的代码贡献，但这些贡献的质量和可合并性极差，反而给项目带来了巨大的评审负担。

二、新手Vibe Coding的核心问题

通过人工检视案例，发现低经验开发者的AI辅助编程主要存在两大核心问题，也是导致其PR评审负担暴增的根本原因：

1. 基础设施不匹配：AI生成的代码语法正确，但未考虑项目构建环境、运行时的专属约束，新手无法本地复现环境问题，只能通过CI反复提交调试，导致PR提交次数大幅增加；
2. 集成摩擦：AI生成的代码缺乏项目整体系统上下文，难以契合项目的隐私架构、集成标准等要求，需要评审者大量反馈并指导新手手动调整，延长了PR解决时间。

三、研究的实际价值与贡献

1. 对项目管理者/开源维护者：提供可落地的实践指导

• 不可直接用低经验Vibe Coder替代资深开发者，除非大幅提升项目的评审能力；
• 为低经验开发者的PR分配额外评审人员，或搭建自动化评审检查机制，缓解评审负担；
• 监控PR评审评论数的异常波动，动态分配评审资源，提升评审效率。

2. 对开发团队/开发者培训：明确新手培训重点

• 针对低经验开发者，强化AI生成代码的验证能力培训，重点培养代码正确性、风格、安全性的检验能力；
• 增加项目构建环境、系统架构的适配培训，让新手能提前规避基础设施不匹配和集成摩擦问题。

3. 对学术研究：填补领域空白，提供研究框架

• 首次系统对比不同经验水平Vibe Coder的贡献差异，填补了Software 3.0时代AI辅助编程研究的空白；
• 提出的经验评分指标和低/高经验分组分析框架，为后续研究人类-AI协作的软件工程动态提供了可复现的方法论；
• 研究结果为设计自适应AI工具、评审自动化策略、软件开发任务分配模型提供了实证基础。

四、开源资源

本研究为支持开放科学，已将复现包开源，地址：https://github.com/AmmarAsdaque/msr-2026-replication-package

总结

该研究是Software 3.0时代针对AI辅助编程（Vibe Coding）的一项重要实证研究，通过分析1719名人类Vibe Coder的22953个GitHub PR，系统对比了低/高经验开发者的AI辅助编程贡献差异。研究发现，低经验开发者借助AI能产出2.15倍提交次数、1.47倍修改文件数的大规模代码贡献，但这些PR的接受率低31%、解决时间是高经验者的5.16倍、评审评论数是4.52倍，核心原因是新手存在基础设施不匹配和集成摩擦两大问题，将大量验证工作负担转移给了评审者。

研究明确指出，项目管理者无法在不提升评审能力的前提下，用低经验Vibe Coder替代资深开发者；同时为开发团队提出了“针对性培训+自适应评审”的解决方案，既填补了学术研究空白，又为工业界的AI辅助编程实践提供了可落地的指导。此外，研究提出的经验评分和分组分析框架，也为后续相关研究奠定了方法论基础。