當寫程式碼不再是瓶頸，Code Review 正在發生什麼改變？
從 Software Factory 到 AI Factory，開發流程沒有被重新發明，但時間分配變了：AI 大幅壓低實作成本，人閱讀與驗證程式碼的速度卻沒有同步提升，瓶頸因此往下游移到 Code Review。
這個瓶頸的轉移，我也是最近才真正感受到。
今年 5 月初，透過愛好 AI 工程 Blog 的《AI 時代的 Code Review：當 Pull Request 成為新瓶頸》這篇文章整理，首次對於業界怎麼看 Code Review 有了粗淺的認識，但還沒有強烈感受到「自己就是瓶頸」。
直到最近這一個月，隨著模型和各種 agent harness 的進化，加上團隊開發流程轉換，躺在 Github 的 PR 越來越多，我才親身體會到，自己的理解力才是真正的瓶頸。
當人的理解力成為瓶頸，接下來的問題就是：哪些改動必須由人看？
天秤的兩端分別是：由人細看每一行被改動的程式碼，以及把 Review 完全交給 AI。
但我認為，現階段兩種極端都行不通。前者的速度跟不上。後者可能會讓錯誤的資料結構與設計持續累積複雜度，直到 AI 花在修 bug 的時間比添加新功能還多。
所以我的答案不是全部看，也不是完全不看。
人需要守住會讓複雜度擴散的設計決策，再根據修改的影響範圍和風險，決定其餘程式碼需要 Review 多深。
但要真正根據影響範圍與風險分配 Review 深度，還需要一套穩定的判斷方法。是否存在能做到這件事的確定性工具，是我正在研究的題目之一，或許有前輩或大神可以提供一些建議。
增加前期設計，仍然讀完每一行程式碼
關於這個挑戰，Dex Horthy 在《Harness Engineering Is Not Enough and Why Software Factories Fail》有給出答案：增加前期設計，讓團隊仍然可以讀完每一行程式碼。
我同意他指出的問題，但不完全同意他的解法。
這個分歧來自我們想達成的目標不同。我理解他的目標，是在合理的速度下追求長期品質。但這個解法有一個前提：團隊可以選擇用速度換取品質。
然而現實是，交付速度往往會受到商業面與其他因素影響，不完全由自己控制。
所以我更想做的是：守住品質底線後，盡可能提高速度。
不能把設計與審查完全交給 AI
不過，盡可能提高速度，不代表得把設計與審查完全交給 AI。
Dex 提到，模型的訓練與評估比較容易獎勵「問題有沒有解決、測試有沒有通過」，不好的架構卻可能幾個月後才產生成本。
而另一個逐步加入功能的實驗，Boundary 的《The Data Structure Problem AI Coding Agents Can’t See》也發現：即使測試一直是綠的，Agent 仍可能選擇會產生多個真相來源或無效狀態的資料結構。
這些問題不會立刻讓系統壞掉，而是讓後面的功能建立在錯誤的基礎上。每次只錯一點，複雜度仍會持續累積，最後花更多時間修復。
所以人仍然需要守住資料結構、系統邊界和核心設計。
根據風險調整 Code Review 深度
這個方向不是最近才出現的。
去年我看了 Anthropic 工程師 Erik Schulntz 的分享《Vibe Coding in Prod》。他主張讓 AI 自主處理低依賴的葉節點，核心節點則由工程師深入理解。
同一套概念也能用來決定人需要投入多少 Code Review。
不過，只看依賴度還不夠。安全性、資料庫變更、公開 API 和關鍵業務邏輯，即使依賴度不高，仍可能需要嚴格審查。低風險修改以測試、自動化檢查和結果驗收為主；高風險修改才投入更多時間細看程式碼和架構。
重點不是少做 Review，而是把有限的注意力放在最可能出問題、也最難回復的地方。