現在談 AI coding agent，很容易把焦點放在「它能不能自己寫完整功能」。這個問題當然重要，但我覺得下一個更現實的瓶頸不是寫得不夠快，而是寫太快之後，誰來驗收。

過去工程團隊的產能，常常卡在寫程式的人不夠。現在 agent 可以開分支、讀 codebase、改檔案、跑測試、補文件，等於把「產出草稿」的成本大幅壓低。問題是，草稿變多不等於交付變快。PR 變多、差異變大、上下文變散，如果 review 流程沒有升級，團隊只是把瓶頸從 coding 移到驗收。

這裡有一個常見誤解：只要 agent 寫得越準，人類就能少看一點。實務上剛好相反。越有能力的 agent，越可能一次碰到更多檔案、跨過更多模組、做出看似合理但其實改變產品語意的決策。小錯誤不一定在語法，常常藏在邊界條件、權限假設、資料遷移、錯誤處理與相容性裡。這些不是單看測試綠燈就能完全放心的地方。

所以導入 coding agent 時，不該只問「哪個模型最會寫」。更該先問四件事：第一，哪些任務只允許 agent 產生草稿，不能自動合併？第二，PR 是否要求附上設計意圖、風險點與驗收方式？第三，測試失敗、格式變更、依賴更新、權限相關修改，能不能被自動標記出來？第四，誰對最後合併負責，而不是讓責任消失在「AI 幫我改的」這句話裡？

比較健康的做法，是把 agent 當成高產出的 junior pair，而不是免 review 的替身。適合先放給它做的，是可回滾、可測試、範圍清楚的工作：補單元測試、重構小函式、修明確 bug、更新文件、把重複程式碼整理成既有模式。比較不適合一開始全放手的，是付款、權限、資料刪除、資安、核心商業邏輯與大規模架構遷移。

對管理者來說，真正的採用指標也要改。不要只看 agent 產生多少行程式碼、開了多少 PR，而要看 review lead time 有沒有下降、回滾率有沒有上升、缺陷是否集中在某些任務類型、工程師是不是花更多時間在讀不信任的 patch。如果驗收成本比產出節省更多，那不是自動化，是把技術債包成效率報表。

結論很簡單：AI coding agent 會讓寫 code 變便宜，但會讓判斷變更珍貴。下一階段真正有競爭力的團隊，不是讓 agent 寫最多 code 的團隊，而是最早把驗收流程產品化的團隊。先建立任務分級、PR 範本、測試門檻、風險標籤與人類責任邊界，再放大 agent 權限。寫得快只是開始，驗得住才是產能。