背景

Ladybird 瀏覽器創辦人 Andreas Kling 宣布，該專案決定放棄原有的 C++ 並正式轉向 Rust 語言，首個目標是將 JavaScript 引擎 LibJS 移植至 Rust。這項決策最引人注目之處在於其開發流程：開發團隊利用 Claude Code 與 Codex 等 AI 代理工具，在短短兩週內完成了兩萬五千行程式碼的遷移，並達成與原 C++ 版本位元級一致的輸出結果。

社群觀點

針對 Ladybird 轉向 Rust 的決定，Hacker News 社群展開了激烈的辯論，焦點集中在「語言頻繁更換」與「AI 輔助重寫」兩大議題。部分評論者對此表示擔憂，認為專案在短時間內從 C++ 轉向 Swift，現在又轉向 Rust，這種反覆的技術選型可能預示著專案缺乏長遠規劃，甚至可能陷入「重寫陷阱」。根據軟體工程的經典理論，大規模重寫往往會導致開發停滯，甚至成為專案走向終結的前兆。然而，支持者反駁指出，Ladybird 並非一般的商業新創公司，其開發節奏與 Linux 或 PHP 等開源專案類似，透過不斷重構來提升品質是常態，且瀏覽器作為處理網路不信任內容的第一線，追求記憶體安全是絕對的剛需。

關於 AI 代理在這次遷移中扮演的角色，社群展現了高度的興趣與分歧。許多資深開發者認為這是一個里程碑，證明了 AI 能夠將原本需要數月的枯燥移植工作縮短至兩週，這種「人機協作」的模式——由人類負責架構設計與審核，AI 負責執行具體轉譯——被視為未來軟體工程的新常態。有留言者將此稱為「代理工程」，認為這能極大地釋放高階工程師的生產力。但也有人提醒，這種由 AI 從 C++ 直接轉譯過來的 Rust 程式碼，往往帶有濃厚的 C++ 風格，並非道地的 Rust 實作，未來在清理這些技術債、使其符合 Rust 所有權模型時，可能會遇到隱藏的架構挑戰。

此外，社群也討論了 Ladybird 與其他專案如 Servo 的關係。儘管有人質疑為何不直接採用現成的 Servo 引擎，但多數觀點認同 Ladybird 追求「全自主開發」的哲學。這不僅是為了增加瀏覽器市場的多樣性，也是為了避免對特定第三方函式庫的過度依賴。雖然有人批評這是「非我所創症候群」（NIH Syndrome），但對於一個旨在打破 Chrome 與 Safari 壟斷的專案來說，擁有完全掌控的技術堆疊被認為是合理的策略。整體而言，社群雖然對頻繁更換語言感到不安，但對於 AI 展現出的驚人效率以及 Rust 帶來的安全性提升，多抱持著謹慎樂觀的期待。

延伸閱讀

• Things You Should Never Do, Part I：Joel Spolsky 撰寫的經典文章，探討為何從頭重寫軟體通常是個錯誤的決定。
• FluxFeed：由社群成員分享，利用 AI 輔助開發的 Rust RSS 閱讀器專案。
• The Ralph Wiggum Loop：一種描述 AI 代理在自動化開發中不斷嘗試錯誤並修正的循環模式。