The Bun Rust Rewrite: AI Porting, Undefined Behavior, and the 'Vibe-Coding' Debate
最近關於 Bun runtime 被宣佈使用 agentic AI 重寫為 Rust 的消息引發了立即的興奮，但隨即也引發了一波技術審查。最近出現的一個 GitHub issue 揭露了新的代碼庫無法通過基本的 Miri 檢查，並且即使在「安全」的 Rust 中也會導致未定義行為 (Undefined Behavior, UB)。
這種情況已成為開發者社群中更廣泛辯論的焦點：利用 AI 驅動的大規模代碼庫移植 (porting) 是否是通往更好軟體的可行路徑，還是這是一種危險的「vibe-coding」趨勢，即為了速度和營銷噱頭而犧牲了嚴謹性？
The Technical Core: Miri and Undefined Behavior
爭議的核心在於對 Miri 的使用，它是 Rust 的中層中間表示 (MIR) 的解釋器。Miri 的設計目的是檢測未定義行為 (Undefined Behavior)——即 Rust 語言規範中未定義的操作，這些操作可能導致不可預測的崩潰、安全漏洞或靜默數據損壞。
在 Rust 中，語言的「安全」子集保證不會出現 UB。然而，當開發者使用 unsafe 塊來執行底層操作時（這在 Bun 等 runtime 中很常見），他們必須承擔確保維護安全不變量 (safety invariants) 的責任。Bun 倉庫中的這個 issue 顯示，AI 生成的移植版本暴露了即使從安全代碼中調用也會導致 UB 產生的 API。
正如一位社群成員所指出的，問題不僅僅在於 UB 的存在，而是在於未能正確封裝 unsafe 代碼：
"The issue isn't the existence of undefined behavior that miri would catch. The issue is exposing an API that allows undefined behavior from safe code... Temporarily in a porting stage incorrectly marking some unsafe functions as safe isn't a real issue [unless] they made an actual release with the code in this state."
Porting vs. Rewriting: A Crucial Distinction
許多反彈情緒源於對項目目標的誤解。雖然在公開討論中使用了「重寫」一詞，但幾位工程師認為這實際上是一個 port。
在 porting 過程中，目標是盡可能直接地將一種語言 (在此案例中為 Zig) 的邏輯翻譯成另一種語言 (Rust)。這通常會導致「非慣用性」代碼——看起來像 Zig 代碼的 Rust 代碼。支持這種做法的論點是，這可以快速將代碼庫帶入更強大的類型系統中，為隨後的迭代優化為慣用且安全的 Rust 代碼提供基礎。
然而，批評者認為，使用 LLM 進行一對一的翻譯是低效且冒險的。有些人建議，使用確定性的翻譯工具 (例如 c2rust) 會比 agentic AI 更安全，因為輸出結果會具有與輸入相同的保證，而不是像「vibe-coding」那樣可能引入原始 Zig 源碼中不存在的新且微妙的 bug。
The "Vibe-Coding" Controversy
Bun 的事件引發了關於 AI 在軟體工程中的角色的哲學衝突。一方是那些將其視為開發演進中必要實驗的人。
"It's a throw thing at the wall and see what sticks situation... LLMs will improve... Using LLMs in an agentic way will improve. So what happened here is a mess, but you gotta break a few eggs to make a souffle."
另一方則是擔心行業正在失去對工程嚴謹性的掌控。在沒有經過詳盡的人類審查的情況下合併一個百萬行 AI 生成的 diff，被一些人視為更大「AI 泡沫」的徵兆。
"I think the only way to interpret a one million line LLM-generated diff with no proper reviews... is that my company no longer has an interest in understanding, or even looking at, its own code."
Marketing vs. Engineering Reality
除了技術層面，還有對「華麗宣傳」文化的批判。高調宣傳的聲明 (例如，「Bun rewritten in Rust in two weeks」) 與糾正事實的 GitHub issue 之間的不對稱性，是公關關聯中常見的模式。
批評者認為，重寫的速度可能是一種營銷噱頭，而非技術里程碑。然而，支持者指出，只要穩定版本仍在使用 Zig，對用戶的風險就很小，且 Rust port 版本的開發可以作為對項目可維護性的長期投資。
Conclusion
Bun 的事件為當前 AI 能力的極限提供了一個案例研究。雖然 LLM 可以以驚人的速度生成大量代碼，但代碼的 驗證 仍然是瓶頸。正如社群觀察到的，當代碼產出率提高 100 倍時，驗證過程的 robustness 必須成比例地提高，以避免創建一個由未經驗證的邏輯構成的「怪獸」。