コンパイラはプログラミングを終わらせるはずだった

コンパイラはプログラミングを終わらせるはずだった

2031年の火曜日の午前7時40分、あなたはまだ一行もコードを書いていません。今日書かないかもしれませんし、それはそれで構いません。

あなたが眠っている間に、4人のエージェントが昨日午後にあなたが整理したバックログに取り組みました。そのうち3人は完了しました。彼らのプルリクエストは、追加したテスト、機能が動作する短い録音、そして不明な点についてのメモとともに、あなたを待っています。4人目のエージェントは午前2時13分に停止し、代わりにあなたに質問を残しました。

仕様では、払い戻しは元のカードに戻るとされています。しかし、この顧客のカードは3月に期限切れです。どうすべきでしょうか？

エージェントは一日中払い戻しコードを書くことができます。しかし、それができないのは、あなたの会社がカードの期限が切れた顧客にいくら支払うべきかを決定することです。そのため、エージェントは停止し、質問をしました。これは、新しい採用者にも期待することと全く同じです。あなたの朝はこう進みます。3つのプルリクエストを読み、サポート担当者と話し、誰も（人間であれそうでなかれ）二度と推測する必要がないように、そのルールを非常に明確に書き留めます。

想像上の火曜日、2031年

エージェント

1234

あなた

5678910

22:0002:0006:0010:0014:0018:0022:00

エージェント

1. 22:00 3人のエージェントが昨日のバックログを処理し、テストと録音を含む3つのプルリクエストを開きます。
2. 22:00 4人目のエージェントが停止し、質問を残します：払い戻しは元のカードに戻りますが、そのカードは期限切れです。
3. 13:00 エージェントが、あなたが最初に書いたテストとともに、あなたが書き留めた払い戻しルールを構築します。
4. 21:30 今夜の実行は、あなたが承認した計画から開始されます。

あなた

1. 07:40 3つのプルリクエストを読み、録音を視聴します。
2. 09:00 02:13の質問に答えます。まだできません。
3. 10:00 サポートに、カードの期限が切れた顧客が何を期待しているか尋ねます。
4. 11:00 ルールを短い仕様と5つのテストとして書き留めます。
5. 14:00 お金に関わる部分のエージェントの作業を読みます。
6. 16:30 今夜の計画を承認します。帰宅します。

これは架空の一日ですが、それでも縮尺は正確です。赤い印は、作業が人を待った唯一の時間です。

この火曜日は私がでっち上げたものです。しかし、そのどれもSFではありません。 unattended で夜間作業を行うエージェントは今日でも存在し、そのうちの1つが毎晩私のマシンで実行されています。それは小さなプロジェクトを考案し、それを構築し、テストし、私は朝食時にそれが何を作ったかを知ります。最初の朝、それが何を作ったのか全く分かりませんでした。そのビルドは現在、Rule Safari、このサイトのライブプロジェクトであり、その仕組みを説明する記事があります。

では、これはプログラミングの終わりなのでしょうか？人々は70年以上もこの質問をしています。私はそれが心地よいと感じます。しかし、少し疑わしくも感じます。

プログラミングは1954年から終わるはずだった

1954年11月10日、IBMのプログラミング研究グループは、FORTRANという新しい言語に関する予備報告書を完成させました。その中の1文には、FORTRANが「コーディングとデバッグを事実上排除するはずだ」と書かれています。

私はこの文が大好きです。それは非常に確信に満ちており、予算さえも伴っていました。FORTRANなしで行う場合の半分のコスト未満で問題を解決する、と。当時の業界には、このようなものに名前がありました。アセンブラやコンパイラは自動プログラミングと呼ばれていました。あなたは欲しいものを記述し、マシンがプログラムを書くのです。

FORTRANは1957年にリリースされ、それは確かに一種のコーディングを排除しました。ほとんど誰も数式を手作業で機械命令に翻訳しなくなりました。デバッグは問題なく生き残りました。（今月、私はブックマークが12時間ごとにしか保存されないというScryバグを追いかけました。そのため、デバッグが健在であることを確認できます。）

FORTRANが実際に行ったことは、仕事の面倒な部分を1つ取り除き、仕事を1段階引き上げることでした。人々はレジスタについて考えるのをやめ、より大きな問題について考えるようになりました。プログラムの作成コストが安くなったため、誰もがより多くのプログラムを欲しがるようになりました。それは以来、何度も繰り返されてきました。

1. 1947年
   アセンブリ言語
   あなたは、生の数値で命令を書くことをやめました
   Kathleen Booth, "Coding for A.R.C."

2. 1957年
   FORTRAN
   あなたは、数式を手作業で機械命令に翻訳することをやめました
   1954年の報告書：「コーディングとデバッグを事実上排除するはずだ」

3. 1972年
   C
   あなたは、新しいマシンごとに同じプログラムを書き直すことをやめました

4. 1981年
   The Last One
   あなたは、結局何もやめませんでした
   BASICプログラムジェネレーターで、あなたが購入する必要のある最後のプログラムと名付けられました。

5. 2008年
   Stack Overflow
   あなたは、すべてのエラーメッセージを一人で解決することをやめました

6. 2010年
   npm
   あなたは、すべてを自分で書くことをやめました

7. 2021年
   GitHub Copilot
   あなたは、定型的なコードを入力することをやめました

8. 2025年
   コーディングエージェント
   あなたは、ほとんどのコードを入力することをやめました

9. 20??年
   次
   あなたは、何を？

すべての段階で、プログラマーの負担が軽減されました。破線は、登りが終わったことを約束していました。

私のお気に入りの段階は1981年です。D.J. "AI" Systemsという英国の会社（はい、本当です）は、The Last Oneという名前のBASICプログラムジェネレーターを販売しました。その名前がすべてのピッチでした。それはあなたのすべてのプログラムを書いてくれるので、あなたが購入する必要のある最後のプログラムになるはずでした。

レビューアは、いくつかのビジネスプログラムに役立つと見つけました。それは最後のプログラムではありませんでした。

ここには、すべての段階におけるパターンがあります。何かが自動化され、作業を行っていた人々はその作業を手作業で行うのをやめ、分野は成長を続けます。GitHubは2025年のレポートで1億8000万人以上の開発者を数え、そのうち3600万人以上が過去12ヶ月で参加しました。

したがって、AIがプログラミングを終わらせるとは思いません。この段階は、ある意味で異なるとは思いますが、それはスピードです。GitHub Copilotのプレビューは2021年6月に出ました。2025年までに、Stack Overflowの調査に参加した開発者の84%がAIツールを使用しているか、使用する予定でした。4年間で、目新しさからデフォルトになりました。

2026年の実際

今は雰囲気が騒がしいので、数字から始めましょう。（雰囲気といえば：Andrej Karpathyは2025年2月に、「雰囲気に完全に身を任せる」コーディングの種類を「vibe coding」と名付けました。Stack Overflowはその年にそれについて尋ねました。開発者の72%はそれがプロフェッショナルな仕事の一部ではないと述べ、さらに5%は断固としてそうではないと述べました。その選択肢を提供してくれたのが大好きです。）

Stack Overflowの調査は、私たちが定期的に行う最大の健康診断であり、その採用曲線は急峻です。2023年の70%の開発者がAIツールを使用または計画していた状態から、2025年には84%になり、プロの開発者の半数が毎日使用していました。

それほど多くの使用があれば、開発者はこれらのツールを愛していると思うでしょう。そうではありません。好意的な感情は、2023年の77%から2025年には60%に低下し、今年になってようやく62%に回復しました。2025年には、AI出力の正確性を信頼する人（33%）よりも、信頼しない人（46%）の方が多かったのです。最も不満な点は、66%の開発者が選んだ「ほぼ正しいが、完全には正しくないAIソリューション」でした。

私は見られていると感じます。ほぼ正しいというのは、高価な間違いの種類です。なぜなら、正しくない部分を見つけるために、すべての行を読まなければならないからです。（開発者の45%は、AI生成コードのデバッグに時間がかかると述べています。）

20%40%60%80%100%
2023202420252026
70%76%84%
使用中または計画中
77%72%60%62%
好意的
42%43%33%
正確性を信頼

Stack Overflow Developer Survey, 2023年から2026年。2026年の調査では、「使用中または計画中」の質問が削除され、「信頼」の質問が書き直されたため、その2つの線は2025年で終わっています。2023年には約90,000人、2026年には30,000人以上の開発者が回答しました。

次に、AIブーム全体に関する私のお気に入りの研究があります。それは非常に失礼だからです。2025年初頭、非営利研究グループMETRは、適切なランダム化比較試験を実施しました。16人の経験豊富なオープンソース開発者が、彼らが長年関わってきた自身のレポジトリにある246の実際の課題に取り組み、各課題はAIツールの使用を許可するか禁止するかをランダムに割り当てられました。

開始前、開発者はAIが時間を24%短縮すると予想していました。終了後、彼らはAIが20%短縮したと信じていました。時計は、AIを使用した場合、彼らが19%長くかかったことを示していました。

19%も長く！それでも、彼らは助けになったと確信して去りました。

• 経済学者は予測：専門家の予測 39%少ない時間
• ML研究者は予測：専門家の予測 38%少ない時間
• 開発者は期待：タスク前 24%少ない時間
• 開発者は感じた：タスク後 20%少ない時間
• 時計は測定：実際に 19%多い時間

METR, 2025年7月：開発者16人、課題246件、主にCursorとClaude 3.5および3.7 Sonnetを使用。専門家の予測は論文からのものです。速度低下には、2%から39%の範囲で広いマージンがあります。

誰かがそれをホットテイクのためにスクリーンショットする前に：これは16人の人々による、2025年初頭のツールを使用した、モデルがどれほどうまくできるかよりも彼らがよく知っているコードベースでの研究です。

そしてMETRはそれを再度実行しようとしました。2025年8月に57人の開発者と800以上のタスクでより大きな研究が開始され、2026年2月にMETRはデータが信頼性に乏しいため頼れないと述べました。主な理由は、開発者が「AIなしで働きたくない」ため、参加を辞退し続けたことです。初期の数字は、復帰した開発者にとって18%のスピードアップを示唆していました（スピードアップが全くない可能性も含む広い範囲で）。

これが、実験がこれまで失敗した中で最も2026年らしい方法だと思います。人々はAIのないグループに参加することを拒否しました。

METRから私が得るものは、どんな見出しよりも狭く、より有用です：体感速度は測定値ではない。AIがチームを速くしているかどうかを知りたいなら、他のどんなものも測定するのと同じように測定してください。

上がり続ける線

METRのもう一つの主要なプロジェクトは、AIエージェントが単独で完了できるタスクの長さを追跡しています。彼らは人間の専門家がソフトウェアタスクのセットにかかる時間を測定し、エージェントが半分の確率で成功するタスクの長さを特定します。2019年、GPT-2は人に約3秒かかるタスクを処理しました。GPT-4は2023年には約4分に到達しました。Claude 3.7 Sonnetは2025年2月に1時間に到達し、Claude Opus 4.6は1年後に約12時間に到達しました。

シリーズ全体を通して、その数値はほぼ6ヶ月ごとに倍増しています。2023年以降は、ほぼ4ヶ月ごとになっています。

1分1時間1営業日1営業週1ヶ月
2019202120232025202720292031
トレンドが続けば
GPT-2GPT-4Claude 3.7 SonnetGPT-5Claude Opus 4.6

METRの時間枠（バージョン1.1）：各モデルが半分の確率で完了する、人間の専門家の時間でのタスクの長さ。METRは、現在のタスクでは16時間を超えるものは信頼性が低いと述べているため、Claude Mythos Previewの5月の17時間の測定値は線上にありません。破線は6ヶ月ごとの倍増を延長したものです。これはトレンドであり、約束ではありません。

さて、対数スケールのグラフに末尾に破線があるのは、多くの悪い予測が始まる方法なので、注意深く進めましょう。「半分の確率」は、その定義において多くの役割を果たしています。ベンチマークタスクは、あなたのコードベースよりもクリーンです。そしてMETRは9月にそのページの更新を停止しました。しかし、線がほぼでも続くなら、エージェントは2028年頃に人間の仕事の1ヶ月分を半分の確率で処理できるようになります。私の2031年の火曜日はそこから来ています。空中に浮かべて描いたわけではありません。対数スケールのグラフから引っ張り出したのです。つまり、軸付きの空中に浮かべたものです。

これらのものを構築している企業は、すでにそのバージョンを体験しています。Googleは2024年10月に、新しいコードの4分の1以上がAIによって生成されたと述べ、6ヶ月後には「30%をはるかに超える」と述べました。2025年3月、AnthropicのDario Amodeiは、AIが3〜6ヶ月以内にコードの90%を書くだろうと予測しました。それは早すぎました。しかし、2026年5月までに、Anthropicは自社のコードベースにマージされたコードの80%以上がClaudeによって書かれたと述べました。

コードが安くなると、キューが動く

プロセスの1つのステップを速くすると、作業は次の最も遅いステップの前に積み上がります。土曜日の夜にキッチンで働いたことがある人なら誰でもこれを理解しています。グリルの速度を上げると、プレートがパスで待機し始めます。

それがソフトウェアチームに起こっていることです。2025年、Faros AIは1,255チームの10,000人以上の開発者のテレメトリを調査しました。AI採用率の高いチームの開発者は、タスクを21%多く完了し、プルリクエストを98%多くマージしましたが、レビュー時間は91%増加しました。

Farosは2026年に22,000人の開発者で再度調査を実施しました。開発者あたりのタスク完了数は34%増加しましたが、これは素晴らしいように聞こえますが、残りを読むとそうではありません。中央値のレビュー時間は5倍に増加しました。レビューなしでマージされるプルリクエストが31%増加し、プルリクエストあたりのインシデントの比率は3倍以上に増加しました。

コードは安くなりましたが、読むコストは高くなり、一部のチームは静かに読むのをやめました。それは、コードが常に良いとは限らないため、重要です。Veracodeは2025年に80のコーディングタスクで100以上の言語モデルをテストし、結果の45%にセキュリティ上の欠陥がありました。GitClearは、変更されたコードにおけるコピー＆ペースト行の割合が2021年の8.3%から2024年には12.3%に増加したのに対し、リファクタリングから得られるような移動コードの割合は4分の1から10%未満に減少したことを発見しました。

メンテナーにも思いを馳せてください。curlを率いるDaniel Stenbergは、2025年5月に「AIスロップ」のバグレポートを提出した人々を禁止し始め、「プロジェクトは事実上DDoS攻撃を受けている」と書きました。2026年1月にcurlはバグバウンティを停止しました。

何を構築するか決定する

それを書き留める

コードを書く

レビューする

動作を確認する

出荷して実行する

今日：コードは人々が読むよりも速く到着するため、プルリクエストはレビューを待ちます。

バーのサイズは例示であり、測定値ではありません。2026年の形状は上記のFaros AIの数値に従っています。2031年の形状は私の推測です。年を切り替えて、どこで作業が待っているかを確認してください。

Fred Brooksは1986年にこのバージョンの到来を予見しました。「No Silver Bullet」で、彼はソフトウェアの難しさを2つの山に分け、アリストテレスの言葉を借りて、本質と事故としました。事故とは、構文、定型的なコード、ビルドとの戦いなど、私たちのツールが私たちに引き起こす問題です。本質とは、彼が「この概念的な構造の仕様、設計、およびテスト」と呼んだもので、これは、そのものが何をすべきかを理解することの、派手な言い方です。AIは事故の部分に非常に長けています。本質とは、午前2時13分の払い戻しの質問であり、それはまだあなたの机の上にあります。

私たちが切り落としているかもしれない段階

これは私が最も気に入らないデータの一部です。

2025年8月、Erik Brynjolfssonとスタンフォード大学デジタル経済学研究所の2人の同僚は、ADPの給与データを使用して、誰が雇用されているかを調査しました。22歳から25歳のソフトウェア開発者の雇用は、2022年後半のピークから約20%減少していました。年配の開発者には顕著な変化は見られませんでした。

彼らは今年8月に、2026年6月までのデータでこの研究を更新しました。AIにさらされている職種の若手労働者は、露出の少ない同僚のペースを維持していた場合よりも19%減少しています。経験豊富な労働者には、同等のギャップは見られません。この効果の大部分は、企業がそもそも若者を少なく採用していることから来ています。

市場の残りの部分も活況を呈しているわけではありません。Indeedのソフトウェア開発求人掲載数の指数は、2025年5月に39%低下した後、2020年2月比で約21%下回っています。

スタンフォードの著者たちは、彼らの発見を因果関係ではなく記述的なものと呼ぶことに慎重であり、2022年以降には他にも多くのことが起こっています。金利が上昇し、多くの企業がパンデミック中に人を雇いすぎました（Indeedの指数は2022年初頭に2020年レベルの2倍以上に達しました）。しかし、このパターンは、エージェントが得意なことと不快なほどよく一致しています。それは、かつてチームの新人にあてがっていた、小さく明確に定義されたチケットです。

シニアエンジニアは、主に実務チームでのジュニアとして、オンザジョブで育成されます。面倒なチケットをこなし、一度本番環境を壊し、親切な誰かがその理由を説明してくれるのです。エージェントが面倒なチケットをすべて引き受けるなら、次のシニアエンジニアはどこから来るのでしょうか？コードをほとんど書いたことがない人が、コードをうまくレビューするのは難しいです。

私には明確な答えはありません。私の推測では、2035年にうまくいくチームは、2026年にジュニアを採用し続け、彼らに異なる徒弟制度を与えたチームでしょう。それは、シニアの隣でエージェントの作業をレビューし、エンドツーエンドで1つの小さなシステムを所有し、エージェントが構築するための仕様とテストを書くことです。それらの仕様とテストを書くことは、実際の仕事です。それはその仕事になるかもしれません。

2031年の5つの予測

さて、ここからが予測の部分です。このページをブックマークして、2031年に戻って私を笑ってください。

チームは小さくなり、その数は非常に多くなります。 Y CombinatorのJared Friedmanによると、2025年冬のバッチの4分の1は、約95%がAI生成されたコードベースを持っていました。2月には、Blockは4,000人近くを解雇し、Jack DorseyはAIツールと「より小さくフラットなチーム」を指摘しました。私はここで間違っているかもしれませんが、それでも全体としてソフトウェアの仕事が減るとは思いませんし、米国労働統計局も同様で、2025年から2035年にかけてソフトウェア開発者、QAアナリスト、テスターの雇用が10%増加すると予測しています。

何かが安くなると、私たちはそれをより多く欲しがる傾向があります。経済学者はこれをJevonsのパラドックスと呼びます。William Stanley Jevonsは1865年に、より効率的な蒸気機関は英国にさらに多くの石炭を燃やさせると主張しました。かつてチームが4分の1の時間を要したソフトウェアは、1人で1週間で済むようになり、誰も解決する余裕がなかった多くの問題が突然価値を持つようになります。

仕様とテストがソースになります。 今日、私たちはコードを所有するもの、仕様を誰も読まないドキュメントとして扱っています。私はそれが逆転すると考えています。仕様とテストは、レビューして議論する対象となり、コードはコンパイラの出力に近くなります。開いて検査することはできますが、手で編集することはめったにありません。（はい、これは1954年の約束と同じです。今回は定着するかもしれません。）

一人の視聴者のためのソフトウェア。 私の毎晩のエージェントは、私自身でさえ求めていないものを作り出します。その中には素晴らしいものもあります。動作するツールが4分の1ではなく1晩のコストで済むなら、人々はスプレッドシートを作るのと同じようにソフトウェアを作成するでしょう。つまり、1つの問題と1人の人物のためであり、それが終われば捨てられます。

コードを読むことがキャリアになります。 私たちはコードを書くことを中心にキャリアを築いてきましたが、読むことを中心にしたキャリアはほとんどありません。私はそれが変わると予想しています。「検証エンジニア」のようなものが求人サイトに掲載され、レビューアに録音、危険な行、エージェントが書かなかったテストを示す、はるかに優れたツールが登場するでしょう。Farosの数字は、2031年どころか、今すぐにでも必要であることを示しています。

すべての変更にはラベルが付きます。 プルリクエストには、誰がまたは何がそれを書いたか、誰がチェックしたか、そして実際に検証されたものは何かを日常的に示すようになると考えています。私はすでにその小さなバージョンを実行しています。私の毎晩のエージェントがビルドしたすべてのプロジェクトは、READMEとこのサイトでそれを表示しています。

火曜日に戻って

FORTRANは確かに一種のコーディングを排除しました。それはコーダーを排除しませんでした。それは、より困難な問題に取り組む、さらに多くのコーダーを生み出し、デバッグもそれに伴いました。

AIも同様のことを、より速く、より乱雑に行うと私は考えています。2031年の開発者は、何が存在すべきかを決定し、機械がそれを構築できるほど明確に説明し、返ってきたものが正しいかを確認するのに一日を費やします。それは常に難しい部分でした。私たちはタイプすることに忙しかったので、それに費やす時間が少なかっただけです。

あなたの火曜日は今、どのようになっていますか？書くことよりもレビューすることの方が多いですか？コメントで教えてください。私の予測がすでに間違っているかどうか知りたいです。

Written by hrih