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編碼會破壞主線的常見擔憂，並強調了團隊規模管理的重要性。