BunのRust書き換え：AI移植、未定義動作、および「バイブ・コーディング」論争

BunランタイムがエージェンティックAIを使用してRustで書き換えられたという最近の発表は、即座に期待を呼び起こし、その直後に技術的な精査の波が押し寄せました。最近、GitHubのIssueが浮上し、新しいコードベースが基本的なMiriチェックに失敗し、「安全な」Rust内であっても未定義動作（UB）を許容していることが明らかになりました。

この状況は、開発者コミュニティにおけるより広範な論争の火種となっています。大規模なコードベースの迅速なAI駆動による移植は、より優れたソフトウェアへの実行可能な道なのか、それとも、厳密さがスピードとマーケティング的な見栄のために犠牲にされる「バイブ・コーディング（vibe-coding）」への危険な傾向なのか？

技術的な核心：Miriと未定義動作

論争の中心にあるのは、Rustの中間表現（MIR）のインタプリタであるMiriの使用です。Miriは、未定義動作（Undefined Behavior）を検出するために設計されています。これは、Rustの言語仕様で定義されていない動作であり、予測不可能なクラッシュ、セキュリティの脆弱性、またはサイレントなデータ破損を引き起こす可能性があります。

Rustにおいて、言語の「安全な」サブセットは、UBが発生しないことが保証されています。しかし、開発者が低レベルな操作を行うためにunsafeブロックを使用する場合（Bunのようなランタイムでは一般的です）、彼らは安全性に関する不変条件を維持する責任を負います。Bunのリポジトリで提起された問題は、AIが生成した移植版が、安全なコードから呼び出された場合でもUBが発生することを許すAPIを露出させていることを示唆しています。

あるコミュニティメンバーが指摘したように、問題は単にUBが存在することではなく、unsafeなコードを適切にラップできていないことにあります。

"Miriがキャッチする未定義動作が存在すること自体が問題なのではありません。問題は、安全なコードから未定義動作を許すAPIを露出させていることです... 移植段階において、一時的に一部のunsafeな関数をsafeとして誤ってマークすることは、実際のリリースでその状態のコードを使用しない限り、本当の問題ではありません。"

移植 vs. 書き換え：重要な区別

反発の多くは、プロジェクトの目標に対する誤解から生じています。「書き換え（rewrite）」という言葉が公の議論で使用されましたが、複数のエンジニアは、これは実際には**移植（port）**であったと主張しています。

移植において、目標は、ある言語（この場合はZig）のロジックを別の言語（Rust）へ可能な限り直接的に翻訳することです。これはしばしば「非慣用的（unidiomatic）」なコード、つまりZigのコードのように見えるRustのコードをもたらします。このアプローチを支持する議論は、コードベースを強力な型システムに迅速に移行させ、その後に慣用的で安全なRustへと反復的に洗練させていくための基盤を提供できるというものです。

しかし、批判的な人々は、LLMを用いた一対一の翻訳は非効率でリスクが高いと主張しています。一部の者は、エージェンティックAIよりも決定論的な翻訳ツール（c2rustなど）の方が安全であっただろうと示唆しています。なぜなら、出力は入力と同じ保証を持つはずであり、「バイブ・コーディング」によって、元のZigソースには存在しなかった、潜在的で微妙なバグを新たに導入する可能性があるからです。

「バイブ・コーディング」論争

Bunの事例は、ソフトウェアエンジニアリングにおけるAIの役割をめぐる哲学的な衝突を引き起こしました。一方には、これを開発の進化における必要な実験と見なす人々がいます。

"これは、壁に何かを投げつけてみて、何がくっつくかを見るような状況です... LLMは改善していくでしょう... エージェンティックな方法でLLMを使用することは改善していくでしょう。スフレを焼くためには、いくつかの卵を割る必要があります。"

もう一方には、エンジニアリングの厳密さが失われつつあることを恐れる人々がいます。徹底的な人間によるレビューなしに、100万行のAI生成のdiffをマージすることの展望は、一部の人々にとって、より大きな「AIバブル」の兆候と見なされています。

"適切なレビューなしに、100万行のLLM生成のdiffを解釈する方法はただ一つです... 私の会社は、もはや、自社のコードを理解すること、あるいは見ることさえすることに興味がなくなっているということです。"

マーケティング vs. エンジニアリングの現実

技術的な側面を超えて、「派手な発表」文化への批判もあります。注目度の高い主張（例：「Bunは2週間でRustに書き換えられた」）と、事実を訂正する静かなGitHub Issueが示す非対称性は、PRにおける既知のパターンです。

批判的な人々は、書き換えのスピードが、技術的なマイルストーンではなく、マーケティング的な演出であった可能性を示唆しています。しかし、擁護派は、安定版がZigのままである限り、ユーザーへのリスクは最小限であり、Rustへの移植はプロジェクトの長期的な保守性を向上させるための長期的な投資であると指摘しています。

結論

Bunの騒動は、現在のAIの能力の限界を示すケーススタディとなっています。LLMは驚異的なスピードで膨大な大なコードを生成し得ますが、そのコードの検証がボトルネックとなります。コミュニティが観察したように、コードの生産速度が100倍になれば、検証プロセスが比例して強化されなければ、検証されていないロジックの「怪物」を生み出すことになります。