現在很多團隊導入 AI coding agent，第一個反應是把整個 repo 丟給它，然後期待它像資深工程師一樣自己讀懂架構、修完 bug、補測試、順手整理技術債。這個期待很爽，但通常也是踩坑開始。

比較務實的判斷是：AI coding agent 適合被當成「有工具權限的 junior pair」，不適合一開始就被當成「可以放養的 maintainer」。

它真正有價值的地方，不是讓你不用看程式，而是把明確、可驗收、低副作用的工程工作變快。例如修一個 isolated bug、補一組 regression test、改一個小元件樣式、把重複邏輯抽成既有專案風格的 helper、根據錯誤 log 找到最可能的修改點。這些任務邊界清楚，做完也容易 review。

最不適合的導入方式，是一句「幫我優化這個專案」加上全 repo 寫入權限。因為 agent 會很努力，但它的努力不等於方向正確。它可能改到不該碰的檔案、順手重構沒有測試保護的區塊、把局部問題修成全域行為變更，甚至為了通過測試而把測試改弱。這些都不是模型笨，而是任務設計太鬆。

導入時最好先做三件事。

第一，縮小工作區。讓 agent 先處理單一 issue、單一模組、單一測試失敗，而不是開放式巡田水。任務描述裡要寫清楚哪些檔案可以改、哪些行為不能動、成功標準是什麼。

第二，先要求它解釋計畫再動手。不是要它寫長篇報告，而是確認它知道 bug 可能在哪、打算改哪裡、會跑哪些測試。這一步可以攔掉很多「看起來很勤奮但其實亂衝」的修改。

第三，把驗收自動化。AI coding agent 最怕的是人類只看 diff 直覺覺得合理。最低限度要有 formatter、lint、unit test；稍微成熟一點，還要有 smoke test、type check、snapshot 或端到端測試。沒有驗收，agent 的速度只是把不確定性更快送到 PR。

誰適合現在導入？已經有基本測試、CI、code review 習慣，而且有很多小型維護任務的團隊。這種環境下，agent 可以變成很實際的產能放大器。

誰不適合急著導入？測試很薄、架構沒有邊界、需求常靠口頭補充、review 也只是看能不能跑的團隊。這時候 agent 不是不能用，但最好先用在讀碼、產生候選修法、補文件與補測試，而不是直接交付 production change。

我的一句判斷是：AI coding agent 的採用重點不是模型多強，而是你有沒有把 repo 變成它可以安全工作的場地。 先把任務切小、權限收窄、驗收補上，它會很有用；反過來，一開始就讓它在整個 codebase 裡自由發揮，省下的時間很容易加倍還在 debug 和 rollback 上。