最近看 AI coding agent 的產品方向，我有一個越來越強烈的感覺：這條路線的下一個戰場，可能不是「模型又變得多會寫 code」，而是「人類怎麼監工」。
這句話聽起來有點掃興。畢竟大家比較愛看 demo：一句話生出功能、自己跑測試、自己修 bug、自己開 PR。很帥，我也喜歡。但真的要把它放進日常開發流程，帥不帥反而不是第一個問題。第一個問題是：它做錯事的時候，誰知道？它要動到危險地方的時候，誰批准？它卡住的時候，誰接手？
以前我們問「AI 會不會寫」，現在要問「AI 能不能被管」
過去一年多，coding assistant 的主旋律大概是能力展示。補完、重構、產生測試、讀 repo、修 issue，大家都在比誰比較像一個 junior developer，甚至像一個不用睡覺的 senior developer。
但從技術主管的角度看，我其實不太在意它偶爾秀一段神操作。真正讓我在意的是它能不能穩定地放進流程裡。
一個 AI coding agent 如果只能在我盯著螢幕時工作，那它比較像一個很聰明的 IDE 外掛。好用，但還不是團隊成員。要變成團隊工作流的一部分，它至少要具備幾件事：任務可以排隊、進度可以查看、關鍵動作需要批准、結果可以驗收、失敗可以追蹤。
也就是說，AI coding agent 的成熟度不只在模型，而在「管理介面」。這有點像以前我們導入 CI/CD。大家一開始會覺得重點是自動 build、自動 deploy，後來才發現真正困難的是權限、環境隔離、rollback、audit log、誰可以按 production deploy 那顆按鈕。
AI coding agent 也是同一種問題，只是它的行動範圍更模糊、更像人，所以治理成本更高。
手機監看不是噱頭，是工作流位置改變
我以前對「手機上監看 agent」這類功能其實有點冷感，心裡會想：工程師不是本來就該在電腦前嗎？但後來想一想，這個方向真正有意思的地方，不是手機，而是它暗示 agent 正在變成一種背景工作。
如果一個任務可以丟給 agent 跑二十分鐘、一小時，甚至半天，中間只在需要判斷時叫我，那操作介面就不一定非得是 IDE。它比較像 CI pipeline、雲端 build、或一個排程任務。你不會一直盯著它跑，但你需要在關鍵節點收到訊號。
例如：
- 它準備修改資料庫 migration，要不要批准？
- 它想刪除一批看似沒用的檔案，要不要批准？
- 它測試失敗三次，是否要改策略？
- 它找到兩種修法，需要人決定偏好的架構方向。
這些不是「寫程式能力」問題，而是「決策交接」問題。好的 agent 工作流，不應該假裝人類不存在；它應該知道哪些事情可以自己做，哪些事情必須停下來問。
這也是我覺得很多 AI 工具 demo 容易誤導人的地方。Demo 裡最漂亮的是一路自動完成，但真實世界最有價值的，常常是它在正確的地方停下來。
沙盒不是保守，是讓速度變快的前提
講到 coding agent，就一定會碰到 sandbox。這東西很無聊，沒有 demo 效果，但我越來越覺得它是必要條件。
如果 agent 可以讀 repo、改檔案、跑指令、裝套件、甚至操作瀏覽器，那它其實已經拿到一個工程師工作站的部分能力。這時候你不能只靠「模型應該會乖」來管理風險。抱歉，這聽起來就像把 production 資料庫密碼貼在桌面，然後相信大家都不會亂按。
沙盒的目的不是把 AI 綁死，而是把「可以放心讓它跑」的範圍劃出來。
我比較喜歡把它想成幾層邊界：
- 檔案邊界：哪些目錄可讀、哪些可寫、哪些完全不能碰。
- 指令邊界：哪些 command 可以直接跑，哪些需要批准。
- 網路邊界：能不能打外部 API、能不能下載依賴、能不能送出資料。
- 機密邊界：token、key、客戶資料、內部文件是否被隔離。
- 版本邊界：所有變更都要能 diff、能 revert、能追蹤來源。
有了這些邊界，我反而更敢放手。因為我知道它就算犯錯，也會被限制在可承受的區域內。沒有邊界的自動化，短期看起來跑很快，長期一定讓人不敢用。
Approval flow 會變成 AI 開發工具的核心體驗
我現在看 coding agent 產品，會特別注意它怎麼處理 approval。不是因為我愛流程，而是 approval flow 決定了人與 AI 的分工品質。
太鬆，危險。太緊，煩死。每個小動作都跳出來問你，最後你只會變成橡皮圖章，一路按同意；真正危險的事情反而被淹沒在通知裡。
好的 approval flow 應該要有分級。
像是讀檔、搜尋、跑單元測試，通常可以自動。修改核心模組、安裝新依賴、變更 CI 設定，就應該提高警戒。碰到資料刪除、權限設定、部署、對外發送，則一定要明確批准，而且要附上足夠脈絡：它為什麼要做、替代方案是什麼、不做會怎樣。
這裡的重點不是按鈕，而是「可判斷性」。如果 agent 只丟一句「需要批准執行某某指令」，我還是得自己猜風險。比較好的做法，是它把意圖、影響範圍、回滾方式一起講清楚。
換句話說，AI 不只要會做事，也要會寫變更申請。這很現實，也很企業。
Agent 要進團隊，就要接受團隊規矩
我常覺得，大家談 AI coding agent 時，會不小心把它當成一個超能力個體。但在團隊裡，個人能力從來不是唯一標準。
一個再強的工程師，如果不寫 commit message、不開 PR、不跑測試、不交代設計取捨、不接受 code review，團隊也很難長期跟他合作。AI 也是一樣。
所以我期待的 coding agent，不是那種「你睡醒它已經偷偷幫你改完 production」的幻想。那聽起來不像未來，像事故報告的前言。
我期待的是它像一個很可靠的 async teammate：我可以派任務給它，它會自己探索、整理方案、提出修改、跑驗證；遇到超出權限的事情會停下來；完成後給我一份可以 review 的結果。它不需要假裝自己是人，但它必須尊重團隊工作的規矩。
這也是為什麼我覺得 AI coding agent 的下一步，不是單純更會寫，而是更好被監工。
真正能落地的 AI 工具，不會只讓人驚呼「它居然做得到」。它還要讓技術主管放心地說：「好，這個我敢交給它。」
差別很大。前者是 demo，後者才是生產力。