AI時代におけるプログラミング言語の進化

AI時代におけるプログラミング言語の進化 José Valim 2026年9月24日 AI, ランタイム, 保証 この記事は、AI時代にプログラミング言語がどのように進化するかについての短い考察の集まりです。2つのパートに分かれています：考察とエージェント型ツールです。最初のパートでは、人間がコードの大部分を書かなくなった場合に、プログラミング言語、そのエコシステム、コミュニティに何が起こるかという疑問を提起します。2番目のパートは、より具体的で意見が分かれるところです。コーディングエージェントが私たちの言語のユーザーになった今、私たちのツールはどのように改善されるべきかです。これらのトピックに関する私の意見は変わるかもしれませんが、最近私の頭にあったことの妥当な要約です。 考察 このセクションでは、エージェントがコードの大部分を書くようになった場合、プログラミング言語やそのコミュニティがどのように変化するかを探ります。これはまだ議論の多いトピックですが、多くの開発者やチームにとってはすでに現実となっています。したがって、それがどれほど広まったと信じているかに関わらず、この変化が私たちにどのような影響を与えるかを検討することは私たちの責任です。始めましょう。 コミュニティについて ほとんどのプログラミング言語の中心には、共有された感性に基づいて集まるコミュニティがあります。Pythonは、何かを行うための明確な方法を重視しています。Rubyは長い間、プログラマーの幸福感を育んできました。Lispコミュニティは伝統的に、言語自体を再形成する能力を称賛してきました。しかし、私たちがコードの大部分を書かなくなったらどうなるでしょうか？そして、それは私たちの帰属意識にどのように影響するでしょうか？それを維持しようとすべきでしょうか、それともコミュニティは、それらを再び結びつける次のものを見つけるべきでしょうか？ 同じように、私たちは困難な問題に対処し、共有された抽象化を作成するために言語を中心にエコシステムを構築します：Webフレームワーク、テンソルライブラリ、データ処理パイプライン、GUIツールキットなどです。コーディングエージェントは、これらのエコシステムに2つの相反する影響を与える可能性があります。第一に、エコシステムの間のギャップが小さくなるかもしれません。これらのフレームワークをすべて構築するには、かなりの時間と労力が必要であり、その多くはエージェントが潜在的に削減できます。これは、問題が既知のアルゴリズムの実装、論文からのアイデアの翻訳、または既存の実装を言語間で移植することを含む場合に特に当てはまり、より小さなコミュニティがより大きなコミュニティに迅速に追いつくことができます。 一方で、実装することが十分に安価になった場合、人々はまだ努力に参加し、同じソリューションで協力するでしょうか？問題Xを解決するためのライブラリが必要な場合、私は単にエージェントに私が本当に必要としているものを構築するように依頼するかもしれません。これは興味深い緊張を生み出します。コーディングエージェントはエコシステム構築のコストを劇的に削減できますが、同時にエコシステムを形成する力の1つを弱める可能性があります。 人間工学について プログラミング言語が進化する理由の相当部分は、構文的な便宜を追加し、時間をかけて人間工学を改善することです。しかし、人間がコードの大部分を書かなくなったら、これらの変更はどれほど重要でしょうか？例えば、過去10年間で、明示的なnullチェックの連続よりも人間が書くのにかなり便利な、オプションのチェイニング演算子を追加する言語の流入を見ました。一方で、エージェントは定型的な作業に悩まされず、その違いははるかに意味が少なくなります。これらの便宜が、コーディングエージェントのトークン効率も向上させるという議論があります。しかし、私は、特にモデルがより安価になり、効率的になり、コンテキストウィンドウが大きくなるにつれて、トークン効率はプログラミング言語を最適化すべき特性の末尾にあると主張します。私は、コーディングエージェントのために作られたと主張する新しいプログラミング言語が、最終的に構文に焦点を当てている場合、それは実質的に今日の制限を中心に構築しているとまで言います。私はエージェントを使用してHTML、CSS、JavaScript、Elixir、Rust、Leanを記述しましたが、私には巨大に感じられる構文の違いは、彼らにとってはそれほど重要ではないようです。彼らの視点では、すべてトークンイン、トークンアウトです。 コンパイラについて この文脈でプログラミング言語について議論するたびに、一般的なフォローアップの質問があります：そもそもプログラミング言語は必要になるでしょうか？おそらくコーディングエージェントがコンパイラを置き換え、直接アセンブリを書くでしょうか？私はいくつかの理由でこれを買いません。第一に、デスクトップアプリケーションを構築している場合、サポートするすべてのアーキテクチャに対して異なるアセンブリ実装を維持したくないでしょう。依然として、アーキテクチャに依存しない表現と、それをターゲットマシンに低下させる能力を持つものが必要です。言い換えれば、たとえその言語が人間が書くために設計されていなかったとしても、コンパイラと高水準言語の一部を少なくとも再発明したことになります。第二に、すべてに優れた単一の言語または計算モデルを見つけていません。システムプログラミング言語、定理証明器、並行、分散、回復力のあるソフトウェア（例：Erlang/Elixir）用の言語、クエリ言語、ハードウェア記述言語などがあります。それらは異なるセマンティクス、異なる抽象化レベル、異なる保証をエンコードします。単一の低水準言語がそれらすべてを統一することを期待するのは不合理です。プログラミング言語がなくなるわけではなく、人間が書くためにプログラミング言語を最適化するのをやめた場合、何を最適化すべきでしょうか？ エージェント型ツール 過去に、人間にとって優れたツールを作成することが、エージェントにとっても優れたツールにつながると述べてきました。これは常に真実であると信じています。これにより、私たちがすでにやっていることを自動化するソリューションが構築されました。エージェントは私たちと同じテストを書き、私たちと同じプログラムメタデータを消費し、私たちと同じログを読みます。しかし、私たちが通常自分で行わないアクションを実行するためにエージェントを使い始めたらどうでしょうか？おそらく、それらが非常に手間がかかる、学習曲線が急である、または人間にとって実用的よりも多くの情報を処理する必要があるためでしょうか？それがこのセクションが探求するものです。このセクションのツールは、エージェントがコードの大部分を書くことを必要としません。たとえコードの20％にのみエージェントを使用した場合でも、ここで概説されているツールから恩恵を受けることができます。 ユーザー制約に対するより強力な保証 プログラミング言語は、表現力、保証、人間工学など、いくつかの競合する目標のバランスを取ります。私たちは関心のあるプログラムを表現したい、言語がそれらのプログラムについて有用なプロパティを確立することを望む、そして開発者にとってアクセスしやすくしたい。エージェントがコードの大部分を書いている場合、これらのトレードオフを再検討できます。その一例が、関数シグネチャの推論です。コンパイラが推論できる情報を明示的に書くのは手間がかかるため、これは人間に価値があります。コーディングエージェントは手間を気にしません。むしろ、型と意図を明示することで、コンパイラ、他のエージェント、そして私たち自身が作業するための情報が増えます。さらに重要なのは、型が完全に推論できる言語は、一般的に型チェックできる言語のサブセットであるため、推論のために最適化することは、表現力と型システムが提供できる保証の両方を最終的に制限する可能性があります。すでに、より複雑なシステムで証明を書く能力があることがわかっているエージェントに対して、なぜこれらの制限を課すのでしょうか？ 保証は常に静的に確立される必要はありません。メモリ安全性は、静的に、またはガベージコレクションなどを介してランタイムによって強制される場合があります。モデルチェックは、モデル生成された実行トレースを使用して実際のシステムを検証することにより、モデルと実装を橋渡しできます。具体例：Erlang/Elixirは、分離されたプロセスとメッセージパッシングに依存して、並行プログラムの構造方法を制約し、一部の表現力を分離と耐障害性に関するより強力なプロパティと交換します。すべての並行アルゴリズムがこのモデルに効率的にマッピングされるわけではありませんが、そうするプログラムはそれから有用な保証を継承します。 全体として、ソフトウェアについてより強力な保証を提供するのにこれほど良い時期はありませんでした。すべてのソフトウェアを正式に検証できるわけではありませんが、組み合わせることができます。