AI Coding Agent 不會取代你，但會無情放大你程式碼的所有缺點。這是這一兩年下來，開發圈逐漸形成的共識。從早期的補全工具，到現在能自主閱讀 repo、規劃步驟、開 PR 的代理型工具，AI 已經深入日常開發流程。熱鬧之餘，值得冷靜看看它到底改變了什麼、又沒改變什麼。
從「補全」到「代理」的分水嶺
過去的 AI 編碼工具，本質上是加強版的自動完成：你打字，它猜。近期主流工具則往「代理」方向走——給它一個任務描述，它會自己讀檔、跑指令、寫測試、必要時開 PR。差別不只在自動化程度，而在於決策權轉移。工具開始替你選擇「先改哪個檔」「該不該重構這段」。
這意味著幾件事：
- 你的 codebase 品質直接決定 AI 的產出品質。命名混亂、耦合嚴重、缺乏測試的專案，AI 進去只會製造更多技術債。
- README、型別註記、註解不再只是給人看的。它們是餵給代理的上下文，寫得好等於直接提升工具效率。
- Code Review 的角色從「抓 bug」轉向「守住架構意圖」。因為 AI 產出的程式碼通常能跑，但未必符合你系統長期演進的方向。
舉個例子（示意情境，非真實案例）：假設一個中小型電商團隊接了一個新的金流串接需求。若專案本身模組邊界清楚、有完整的整合測試，AI 代理可以在很短時間內完成骨架、補測試、跑通 CI；但如果金流邏輯散落在多個 Controller 裡、狀態靠全域變數傳遞，AI 反而會產出一堆看起來合理、實際上加劇混亂的補丁。
決策者該關心的不是「用哪個模型」
模型會一直換，工具會一直迭代。真正決定 AI 能否幫上忙的，是幾件無聊但關鍵的事：
1. 程式碼可讀性優先於聰明。 AI 代理讀你的專案跟新進工程師一樣，靠命名與結構理解意圖。愈「炫技」的寫法，愈容易讓 AI 誤判。
2. 測試是護欄，不是裝飾。 讓 AI 自主修改程式碼的前提是你有辦法快速驗證它沒改壞東西。整合測試與端對端測試的價值在這個時代明顯上升。
3. 權限與稽核要提前想。 代理型工具能執行 shell、能推 commit、能呼叫外部 API。哪些操作要人工核可、哪些可以放行、log 怎麼留，這些屬於治理層面的問題，不能等出事再補。
下面是一段最小示意，說明如何在 CI 中為 AI 產生的 PR 加一層自動檢查：
# 示意：實際設定請依團隊 CI 工具調整
on:
pull_request:
types: [opened]
jobs:
ai-pr-guard:
if: contains(github.event.pull_request.labels.*.name, 'ai-generated')
steps:
- run: ./scripts/run-full-tests.sh
- run: ./scripts/check-architecture-rules.sh
關鍵不在腳本本身，而在「AI 產出走一條更嚴格的檢查通道」這個設計決策。
我們的觀察
這波熱潮真正的價值，不在於「用 AI 寫更多程式碼」，而在於它逼團隊面對長年沒解決的基本功——邊界清楚的架構、能跑的測試、寫得清楚的文件。我們在跟客戶討論導入時，通常會建議先花時間把這些基礎補起來，再談代理化，否則往往是把混亂加速、把技術債複利化。工具會繼續變，但這件事短期內看不到會被跳過的可能。