看完 Bun 用 Claude Fable 跑大約 11 天、跑了 50 個左右的 dynamic workflows，把 535,496 行 Zig 全部重寫成 Rust，我的第一反應真的很震撼。

但震撼過後，我一直盯著一件事看：他們的 test suite 是從哪來的？

原來 Bun 在做這件事之前，就已經有一個 language-independent 的測試套件，可以跨語言驗證行為是否一致。也就是說，整個 rewrite 背後是有一個「標準答案」在撐著的，1 個負責實作的 implementer 搭配 2 個 adversarial reviewers 互相對抗，確保每一步都能被驗證。

光是看到這個架構，我就已經開始覺得不對勁了。

真正讓我冷汗直流的部分

上個月我在公司接了一個小任務，要把一段舊的 Python script 改成用 agent 自動處理，大概是把幾個 API 的呼叫流程重新串一遍。我直接丟給 agent 說「幫我重寫這段邏輯」，跑出來看起來很順，我就 merge 了。

然後隔天就爆了 QQ

問題在哪？那段 script 裡有一個邊界條件，原本的邏輯在某些 response 格式會做 fallback，但 agent 重寫的版本直接省掉了那個 fallback，因為「看起來不重要」。我沒有測試這個邊界，因為我連那個邊界在哪都不確定。

回頭看 Bun 那篇文章說的，他們光是 API 費用估計就花了大約 165,000 美元，跑了 5.9B uncached input tokens，72B cached reads。這種規模的事情，如果沒有嚴密的測試框架在底下撐著，根本不可能做。

但我連一個幾十行的 migration script 都沒測齊，就想把 agent 放大。

沒有驗收標準的 rewrite，看起來成功才是最危險的

我現在最怕的情境不是 agent 跑出錯誤，而是跑出一個「看起來對」的結果。

因為錯誤很好處理，你會看到報錯，會去 debug，會找到問題。但「看起來對」的結果，你不知道它在哪個 edge case 會爆，可能是一個月後，可能是流量突然大起來的時候，可能是某個使用者做了一個你沒預期的操作。

Bun rewrite 能成功，是因為他們在開始之前就定義好「什麼叫做成功」，有語言無關的測試套件當作基準，有 adversarial reviewer 專門想辦法找漏洞。這不是 AI 的功勞，這是工程紀律的功勞，AI 只是執行的手。

我自己踩坑過之後才真的體會到：你給 agent 的任務範圍，跟你能驗證的範圍，這兩個要匹配。任何時候 agent 的操作超出你能驗證的邊界，你就是在賭。

也許你賭贏了，也許會像我一樣隔天早上看到 Slack 通知說 production 出問題了 😅

所以我現在的習慣

在讓 agent 動任何現有 code 之前，我會先強迫自己回答三個問題：

1. 這段 code 的「正確行為」，我能不能用一個 test 寫下來？
2. 有沒有 edge case 是我現在不確定的？那這個 edge case 在 agent 重寫後要怎麼驗？
3. 如果 agent 的輸出看起來對，我要怎麼知道它真的對？

答不出來的話，就不要動。先補測試，再讓 agent 跑。

這三個問題問下來，我大概有一半的時候會發現自己根本沒準備好。這很正常，菜就多練，但至少要知道自己菜在哪。

---

Bun rewrite 是很精彩的案例，值得認真讀，但讀完要帶走的不是「AI 厲害可以重寫 53 萬行」，而是「在 scale up 之前，你的 test suite 在哪」。

這個問題我現在每次 commit 前都會問自己一遍，雖然有時候答案還是「欸，不夠齊」QQ