Anthropic 如何做到每天合併 3 萬筆程式碼變更——Manish Kapoor（Sonar）與 Addy Osmani（Anthropic）對談

Anthropic 負責 Claude Code 開發者體驗的 Addy Osmani 認為，AI 已經解決了程式碼生成，卻仍未解決程式碼信心；如今工程團隊真正該投資的瓶頸是驗證，而非撰寫。他在與 Sonar 的 Manish Kapur 對談時說明，Anthropic 內部團隊每天合併約 3 萬筆程式碼變更，背後靠的是自動化的第一輪審查與會產生證據的代理。這場對談涵蓋了這套審查流程、"明工廠與暗工廠" 的軟體工廠光譜、多層次驗證、代理護欄，以及代理撰寫的程式碼是否該被標記；每天 3 萬筆這個亮眼數字，只是整場關於信任與問責的討論中的一個資料點。

Osmani 在 Google 任職約 14 年後加入 Anthropic；Kapur 則帶領 Sonar 的產品與解決方案開發者關係團隊。兩人皆站在販售驗證與代理工具的廠商立場發言，因此他們引用的統計與預測應視為其自身說法。讀者閱讀後應能掌握：AI 程式碼採用率與審查落差的具體數字、Anthropic 內部的審查迴圈，以及兩人針對正邁向自主軟體工廠的團隊所提出的實務框架——分層驗證、引導軌道、贏來的自主權。

寫程式已被解決，驗證才是新瓶頸

Kapur 開場先請全場舉手：前一週幾乎所有人都讓 coding agent 提交 pull request，但只有少數人逐行審查每一段合併的程式碼。這個落差就是整集的骨幹。Kapur 引用 Sonar 即將發布的程式碼狀態報告，該報告調查了近 1,000 名開發者：84% 表示 AI 功能已進入正式環境、修復速度也更快；pull request 正變得越來越大、越來越複雜；只有 31% 的程式碼在未經測試的情況下就上線——他稱這對受監管與關鍵任務應用而言是「有點嚇人的事實」。

Osmani 把高層該問的問題定調為：如何讓程式碼上線得 *更快、也更有信心*。他認為信心來自那些長久以來已經定義好的程式碼要素——測試、基準、規格——而代理現在能以更低成本產出這些東西。他最具體的論斷是：讓代理具備驗證自己工作的能力，可讓產出品質「提升兩到三倍」。

Anthropic 每天合併約 3 萬筆變更，背後是自動化審查迴圈

Kapur 指出，Anthropic 在 2026 年 5 月每天合併約 2,500 筆變更，如今每天約合併 3 萬筆——他稱這個跳升「很驚人」。Osmani 證實了 5 月的數字，並提到一份已發布的案例研究：最近一次 Claude.ai 更新整合了約 3,000 個 pull request，參與者橫跨工程師、產品設計師與其他職能，據稱生產力提升為三倍。

Osmani 描述的流程是：由 Claude 執行第一輪審查；代理必須能像真實使用者一樣體驗產品（開啟介面、在瀏覽器中測試、執行 lint 與其他檢查）；並在編輯時觸發攔截器，揪出 bug 或功能缺口，推動一輪修正。接著由人類驗證代理提供的證據，而不是重讀每一行程式碼——例如一段瀏覽器工作階段的生成影片，或行動版、桌機版流程的截圖。

flowchart TD
    A["代理開啟 pull request"] --> B["Claude 第一輪審查"]
    B --> C["代理在瀏覽器中端到端執行任務，並跑 lint 與各項檢查"]
    C --> D{"攔截器發現 bug 或缺口？"}
    D -->|是| E["在 PR 上進入修正迴圈"]
    E --> B
    D -->|否| F["代理提供證據，影片或截圖"]
    F --> G["人類驗證證據後合併"]

Osmani 強調，要把團隊的品味與最佳實務寫進代理審查時會查閱的共用資源——Claude.md、agents.md——讓審查標準就放在代理讀得到的地方。

明工廠與暗工廠，落在人類參與程度的光譜上

Osmani 把軟體工廠定義為：由代理大規模地迴圈執行規劃、建置、測試與上線，並分成兩種模式。在「明工廠」裡，人類仍在每個階段運用品味與判斷。在「暗工廠」裡，流程像機器人驅動的汽車產線——界定範圍、創造、驗證——人則退到思考意圖的層次，只在最大的例外發生時才被拉進來。Kapur 補上產線的框架：先有意圖與規格，才有程式碼，軟體生命週期的每個階段都自動化；暗工廠裡「一盞燈都不開」，24 小時全年無休地運轉。

被問到預測多數團隊在 2027 年底會走到哪裡，Osmani 說會是「帶有幾個暗角落的明亮工廠」——他不認為全場會全面採用暗工廠，但預期 Anthropic 自己會在這一、兩年內做到。Kapur 的調查資料顯示，目前只有 5% 的公司採用軟體工廠，金融服務業為 34%；現場舉手也只有寥寥幾人表示正在使用。

驗證必須分層、零信任，且在每個迴圈中執行

Kapur 說明 Sonar 的立場，呼應其執行長當天的主題演講：每家公司都應採用多層次、零信任的驗證，並套用到每一個迴圈——代理迴圈內、CI 內，以及程式碼維護期間。他描述三個層次，各自針對不同型別的問題：

Osmani 同意，下一波進展來自把精準的驗證與模型品質結合，而他認為模型品質已經很強——他舉「Opus 55」為例，說已達到不錯的水準。他主張討論應該具體到*哪些*測試能建立信心：Anthropic 高度依賴端到端測試、屬性測試與視覺驗證測試，因為正是這些測試讓變更得以自動合併。

代理氾濫，逼出控制、許可權與沙箱

Osmani 提到，在這場對談的幾個月前，他接觸的許多公司都放任工程團隊實驗代理，直到有數百、數千個代理在跑，卻不清楚它們碰了什麼、存取了哪些資料、有沒有部署到正式環境。他從企業端聽到的三大優先事項是控制、許可權與沙箱——包括確保代理無法逃出沙箱。

Kapur 提出 Sonar 的重新框架：與其叫「護欄」（guardrails），不如叫「引導軌道」（guide rails），把代理導上既定軌道，而不只是圍起來。雙方共同的關注點是代理的識別與遙測——要能知道代理在各系統中實際做了什麼。

標記代理撰寫的程式碼，並把自主權視為贏來的

至於代理撰寫的程式碼是否該在報告中標記，兩人都認為應該。Osmani 說 Anthropic 已經不太在意 Claude 是否被標為作者，重點轉向交付的功能是否正確；標記也有助於界定代理撰寫的程式碼需要哪些額外檢查。Kapur 主張至少在未來 6 到 9 個月內標記 pull request，一來建立對工廠的信心，二來滿足金融客戶的稽核需求。Osmani 的說法是：「問責才是這裡最重要的一環」——他可能會開一個 Claude 例項來完成工作，但東西壞了，就是他來修。

被問到初階工程師與主管今年該培養什麼能力，Osmani 說主管應推動團隊定義「驗證」代表什麼、如何進行測試，包括多快能信任代理自行簽核程式碼並自動合併；初階工程師則應深入掌握端到端測試、功能測試等各種測試型別。至於代理開啟的 PR 何時可以安全合併，他的答案是：當你完全確信不會出錯，或已把風險降到最低的時候。

Kapur 以三點作結：寫程式是最快的一環，而這個問題已經解決；寫得快不等於上線快，所以要盤點並審查每一次合併；自主權是靠工廠每個迴圈中獨立的 automated 驗證贏來的。

「寫得快不等於開發得快。你要盤點正在合併的東西、審查正在合併的東西，並確保它沒有跑出沙箱之外。」

真正的未解問題是信任落差，而非吞吐量落差

這集的數字指向相反方向：吞吐量成長 59%、Anthropic 每天合併 3 萬筆，對照的是每 10 次合併有 3 次失敗、31% 的程式碼未經測試就上線、只有 28% 的公司具備共用的代理控制措施。講者的解方——分層驗證、把品味寫進 Claude.md 與 agents.md、引導軌道、標記——是與廠商立場一致的處方；而 2027 年「帶有暗角落的明亮工廠」則是 Osmani 的判斷，不是實測趨勢。尚未化解的張力在於問責：兩人都堅持人類要為代理的產出負責，但他們描述的流程，卻把人的工作從讀程式碼轉為驗證代理提供的證據。這套證據標準在受監管產業的稽核下站不站得住腳，正是接下來 6 到 9 個月 PR 標記要回答的問題。