AI注目記事のキュレーターページ

Jarred Sumnerは、ZigからRustへのBunの再構築についてのブログ記事を5月9日以来約束していましたが、その再構築が完了するまでの時間よりもずっと長く待たされました。正直なところ、待った甲斐がありました。この記事は、動的ワークフロー、試行運転、敵対的レビューなど、非常に洗練されたエージェント工学の詳細な説明です。Jarredは記事の前半で、Bunをここまで進めたZigを称賛しています。そして、彼が強調する核心的なアイデアに触れます。「私たちのバグ修正リストは気分が悪く、Bunのクラッシュについて心配しながら眠りにつくのに疲れていました。Zigを責めるつもりはありませんが、他のZigユーザーは私たちが抱えていたバグを持っていませんし、GCと手動管理メモリを混在させることは、ソフトウェアが必要とするには珍しいことです。私たちはZigがなければここまで来られなかったでしょうし、常に感謝しています。最近まで、プログラミング言語の選択はBunのようなプロジェクトにとって一方通行の決定でした。大規模なソフトウェアをゼロから再構築することは決してすべきではないと誰もが知っていますが、今日の最前線モデルによって動かされるコーディングエージェントは、その方程式を変えます。なぜRustを選んだのか？それはメモリ管理の課題に帰着します。バグリストの大部分は、使用後解放（use-after-free）、二重解放（double-free）、エラーパスでの「解放を忘れた」ことに関連しています。安全なRustでは、これらはコンパイラエラーとなり、RAIIのような自動クリーンアップが行われます。再構築を可能にした重要な要素は、BunのテストスイートがTypeScriptで書かれていたことです。これにより、準拠スイートとして機能し、エージェントハーネスがBunからRustへの初期ポートの多くを自動化できました。最初はうまくいくとは思っていませんでしたが、数日後にはテストスイートの高い割合が合格し、新しいRustコードが元のZigコードベースとどれほど一致しているかを見て、私の意見は「試す価値がある」から「これをマージするつもりだ」に変わりました。11日間のほとんどの間、私はワークフローを監視し、出力を手動で読み取って問題やバグをチェックし、Claudeにループを編集して修正するよう促しました。+100万行追加されたPRをどうレビューするのか？大規模なLLM作成コードを責任を持ってマージするために必要な信頼をどう構築するのか？言語に依存しないテストスイートと100万のアサーション、敵対的コードレビュー、何かがうまくいかないときには、手動でコードを修正するのではなく、コードを生成するプロセスを修正することです。新しいBunの実装は、Claude Codeでほぼ1ヶ月間稼働しています。Claude Code v2.1.181（6月17日リリース）以降、BunのRustポートを使用しています。Linuxでの起動が10%速くなりましたが、その他はほとんど誰も気づきませんでした。退屈なのは良いことです。Anthropicで働く特典は、トークンを支払う必要がないことです。推定コストは165,000ドルです！マージ前には、59億の未キャッシュ入力トークン、6.9億の出力トークン、720億のキャッシュ入力トークンの読み取りが必要でした。約165,000ドルのAPI価格です。この全体は、協調した並列エージェントの助けを借りて、非常に野心的なプロジェクトに取り組むことの魅力的なケーススタディです。