（本記事は、https://www.youtube.com/watch?v=l6lxgYeVZqsにある私のYouTube動画の書き起こしを基に編集したものです）

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

それでも、リーナスは一人しかいません。実際のところ、彼のその実装能力だけでは、彼について多くを語ることはできません。むしろ注目すべきは、その後に起こったことです。

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

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

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

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

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

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

いま、我々がリーナスだ

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

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

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

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

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

それが、私にとってのリーナスの教訓です。そしてそれは、「LLMがあればプログラミングは誰にでも簡単だ」と言う人々に対する、即座の反論として用いられるべきものです。