把八十萬行程式碼交給 AI 之後，誰負責證明它沒變質？
看到 GitHub 用 Copilot 協助把 Copilot agent runtime 從 TypeScript、Node 與 V8 改寫成超過 80 萬行 production Rust，我第一個反應不是「AI 寫了好多程式」，而是：這個系統到底要維持哪些不成文的契約？
這個案例最值得看的地方，不是幾個月完成，也不是 agents 產生了大部分程式碼，而是交付方式。團隊把工作切成 128 個 PR，持續整合，同時修正數十個 regression。換句話說，AI 提高的是 implementation bandwidth，並沒有自動提高 verification bandwidth。前者解決「能不能把新版本寫出來」，後者才解決「新版本是不是仍然等價」。
嚴格來說，runtime migration 不是把每個 function 翻成另一種語言。它更像是在搬運一組散落在程式碼、測試、CI、錯誤處理和使用者習慣裡的行為規格。文章提到的問題很有代表性：migration incomplete 會漏掉路徑，state 與 lifetime 會改變資源的存活時間，behavioral contract mismatch 會讓看似合理的輸出破壞既有依賴，host boundary 則會暴露不同執行環境的差異。這些都不是 syntax 或 type checker 能完整捕捉的錯誤。
我會把這類 AI 輔助重寫拆成四個驗證問題。第一，功能是否存在，避免只完成主流程。第二，狀態轉移是否相同，尤其是取消、重試、逾時與部分失敗。第三，外部可觀察行為是否相同，包括輸出格式、錯誤訊息、順序和資源使用。第四，測試本身是否真的能辨識錯誤，而不是只把新實作當成答案。最後一項最容易被忽略，也就是 test oracle 問題：如果測試只驗證「程式有回應」，它可能根本沒有驗證「回應正確」。
這也解釋了為什麼增量整合和人工 review 仍然重要。小 PR 不只是方便審查，更是在縮小每次變更的因果範圍；CI 不只是跑綠燈，而是把隱藏契約變成可重複執行的證據；人工 review 的價值也不只是找 typo，而是追問「這個行為在舊系統裡是不是有被依賴」。
所以，AI 時代的工程瓶頸可能會從寫程式轉移到定義正確性。當生成成本接近零，真正稀缺的是好的 oracle、完整的 regression corpus，以及知道哪些差異不能接受的人。Port 很容易，證明沒有悄悄改變世界，才是難題。
作者：陳思維