產碼速度上去後，驗證才是主戰場
我在做 SRE 時最怕的場面，通常是大家很有信心地把一批變更合進 main，過了半小時才發現 CI 還在排隊。這時候工程師會開始互相問「誰的 commit 卡住了」，但真正的問題往往早就超過某一個 commit 了。
Anthropic 分享的數字很有意思。每日合併量從 2026 年 5 月約 2,500 次，增加到 9 月超過 30,000 次，接近 12 倍。main branch 歷史接近 100 GB，CI 每天約 2,500 萬次 checkout。原本為人類團隊設計的 Git mirror、完整 checkout 和逐個 PR 排隊審查，在這個量級自然會變成生產線上的瓶頸。
我覺得最值得帶回中小團隊的，不是立刻去造一套 Scion。Anthropic 用 7 人、5 個月完成 Scion 與 Antique，確實很厲害，但多數團隊沒有同樣的流量，也沒有必要複製同一個解法。先把自己的變更流量、CI 等待時間、checkout 時間和失敗重跑率量出來，才知道瓶頸是在 Git、runner，還是測試本身。
如果每日合併量真的往 12 倍走，第一步可以做三件事。第一，CI 改成依照變更範圍跑測試，搭配 remote cache 和可重用的 build artifact，別讓每個小改動都重新 checkout 全部歷史。第二，把 main 的保護規則從「每個檢查都通過」改成分層風險門檻，低風險文件改動和涉及權限、資料庫 migration 的變更，不該共用一條等待路徑。第三，把 code review 從逐行找錯，移一部分到確認 agent 的意圖、測試證據和影響範圍。文章提到工程師常做的是對 Claude 說「不」，這其實代表審查工作沒有消失，只是更像在做變更核准。
另外要注意，驗證速度快不等於驗證品質高。我會每週看四個數字，從 PR 開始到可合併的中位時間、CI 排隊時間、變更失敗率、回滾或 hotfix 次數。若 checkout 從幾分鐘縮到幾秒，CI capacity 也改善 25%，卻讓失敗率上升，那只是把錯誤更快送進 production。
所以中小團隊現在就能做的事情很樸素：先記錄瓶頸，再拆測試層級，開啟 shallow 或 partial clone，建立可靠的 cache，最後才考慮換 source control。AI 把產碼推得更快之後，工程團隊的核心能力會從「能不能寫出來」移到「能不能用可接受的成本證明它可以上線」。這個轉換，應該比追下一個 coding agent 更早開始。
作者：承翰