プログラミングの終焉

プログラミングの終焉 2026-08-25 先週、Bun 1.4がリリースされました。これは、BunをZigからRustに書き換えたもので、Rustコードが100万行以上含まれているとのことです。この言語切り替えを巡ってはプログラミングコミュニティで多くのドラマがありましたが、このリリースで最も重要なのは、その書き換えがどのように行われたかと、その規模だと私は考えています。この詳細と私自身の経験、そして間もなく登場するAIの進歩は、私たちが知っているプログラミングの終焉が訪れたと信じさせるものです。 私が意味するところは、コードを手動で記述し、他の人間がそれをレビューして有用で動作するソフトウェアを作成するという行為が、絶滅に向かっているということです。少なくとも、エージェントによって作成される有用で動作するソフトウェアの絶対的な洪水に埋もれてしまい、人間はコードそのものではなく、最終結果のみをレビューするようになるでしょう。これまで以上に多くのソフトウェアが存在するようになりますが、そのほとんどのコードは人間によって書かれたり、読まれたりすることはないでしょう。 確かに、ゴミのようなコードも大量に存在するでしょう。バグがあり、役に立たず、ひどく、攻撃的なソフトウェアで、プログラマーの美学、目的、スタイルには全く合わないものです。しかし、実在の問題を解決する、よく設計された動作するソフトウェアも存在するでしょう。しかし、それは人間の目によって詳細にレビューされていないものです。 このソフトウェアの爆発的な増加は、GitHubの8月17日の障害に関する投稿のこのグラフからすでに見て取れます。 昨年以降、生成されるコードの量には急激な指数関数的な上昇が見られます。私の理論では、このほとんどはサイドプロジェクト、企業内の非公式なプロジェクト、あるいは個々のユーザーによるものだということです。これらは重要度の低いものと見なされています。ほとんどの企業では、ビジネスを推進する製品に関して、個々の開発者が2倍、ましてや10倍や100倍の速度で出荷するには、依然としてかなりの組織的な摩擦があります。 これらのグラフのコードのほとんどは、現在フロンティアではないモデルによって生成されたものです。数ヶ月前のフロンティアモデル、つまりFable 5やGPT 5.6 Solではないモデルによって生成されたものです。 AnthropicとOpenAIの開発者は近い未来に生きている BunのRustへの書き換えの詳細を読むと、大きなハイライトは、それが1人の開発者、Jarred Sumner氏によって、Fable 5のプレリリース版と無制限と思われるトークン予算を使って行われたということです。彼は、エージェントが並列で作業し、ZigコードベースをRustに翻訳するための動作ハーネスとフレームワークを作成しました。11日間で、複数のエージェントが6,778件のコミットを生成し、API価格で約165,000ドルかかるほどのトークンを消費しました。 この書き換えを巡るドラマが最初に浮上したのは5月初旬で、上記のブログ投稿が書かれるずっと前のことでした。それは、書き換えのマージによってのみ明らかになり、+1,009,257 -4,024の変更が見られました。私はその規模に驚き、Mythosを使ってこれを達成したのではないかと推測しました。 また、これは無制限のMythosトークンで行われたのか、それともOpus 4.7トークンで、私たち全員の現在、そして近い未来なのでしょうか？私の推測は前者です。だから、これは今年の後半に何が可能になるかのプレビューです。 — @pauldix, 2026年5月14日 当時の私の経験では、Opus 4.7でそのようなことが可能だとは思えなかったので、このような書き換えを可能にしたのはまだリリースされていないMythosに違いないと考えていました。AIが100万行のコードを書き、その後数ヶ月かけてそれを洗練させて、現在数百万の開発者マシンで動作している信頼できるソフトウェアを作成したという事実は、全く驚くべきことです。 そして、「比較対象となるオラクルがあったので、ある言語から別の言語への移行は簡単だったため、それほど印象的ではない」と言うかもしれませんが、私はそれがこの全体を過小評価していると思います。検証システムを構築し、適切な指示を与えることができれば、AIは非常に複雑で高度なソフトウェアを生成でき、それが機能するまで継続的に洗練させることができます。 AnthropicとOpenAIの開発者が過去数ヶ月間にX（旧Twitter）で言っていることに注意を払うと、彼らはそれぞれ週に数十件から数百件のPR（プルリクエスト）を出荷しており、彼らの焦点はスタックの上位に移行しています。これは理にかなっています。なぜなら、開発者が自分の仕事もこなしながら、毎週数百件のPRに相当するコードをすべて詳細にレビューすることは実際には不可能だからです。 彼らが公に言っていることを額面通りに受け取ると、彼らはもはや出荷されるすべてのコード行を非常に詳細にレビューしているわけではありません。彼らは、AIが大規模かつ高速にソフトウェアを生成できるように、システム、プロンプト、検証ツールを構築することに時間を費やしています。少なくとも、彼らがループについて話すときに私が解釈しているのはそういうことです。 しかし、彼らは無制限のFableとAstra（OpenAIの次期モデル）へのアクセスがある世界で活動しています。彼らは、私たち一般人がおそらく1年後に経験するであろう近い将来に生きています。ソフトウェア開発にAIを使用する彼らの経験は、週ごとのFableの割り当てがリセットされるのを待っている、現場の私たち他の人々の経験ではありません。 Bun 1.4のリリースは、Fableレベルの知性とほぼ無制限のトークンを組み合わせた場合に何が可能になるかの一端を示すはずです。数百万の稼働中のデプロイメントで証明された、大規模で動作するソフトウェア配信です。 現場からの私の経験レポート 私自身の経験から、最近の2つの逸話をお伝えします。私の感覚では、Fableは、昨年11月末にリリースされたOpus 4.5が異なると人々が気づいたのと同様の方法で、以前のモデルとは質的に異なります。より高いレベルの指示と少ない監督で、より多くを生成できる閾値を超えました。 私は、開発したい機能の要件、アーキテクチャ、指示を与えることができ、それ以降の私の操作なしに、複数の作業時間で完全に機能する最初のバージョンを作成することができます。私の2つの例は、どちらもInfluxDBに出荷されていないものですが、私がフォークで構築した新しい機能です。新しいモデルで何が可能かを見るために、これらを選択しました。 最初の例は、InfluxDBのデータがIceberg REST経由、または外部S3バケットとGlueカタログからアクセスできるようにする、Iceberg統合です。これは複雑な機能で、以下が必要です。 機能有効化のためのAPIとCLI Iceberg REST APIの実装 Icebergマニフェストと外部ストアのParquetデータを作成するためのコンパクターとの深い連携 非エクスポートユースケースのためにInfluxDBで実装された、Glue S3 APIへのリクエストまたはIcebergマニフェストの作成 これは数千行の実装コードとテストコードからなります。私は大まかなアーキテクチャ設計と要件をまとめ、その後、サブエージェントを介したコードレビューのトリガー、およびプロセスの監督を通じて、Fableに作業を指示しました。14時間後、動作するバージョンが生成されました。その後、InfluxDBクラスターを実行し、DuckDBとPyIcebergを外部クライアントとして使用して、すべてをエンドツーエンドで検証するように指示しました。いくつかのバグを修正し、すべてが機能することを検証しました。 2番目の例は、InfluxDBのエッジデータレプリケーションシステムの作成です。これは、サテライトとして実行される複数の個別のInfluxDBノードが、圧縮されたデータを定期的に中央のInfluxDBクラスターにレプリケートするものです。これは以下を定義します。 レプリケートされるものと頻度を設定するためのAPI 上記のアクセス用CLI レプリケートする圧縮データをフィルタリング、集計、作成するために使用されるコンパクターの更新、および送信されたものと残っているものを把握するための追跡 レプリケーションペイロードで使用されるカタログ情報にアクセスするためのエッジノード用API パイプラインに圧縮ブロックデータを受信するためのAPI セットアップ全体を可視化するためのメトリクスとシステムテーブル 私はアーキテクチャを設計し、ユーザーエクスペリエンスがどのようになるかの例を示しました。Fableと協力して設計を生成し、その後、監督者として行動しながら、作業を行うように指示しました。28時間後、ほぼ機能する実装が完成しました。