AI编写代码导致主线破坏频率减半
Mergify的《合并队列状态报告》分析了超过20万次合并，发现AI辅助的拉取请求破坏主线的概率仅为1.9%，远低于非AI的4.4%。报告还揭示了团队规模与主线破坏率之间的强相关性：40人以上的团队中，每8次合并就有1次可能导致主线破坏。
Mergify发布了其2026年《合并队列状态报告》，基于过去三个月超过20万次合并的数据，揭示了AI辅助编码、团队规模与主线稳定性之间的关系。这份报告由Mergify联合创始人兼CEO Julien Danjou撰写，分析了477个工程团队的合并行为，旨在回答一个简单问题：一个拉取请求（PR）从批准到合并到主线之间到底发生了什么？
报告显示，AI辅助的PR破坏主线的概率仅为非AI PR的一半（1.9% vs 4.4%），这一发现在控制PR大小和仓库后仍然成立。值得注意的是，AI辅助的PR平均改动行数（137行）反而高于非AI PR（84行），排除了“更小PR更安全”的解释。目前约七分之一的私有合并已带有AI辅助痕迹，这还只是下限，因为许多工具（如Copilot内联建议）不会留下标记。自主代理完整编写PR的情况仍然很少，仅占少数。
团队规模是影响主线稳定性的关键因素。2-5人的小团队中，主线破坏率仅为0.77%（约130次合并一次），而40人以上的团队飙升至12.5%（每8次合并一次）。破坏率从16-40人阶段开始明显上升（2.49%），这正是团队开始感受到合并痛点的时候。私有仓库的破坏率是开源的4.5倍（5.1% vs 1.1%），归因于私有代码库中互依赖的代码更密集。私有仓库的失败批次平均包含约5.8个PR，而开源仅为2.6个。
报告还指出，尽管批量合并（同时测试多个PR）能显著减少CI开销，但94%的私有合并仍采用单PR模式。平均而言，私有仓库的失败批次包含约5.8个PR，而开源仅为2.6个。合并队列的延迟中位数约为7分钟，但p99尾延迟可达20小时（私有仓库）。自动化工具如Dependabot和Renovate处理速度更快，平均0.4分钟，而人类PR约需12分钟。
对于工程团队，报告建议关注团队规模而非时间线：当团队超过15-20人时，合并队列从可选变为必要。同时，在队列繁忙时应启用批量合并，这是数据中最被忽视的优化手段。报告还比较了GitHub原生队列与专业队列的差异，指出专业队列在批量自动二分、按范围并行队列和优先级通道方面的优势。
总之，这份报告提供了基于实证的洞察，挑战了AI编码会破坏主线的常见担忧，并强调了团队规模管理的重要性。