Bunの「大移行」が巻き起こした論争

ここ数ヶ月、JavaScriptランタイムBunがZigからRustへ大規模な移行を行った件が、開発コミュニティで大きな波紋を呼んでいます。特に注目すべきは、この移行にAIコーディングツールであるClaude Codeが極めて積極的に利用された点です。Bunの作者であるJarred Sumner氏は、この移行の経緯と理由について詳細な説明を公開しました（出典）。

その後、Zig言語の作者であるAndrew Kelley氏が、Jarred Sumner氏との間にあったとされる長期的な不和や、彼の開発スタイルに対する不満を露わにする投稿を発表しました。Kelley氏はSumner氏を「臭いマネージャー」と呼び、「LLMにアクセスできるずっと前から、Jarredはすでにずさんなコードを書いていた」とまで言及しています。

これはかなり衝撃的なニュースですね。AIツールの活用そのものだけでなく、その結果として人間関係にまでヒビが入ってしまうというのは、ソフトウェア開発の現場におけるAIの導入が持つ別の側面を示していると感じます。

「LLMにアクセスできるずっと前から、Jarredはすでにずさんなコードを書いていた」（出典）

この一連の騒動は、単なる技術的な移行の話に留まらず、ソフトウェア開発の根本的な性質、つまり「職人技」と「工業プロセス」のどちらとして捉えるべきかという問いを浮き彫りにしました。

ソフトウェア開発は「職人技」か「工業プロセス」か

主記事の著者は、ほとんどのソフトウェア生産は「工業プロセス」であると考えています。大規模な組織で、標準化されたハードウェアとシステム上で作業し、開発者の役割も部門、企業、さらには国を越えて標準化されている、という現状認識です。数十年前は熟練した個人が手作業で行う「職人技」だったかもしれませんが、現在はそうではない、と強く主張しています。

一方で、著者は長年、「ソフトウェア生産は職人技であるべきなのか」という疑問を抱いているとも述べています。より良いソフトウェアは、開発者が職人のように傑作を何年にもわたって作り上げることから生まれるのでしょうか？それとも、工業的で反復可能で自動化されたプロセスを導入し、開発者がコード工場の熟練労働者として機能することから生まれるのでしょうか？

この問いに対する開発者一人ひとりの答えは、日々のコーディングスタイルや、AIコーディングツールとの向き合い方にも直結するのではないでしょうか。私自身は、AIを積極的に活用しつつも、最終的な品質保証や創造的な部分は人間にしかできないと感じているので、そのバランスが重要だと考えています。特に、Claude Codeをバイブコーディングに使っていると、AIはあくまで強力なツールであり、それをどう使いこなすかという「職人技」が問われるという感覚があります。

現在のソフトウェア開発における「職人技」と「工業プロセス」の対比を以下にまとめます。

項目 職人技的アプローチ 工業プロセス的アプローチ
開発哲学 個人の創造性、美的感覚、深い専門知識を重視。傑作の追求。 標準化、再現性、効率性を重視。コモディティとしてのソフトウェア生産。
ツールの役割 開発者の能力を拡張する道具。創造性を高める補助。 自動化、省力化を目的とした機械。個人の裁量を減らす。
コードの品質 高度なカスタマイズ性、独特の洗練された設計、長期的なメンテナンス性。 バグの少なさ、安定性、スケーラビリティ、予測可能なパフォーマンス。
AIツールの位置づけ 個人のスキルを補完・強化するインテリジェントなアシスタント。 定型作業の自動化、コード生成、品質チェックの効率化ツール。

AIコーディングが加速させる「工業化」の波

今回のBunのケースのように、Claude CodeのようなAIコーディングツールが大規模な言語移行プロジェクトに活用されたことは、ソフトウェア開発の「工業プロセス化」を加速させる兆候と言えるでしょう。AIがコード生成やリファクタリングを効率的に行うことで、開発者はより高レベルな設計や問題解決に集中できるようになります。

しかし、Andrew Kelley氏がJarred Sumner氏を批判したように、「LLMにアクセスできるずっと前からずさんなコードを書いていた」という指摘は、AIがコード品質を魔法のように高める「シルバーバレット」ではないことを示唆しています（出典）。AIはあくまでツールであり、それを使いこなす人間のスキルや倫理観が重要であるという点は、Fred Brooksの有名なエッセイ「No Silver Bullet」が40年経った今もなお真実である、という参考記事の主張とも重なりますね。

AIは「シルバーバレット」ではない。AIはあくまでツールであり、それを使いこなす人間のスキルや倫理観が重要である。

私個人のプロジェクトでもClaude Codeを活用していますが、特にリファクタリングや言語間のブリッジコード生成において、その威力は絶大だと感じています。しかし、生成されたコードの意図を完全に理解し、潜在的なバグを見つけ出す能力は、やはり人間の開発者にかかっています。たとえば、RustのC FFI（Foreign Function Interface）は長年Cライブラリの恩恵を受けてきましたが、メモリ安全性の保証はC側に依存するという課題がありました。

参考記事で言及されている「Fil-C」のような技術は、C/C++コードにランタイムチェックを追加することで安全性を高めようとしており（出典）、AIと組み合わせることで、より安全で効率的なクロス言語開発が進む可能性を感じます。自分のアプリに組み込んでみたいですね。

「タブ vs スペース」論争から学ぶ本質

主記事の著者は、この議論の本質を理解するための例として、古典的な「タブ vs スペース」論争を持ち出しています。この論争は、なんと1988年から存在しており、30年以上にわたって開発者を二分してきました（出典）。

一見すると些細なフォーマットの議論ですが、これは「個人の美学（職人技）」と「標準化された規則（工業プロセス）」の対立を象徴しています。タブを使いたい人は効率性やアクセシビリティを重視し、スペースを使いたい人は厳密なレイアウトの一貫性を重視する、といった具合です。

最終的には、ESLintやPrettierのようなツールによって自動フォーマットが普及し、この議論は個人の好みから「チームやプロジェクトのルール」という工業プロセス的な側面が強くなりました。AIコーディングツールは、この流れをさらに加速させ、個人の裁量を減らし、標準化されたコードスタイルを強制する強力な手段となり得るでしょう。

これは、個人の「職人技」としてのコーディングへの情熱が薄れることにつながる可能性も秘めていると感じます。しかし、定型的なフォーマットの議論から解放されることで、より本質的な設計やアルゴリズムに集中できる、というポジティブな側面もあるのではないでしょうか。まるで自作PCのパーツ選びで、メモリやSSDの規格は決まっているものの、どのメーカーを選ぶか、GPUの性能をどこまで追求するかといった部分に個人のこだわりが出るのに似ているかもしれません。

項目 タブ スペース
メリット ファイルサイズが小さい、アクセシビリティ（個人の設定で表示幅調整可能）、効率的なインデント操作。 環境によらず一貫した見た目を保証、GitHubなどのコードビューアで意図通りに表示されやすい。
デメリット 環境依存で表示幅が変わる、混在すると問題発生。 ファイルサイズが大きい、インデント操作が手間（ツールで補完）。
AIとの関連 AIは標準化されたフォーマットを学習し、それに従うコードを生成する傾向がある。個人の設定に合わせた生成はまだ限定的。

この論争は、ソフトウェア開発における本質的な問いの縮図であり、AI時代においても、何が個人の裁量に任され、何が標準化されるべきかという議論が続いていくことを示唆しています。

技術と人間性のバランスが問われる時代

今回のBunの移行騒動は、AIがもたらす開発効率の向上と、それによって生じる人間関係や開発哲学の摩擦という、現代のソフトウェアエンジニアリングが直面する本質的な課題を浮き彫りにしました。AIは強力なツールであり、開発プロセスを工業化する大きな力を持っていますが、最終的にソフトウェアを作り、利用するのは人間です。技術の進化とともに、開発者がどのように自身のスキルを磨き、チームと協力し、そして何より「ソフトウェアをなぜ作るのか」という問いに向き合い続けるかが、これまで以上に重要になるでしょう。

これはまるで、高機能な電動工具を手にしても、最終的にどんなものを作り上げるかは、その職人の腕とセンスにかかっているのと同じです。AIを使いこなす「新しい職人技」が求められる時代が来ているのではないでしょうか。