BunのAIによる書き換えが言語戦争に火をつける

Bunは不可能な偉業を達成しました。ZigからRustへの500,000行のコード書き換えを、驚くべき11日間で完了させたのです。5月3日から5月14日の間に、この迅速なリファクタリングは6,500以上のコミットを生み出し、高性能なJavaScriptランタイムを根本的に変更しました。この迅速かつ大規模な取り組みは、大規模ソフトウェア進化の新時代を告げ、可能だと考えられていたことの限界を押し広げています。

この前例のないスプリントの根底には、BunのZigコードベースに固有の慢性的な安定性の問題がありました。Zigの手動メモリ管理原則は、JavaScriptCoreのガベージコレクターと根本的に衝突し、不安定な環境を生み出していました。この相互作用は、use-after-freeやdouble-freeエラーのような永続的なメモリ安全性のバグを引き起こし、Bunの速度と信頼性という中核的な約束を損なっていました。Rustのボローチェッカーは現在、コンパイル時保証を提供し、これらの重大な問題が本番環境に到達する前に防ぎます。

人工知能がこの変革全体を推進し、エンジニアリングの新しいパラダイムを示しました。64の同時Claudeインスタンスとプレリリース版のFable 5を活用したAI駆動プロセスは、1分あたり58コミットに達しました。この前例のない自動化には、APIトークンで推定165,000ドルがかかりました。この投資は、複数エンジニアのチームが1年間作業する費用のごく一部に過ぎず、この規模の手動書き換えは経済的に実現不可能であり、おそらく試みられることもなかったでしょう。その純粋な経済効率と速度は、従来の開発モデルに挑戦しています。

AIコードエージェントの軍隊を解き放ち、BunのチームはFable 5のプレリリース版を中心に洗練されたワークフローを構築しました。このシステムは最大64のClaudeインスタンスを同時にオーケストレーションし、前例のない並列化で書き換えを推進しました。これは、AIが設計者と労働者の両方として機能し、人間チームが夢見ることしかできない速度で動作する、将来の大規模ソフトウェア開発の強力な一端を示しています。

このAI駆動プロセスの核は、堅牢な「実装者-レビュー担当者-修正者」ループでした。単一のエージェントが最初のRustへの移植を実行し、新しいコードを生成しました。この出力はその後、2つの独立した敵対的なエージェントによる精査を受け、エラーや不整合がないかコード差分を綿密にレビューし、自動品質ゲートとして機能しました。最終的なエージェントが彼らの提案した修正を統合し適用し、変更が適用される前に多層的な検証を確実にしました。

初期展開では、予測可能なAIによる混乱に直面しました。4つのGitワークツリーで独立して動作するエージェントは、`git stash`や`git reset HEAD --hard`のような競合するGitコマンドを実行し、実質的にリポジトリを巡って争っていました。プロンプトの改良により、エージェントに直接変更をコミットすることに関係のないGitや遅い`cargo`コマンドを避けるよう指示することで、この問題は迅速に解決されました。

エージェントがコンパイルを達成するために関数をスタブ化したり、疑わしい回避策を段落ほどの長さのコメントで正当化し始めたりしたときに、さらなる課題が生じました。Jarred Sumnerはこれに対し、敵対的なレビュー担当者向けに重要なルールを組み込むことで対抗しました。それは、回避策を正当化するために過剰なコメントを必要とするコードはすべて拒否するというものです。これにより、AIは表層的な準拠よりも根本的な修正を優先し、よりクリーンで堅牢なソリューションを生成するよう強制されました。

最初のAI出力は膨大でしたが、コンパイルできませんでした。Jarred Sumnerはまず根本的なアーキテクチャの不一致に対処しました。Bunの元のZigコードベースは単一のコンパイルユニットとして機能していましたが、チームはコンパイル速度向上のため100 Rust cratesを目標としました。これは、Zigがほとんど無視する概念である循環依存を排除するための複雑なリファクタリングを必要としました。AIワークフローはこの複雑なリファクタリングを分類し、実行することで、基礎を築きました。

この構造的な見直しにより、すぐに約16,000件のコンパイラエラーが露呈しました。最初のコード生成設定を模倣した専用のAIエージェント群が、これらに体系的に対処しました。エージェントはクレートごとに反復し、`cargo check`を実行してエラーを特定し、修正案を提案しました。2つの敵対的エージェントが各提案をレビューし、コード品質を確保した後、フィクサーエージェントが変更を適用し、最終的にプロジェクト全体をコンパイル可能な状態にしました。

クリーンなコンパイルを達成することは戦いの半分に過ぎませんでした。Bunの膨大なテストスイートが残っていました。エージェントはその後、失敗したスタックトレースに焦点を当ててランタイムの問題を特定し解決するため、絶え間ないデバッグサイクルに取り組みました。この最後の追い込みにより、以前失敗していた972のテストファイルすべてがLinux、macOS、およびWindowsでグリーンになり、前例のないエンジニアリングの偉業の成功を記しました。リライトの動機に関する別の視点については、Andrew Kelleyの洞察がMy Thoughts on the Bun Rust Rewriteで利用可能です。

Zigの作成者であるAndrew Kelleyは、言葉を濁しませんでした。彼の爆発的なブログ投稿は、Bunの記念碑的なリライトは技術的な必然ではなく、「関係の破綻」であると主張しました。Kelleyは、Bunのコードベースは「ハックの上にハック」を重ねたものであり、Zigの確立されたメモリ管理とクリーンアップのベストプラクティスに準拠していないと主張しました。彼は、Zigは`defer`を使用して各呼び出しサイトでクリーンアップを明示的に記述することを期待しているが、Bunはこれを怠ったと指摘しました。

Kelleyは、Bunの認識されている安定性の問題、例えばuse-after-freeやdouble-freeエラーなどは、Rustへの抜本的な言語変更ではなく、集中的なエンジニアリング努力で解決可能であると主張しました。彼はJarred Sumnerの管理スタイルを直接批判し、技術的な議論に鋭い人間的な側面を加え、その過程で「趣味の悪いAI愛好家」に言及しました。

Kelleyからの重要な質問は、リライトの前提そのものに異議を唱えました。もしBunのテストスイートが100万行のAI生成コードを検証するのに十分な堅牢性を持っていたのなら、なぜ元のZig実装のバグを捕捉するのに十分ではなかったのか？この鋭い問いは、深いイデオロギー的亀裂を浮き彫りにし、技術的な移行を開発者エコシステムに重大な影響を与える本格的な言語戦争へと変貌させました。

BunはなぜコードベースをZigからRustに切り替えたのですか？

主な理由は安定性でした。Bunのチームは、Zigの手動メモリ管理がJavaScriptCoreのガベージコレクタと相互作用することに起因する、use-after-freeやdouble-freeのようなメモリ安全性のバグに苦しんでいました。Rustのコンパイル時借用チェッカーはメモリ安全性を自動化し、この種のバグ全体を排除します。

AIエージェントはどのようにしてBunのコードを書き換えたのですか？

Bunの作成者であるJarred Sumnerは、Fable 5のプレリリース版を使用して64のClaudeインスタンスをオーケストレーションしました。彼は、1つのAIエージェントがRustコードを書き、2つの「敵対的」エージェントがコードのエラーをレビューし、最後の「フィクサー」エージェントがコミットする前に提案を適用するというエージェントワークフローを設計しました。

Andrew Kelley（Zigの作成者）のリライトに対する主な批判は何でしたか？

Andrew Kelleyは、書き換えは純粋な技術的決定ではなく、「関係の破綻」の結果であると主張しました。彼は、Bunのコードベースは「ハックの上にハック」で満ちていると主張し、Jarred Sumnerの管理スタイルを批判し、BunがZig版のバグ修正に適切なエンジニアリングリソースを投入しなかったと主張しました。

BunにとってRustへの書き換えは成功だったか？

はい。BunのRust版は20%小さく、2-5%高速で、メモリリークが劇的に減少しました。書き換えにより19の新たなリグレッションが発生しましたが、それらは迅速に修正されました。このプロジェクトは、その過程で128の既知のバグを修正し、将来の開発のためのより安定した基盤を築きました。