（本記事は、私のYouTube動画（https://www.youtube.com/watch?v=l6lxgYeVZqs）の書き起こしをもとに再構成したものです。）

リーナス・トーバルズが最初のLinuxカーネルを開発したとき、彼はMinixのソースを読み込み、コンピュータアーキテクチャを学び、必要な基礎知識をすべて備えていました。そして言うまでもなく、極めて優れたプログラマーでした。ですが、386向けに最小限ながら動作するUnixカーネルを書くという作業（当初、Linuxはいわば単一アーキテクチャでした）は、他の多くのプログラマーや学生にも手が届くものでした。「多く」といっても、0.1%とか、千人に一人とか、一万人に一人とか、その程度の意味ですが。もちろん大半の人にはできない偉業ですが、できる人は決して少なくありません。近年のHacker Newsをご覧になれば、Cで書かれたカーネル、ゼロから実装されたマイクロカーネル、Rustで書かれたカーネル、あらゆる手法で作られたカーネル、Raspberry Pi向けに一から作られた小さなUnixシステム、ESP32向けのOSなど、どれだけ多くのプロジェクトがあるかがお分かりになるはずです。カーネルを書くことは誰にでもできることではありませんが、十分な努力を注げば、多くの人がやり遂げられることでもあります。もちろん、誰もがうまくやれるわけではありません。彼は疑いようなく天才的なプログラマーですから、より良くやり遂げたのです。

それでも、リーナスは一人しかいません。実のところ、彼のその実装能力だけでは、彼の本質はあまり語れません。むしろ注目すべきなのは、その後に起きたことなのです。

彼はコードを書くのをやめた

有名なオープンソースプロジェクトのメンテナの中でも、彼はLinux開発のごく初期から、ほぼ完全にコードを書くことをやめ、プロジェクトを率いることに専念した数少ない一人でした。リーダーとして、コーディネーターとして、プロジェクトが目指すべきゴールを明確に持ち続ける唯一の頭脳として、といった役割に専念するためです。これは稀なことです。多くのメンテナは（かくいう私自身、長い間そうでしたが）、むしろ自ら手を動かして実装し続け、なかなか委譲しないものです。

これはソフトウェアに対する考え方の違いからも来ています。Linuxは必然的に、計り知れないほど大きくならざるを得ませんでした。多くのデバイスやプラットフォーム、サブシステムを抱え込み、時代や新しいソフトウェアの要請、次々と登場するハードウェアに適応し続けることは、カーネルというものの本質なのです。ですから、肥大化は失敗ではありませんでした。一方でRedisは、自己完結したままでいられる存在でした。先日、SQLiteのリチャード・ヒップ博士からlinenoiseにプルリクエストをいただきましたが、彼もまた安定性やミニマリズム、パフォーマンスを追求しつつ、常にコードベースを非常に小さく保ち、長い間自らコードを書き続けています。リーナスはそうではありませんでした。彼はすぐに理解したのです。一人の人間の実装能力をはるかに超えて大きくなっていく運命にあるプロジェクトにとって、より重要なことに自分の時間を使わなければならないということを。

こうして彼はプロジェクトリーダーになりました。アイデアと方向性を担う存在になったのです。では、リーナスは何をしているのでしょうか。彼は毎回、すべてのパッチを一行一行チェックするわけではありません。もちろん、一つの実装を深く読み込み、何が起きているかを理解することもありました。長年にわたり、新しいサブシステムを書いたり、書き直したりすることもありました。たしかUSBレイヤーを一度、ずいぶん前にそうしたと思いますし、仮想ファイルシステムでも、inodeやinodeキャッシュの構造を変えて再実装したと記憶しています。そのほかにもいくつかの場面でありました。Gitを作ったときのように、時折プログラミングを続けることもありました。しかし大半において、彼はパッチを一つひとつ詳細に、行ごとに眺めているわけではありません。各分野のメンテナたちと対話し、ある機能やある方向性が、進むべき道なのかそうでないのかを見極めているのです。

いわば『人月の神話』のブルックスの言葉を借りれば、リーナスはカーネルの設計概念を保持し、カーネルのヒエラルキーの下にいるすべての人と対話を続け、カーネルがあるべき方向へ進むようにしているのです。開発が一定の方向へ向かうように、ということです。実装の観点からも――どのように実装するのか、その品質はどうか、コードの書き方そのものに込められた実装上の思想はどうか――そして設計の観点からも――何をしたいのか、何をしたくないのか、モジュールやスケジューラ、ハードウェアサポート、Rustを統合するかどうかといった点で何が最良の戦略なのか。そういったことすべてです。

私は、これこそがリーナスの真の天才性だったと考えています。彼は単に極めて優秀なプログラマーであるだけではありません。そうした人は他にもいます。彼は同時に、優れたメンテナであり、信じられないほど優れた設計者であり、巨大なプロジェクトのアイデアと構造を一貫性をもって扱い、多くの人々と対話しながらまとめ上げられる人物なのです。これは誰にでもできることではありません。

今、私たちがリーナスだ

さて、人工知能とともにプログラミングするとき、私たちはまさに同じ存在になります。私たちはリーナス・トーバルズなのです。常に彼ほどの才能を持っているわけではありませんが、コードの一行一行をレビューしないプロジェクトにおいて、私たちが担うべき役割は、まさにあのタイプの役割なのです。彼が担っているのとまったく同じ役割です。

ただ、制御する対象はよりシンプルです。多数のエージェントを並列で使わない限り、さまざまな方向から届く無数のパッチをさばくより、はるかにシンプルに制御できます。ただし、はるかに高速です。人間の速度で動く大人数のチームとやり取りする代わりに、そのとき並行して進めているプロジェクトのブランチ数に応じて一人、二人、三人といった少人数のチームとやり取りするようなものです。しかも彼らははるかに速く、すぐにフィードバックを返してくれます。これは仕事のやり方を少し変えますが、私見ではより良い方向に変わります。より簡単で、コンテキストスイッチも少なく、関わる人数も少なく、性格や態度に起因する問題もはるかに少なくなるのです。

ですから、この役割が重要だと考えるなら、自動プログラミングを「プロンプトを入れれば、あとは勝手に書いてくれるもの」だと考えてはなりません。バイブコーディングは、自動プログラミングとは何か、そして大多数の人にとって自動プログラミングが何になるのかについて、誤った考え方です。バイブコーディングは、技術的な能力を持たない人でも自分のツールを作ることに携わりたいといった場合には、とても興味深いものです。可能性を民主化するのですから、歓迎すべきことです。しかし、それは本質ではありません。

むしろ自動プログラミングとは、熟練した技術者、熟練したプログラマー、熟練した設計者、熟練したソフトウェアアーキテクトの手にかかれば、リーナスの役割を担うことなのです。エージェントやLLMが、さまざまなサブシステムのメンテナの役割を担うのです。そして誰もがそれをうまくできるわけではないからこそ、自動プログラミングにも才能が必要なのです。エージェントと対話し、アイデアを検証し、どの実装をすべきか、すべきでないかを見極め、エージェントに最良の仕事をさせるためのコミュニケーションの方法を心得、優れたプログラマーが直観し、先回りして用意するような設計上のヒントを与えることができる才能が必要なのです。

つまり、自動プログラミングをうまくやるということは、リーナスの役割を担うということです。そしてこのことは、うまくやることもできれば、へたくそにやることもあり、理解されることもあれば、貶められることもあります。また、訓練を要し、学ぶ必要があるものでもあります。ちょうどリーナスがそうやって学んだようにです。彼には確かにこのことに対する生来の才能があったでしょう。しかし彼は「すべて自分で実装する」という状態から、シンフォニーを操り、オーケストラを指揮する能力へと移行していったのです。

それが私にとってのリーナスの教訓であり、LLMがあればプログラミングは誰にでも簡単だと言う人たちへの、真っ向からの反論としてすぐにでも用いられるべきものなのです。