Agent 寫得飛快，人類真的驗得完嗎？
先講結論，Agent 寫得飛快，人類真的驗得完嗎？
看到 Nokia 用 Cursor 重做 SDLC 那張卡，5,000 萬行混合 codebase，原本要 12 位以上專家花數月做 decomposition analysis，後來變成 2 位工程師 2 週完成，部分流程還有約 80% 自動化。數字很香，香到有點像簡報最後一頁會出現的那種數字 XD
先把前提講清楚，這些是 vendor 或 customer 的估計，不是獨立稽核。我不會因為這樣就說案例不可信，工程團隊自己最知道哪裡省到時間。但這個案例真正值得看的地方，不是 Cursor 產生 code 的速度，而是監督工作突然變成新的瓶頸。
以前 decomposition 慢，至少大家知道慢在哪裡。專家把系統切開，開會吵依賴關係，留下設計文件，最後有人簽名。現在 Agent 可以很快吐出一份看起來合理的分析，問題變成，人要怎麼確認它真的讀懂了 5,000 萬行，而不是把命名、資料夾和幾個熱門 pattern 拼成一篇很像樣的作文。
我之前看過一個小型服務的重構，只有大約 18 個 endpoint，Agent 兩小時就畫出 dependency map，還順手提了 27 個可拆的模組。人看完覺得有料，照著做，第三天測試才發現其中一條付款失敗的 fallback 會繞過 audit log。那條路徑平常幾乎不走，所以靜態閱讀很難抓，真正有用的線索反而是 production log 裡一個很不起眼的 error code。
這種坑很說明問題。Agent 的輸出能不能用，不該只看它講得順不順，而要看推論能不能被驗證。我的做法會把 agentic SDLC 的驗證拆成四層，沒有四層都過，速度數字先當參考就好。
第一層，證據驗證
Agent 每提出一個結論，都要能回到 repository 的具體證據。不是只說「這個模組負責付款」，而是列出檔案、function、呼叫者、測試案例，以及它引用的 commit 或 log。
可以要求輸出固定格式，例如：
claim: payment fallback writes audit event
evidence: src/payment/fallback.ts:41
callers: checkout.ts:88, retry-worker.ts:122
tests: test/payment/fallback.spec.ts
confidence: low
unknowns: production flag PAYMENT_RETRY_V2
重點不是格式很漂亮，而是 reviewer 能不能在 10 分鐘內抽查 5 個 claim。抽查時如果每個 claim 都要重新問 Agent「你為什麼這樣想」，那就沒有 traceability，只有聊天紀錄而已。
我會特別抽查低 confidence 和沒有測試對應的項目。高 confidence 反而可能是最危險的地方，因為人容易看到肯定語氣就放下戒心。confidence 應該是風險標記，不是正確率保證，這點很多團隊會搞混。
第二層，反例驗證
只驗證 Agent 找到的 happy path 不夠，因為它通常很會沿著現有命名走。每一個重要推論至少要問三個反例。
例如它說「這個 API 可以無狀態水平擴充」，就要測：
- 同一個 user 的請求被送到不同 instance 會怎樣
- cache 過期和重試同時發生會怎樣
- 第三方 timeout 後，重送是否造成 duplicate side effect
它說「這些模組可以獨立部署」，就要反問資料庫 schema migration、feature flag、rollback、舊版 client。很多 decomposition analysis 只切 code，不切責任和失敗模式，切完架構圖很漂亮，值班的人卻不知道出事要找誰。
這裡可以把 Agent 當反方使用。第一輪請它提案，第二輪清空第一輪的結論，改給它風險清單，要求找出反例。兩輪結果如果完全一致，我反而會提高警覺，因為那可能代表它只是在重述自己。
第三層，行為驗證
分析不是產品，最後還是要跑。對每一個改動，至少留下原始行為、預期行為、實際行為三欄。測試數量增加不代表驗證變好，因為 Agent 很容易補出一堆只驗證 mock 的測試。
我會看三個數字：
- change failure rate，部署後需要回滾、hotfix 或人工介入的比例
- recovery time，失敗後恢復到可服務狀態的時間
- escaped defect，測試和 staging
都沒抓到，最後在真實流量出現的問題數
假設 cycle time 從 30 天降到 8 天，但 change failure rate 從 4% 升到 18%，recovery time 又從 40 分鐘變成 6 小時，這不是交付變快，是把排隊時間換成事故時間。反過來，如果 cycle time 只降到 20 天，failure rate 維持 4%，recovery time 降到 15 分鐘，可能才是比較健康的自動化。
這也是為什麼 Nokia 案例裡提到的 cycle time、change failure rate、recovery time 要放在一起看。單看 80% 自動化，跟單看 Agent 產出幾行 code 一樣，都是很容易被拿去做行銷的單點指標。
第四層，責任邊界驗證
最容易被漏掉的其實是責任。Agent 可以提出 decomposition，也可以開 PR，但誰對資料遷移、權限、資安、SLA 和 rollback 負責？「人類在 loop 裡」這句話太模糊了，人在什麼節點、看了什麼證據、擁有什麼否決權，才是能不能追責的差別。
我會在每個高風險變更旁邊寫一張小小的 decision record：
- Agent 做了什麼推論
- 哪位工程師審查了哪些證據
- 哪些未知被接受
- 失敗時誰有權 rollback
- 什麼條件出現時必須重新審查
尤其是權限、付款、資料刪除、schema migration，不能用「Agent 建議，人類同意」帶過。這跟實習生寫 code 完全不是同一種管理方式，因為 Agent 一次可以把責任模糊的變更散到十幾個服務，最後每個人都只看自己那一小段。
真正可執行的 gate
如果要把上面四層放進日常流程，我會用一個很俗但有效的 gate。每個 Agent PR 都必須附上 claim list、evidence link、反例結果、測試結果、rollback plan。高風險 PR 再加人工 approval，且 approval 不能只按綠色按鈕，要勾選自己實際檢查過的範圍。
可以先用 2 週做 pilot，選 20 個 PR，記錄每個 PR 的：
- Agent 花費時間
- 人類 review 花費時間
- claim 抽查失敗數
- 測試漏抓數
- 上線後修正時間
我猜很多團隊跑完會發現，Agent 省掉的不是所有工程時間，而是把時間從寫初稿搬到驗證。這沒有不好，至少驗證是比較接近品質的工作，但管理層要承認這個轉移，不能拿 code generation 的速度直接當成 SDLC throughput。
還有一個很現實的反例。假設某個團隊因為 Agent 很快，兩週內合併 100 個 PR，卻只有 1 位 reviewer。另一個團隊兩週合併 35 個 PR，但每個高風險變更都有獨立反例測試和 rollback 演練。前者在 demo 上一定比較亮眼，後者比較可能在半年後還活得好好的。工程不是比誰把更多變更塞進 production，還要比誰能知道自己為什麼敢塞。
所以我看 Nokia 這個案例，重點不會下在 Cursor 讓 2 個人做出 12 個人的工作。比較精準的說法是，工具把 decomposition 的初始成本壓低了，接下來團隊必須投資在 evidence、counterexample、runtime metrics 和 ownership。這四個東西做不起來，Agent 越快，未知就累積越快。
最後留一句給跟風導入 Agent 的團隊。先不要問它一天能寫幾行 code，先拿一個你們已經熟悉、而且有歷史事故紀錄的服務做盲測。把舊版分析交給 Agent，要求它列出證據和不知道的地方，再用既有 incident report 對答案。若它只答對 happy path，卻漏掉最常出事的那三條路徑，你們缺的不是更大的 context window，是更嚴格的驗證制度。
Agent 寫得快是能力，能讓人類快速知道它哪裡可能錯，才是工程系統。前者很適合做 demo，後者才值得拿去承擔 production。這句可能有點老派，但至少出事時，值班的人還知道要找誰，笑死。
作者：島民No.9527