「コードを書く量は減っているのに、こなせる仕事の規模は増えている」——Andrej Karpathyが2026年4月30日のSequoia Ascent 2026で語ったのは、そんな開発現場の話です。AIツールの進化は「既存の仕事を速くする」だけでなく、ソフトウェアの構造そのものを変えつつあります。

この記事でわかること：

  • Software 1.0・2.0・3.0の違いと、今どの段階にいるか
  • 「MenuGen」が示すアプリ消滅の具体的なメカニズム
  • 2025年12月の変曲点と、その後に変わった開発の単位
  • バイブコーディングとエージェンティックエンジニアリングの違い
  • 稀少になるスキルとコモディティ化するスキル
Sequoia Ascent 2026 summary
Summary of my talk at Sequoia Ascent
karpathy

ソフトウェアの3段階進化

Karpathyはソフトウェアの歴史を3段階に整理します。

Software 1.0は、人間が明示的にコードを書く時代です。PythonでもGoでも、コンピュータに渡す命令をそのまま言語で記述します。Software 2.0は、データセットと目的関数を設計し、ニューラルネットワークを訓練することでプログラムを「学習」させる時代。Teslaの自動運転開発でも、手書きのC++ルールがどんどんニューラルネットワークに置き換わっていく現場をKarpathy自身が経験しています。

Software 3.0は、LLMをプロンプトで操作する時代です。コンテキストウィンドウに何を置くかが、LLMというインタープリタへの命令になります。ゴール、サンプルコード、ドキュメント、エラーメッセージ——これらを渡すだけで有用な計算が返ってくる。プログラミング言語は事実上、自然言語になりました。

この変化を象徴するのがOpenClawのインストール方法です。複数のプラットフォームに対応するシェルスクリプトは環境差異を吸収するため肥大化しますが、OpenClawはその代わりにエージェントへ貼り付けるテキストブロックとしてインストール手順を提供しました。エージェントは環境を読み取り、エラーをデバッグし、設定を完了させます。これがSoftware 3.0の「プログラム」の形です。

MenuGenが示す「アプリが消える瞬間」

Karpathyが作ったMenuGenというアプリの話は、Software 3.0の本質を鮮やかに描き出しています。

レストランのメニュー写真を撮影すると、料理名をOCRで抽出し、料理の画像を生成して表示するアプリです。フロントエンドのコード、API連携、画像生成サービス、デプロイ設定、認証、決済処理——従来のWebアプリ開発に必要な要素がすべて詰まっていました。

ところが後に、同じことをはるかに単純に実現できることに気づきます。マルチモーダルモデルにメニュー写真を渡し、料理の画像をメニュー上に直接重ねて表示するよう指示する。アプリケーション層は消え、モデルが入力メディアを直接出力メディアへ変換します。

「このコードの多くは存在すべきではなかった。ニューラルネットワークが仕事のほとんどをやってしまう」とKarpathyは語っています（参考）。

AIが既存のアプリを速く作るツールだという話ではありません。一部のアプリはモデルに吸収され、アプリとして存在すべきでなくなる——これが最も重要な示唆です。

2025年12月の変曲点

Karpathyが「これまでで最も遅れを感じたプログラマー」と表現したのは、2025年12月に訪れた変化です。

それまでのClaude Code、Codexといったエージェントツールは役に立ちましたが、生成されたコードの修正が頻繁に必要でした。12月を境に、生成されるチャンクが大きく、整合性が高く、信頼できるものになった。最後に自分で修正した時をいつか思い出せなくなったと言います。

プログラミングの単位が変わりました。「この機能を実装して」「このサブシステムをリファクタリングして」「テストを書いて、実行して、失敗を直して」——コードを1行ずつ書くのではなく、エージェントへの「マクロアクション」を設計する仕事になっています。プログラマーの役割は、コードライターからエージェントのオーケストレーターへと移行しています。

バイブコーディングとエージェンティックエンジニアリングの違い

Karpathyは関連するが異なる2つの概念を区別しています。

バイブコーディング（Vibe Coding）はフロアを上げるものです。やりたいことを言葉で伝えるだけでソフトウェアが作れるようになりました。プロトタイプや個人ツールには十分です。

エージェンティックエンジニアリング（Agentic Engineering）はシーリングを上げるものです。不確実なエージェントを束ねながら、正確性・セキュリティ・品質・保守性を維持する専門的な規律です。仕様の設計、計画の監督、差分のレビュー、テスト作成、評価ループの構築、権限管理——これらがエージェンティックエンジニアの仕事になります。

Karpathyはエージェントが書いたStripe決済コードの例を挙げています。エージェントはStripeのメールアドレスとGoogleのログインメールを同一視して照合するコードを書きました。動くコードですが、システム設計としては誤りです。2つのメールが異なれば照合は失敗します。「エージェントが生成したコードを盲目的に受け入れるのではなく、人間がシステムの形と設計境界を判断しなければならない」というのがKarpathyの主張です。

稀少になるスキル・コモディティ化するスキル

Software 3.0の世界で何が変わるかを、Karpathyは明確に整理しています。

希少度が下がるのは、コード生成、APIの詳細記憶、ボイラープレートコード、単純な繰り返し変換処理です。エージェントがこれらを担います。

希少度が上がるのは、理解力と判断力、評価ループの設計、セキュリティ・権限設計、システム境界の定義、エージェントの調整・管理、「モデルが外れているとき」を認識する感覚です。

「思考を外注することはできる。しかし、理解を外注することはできない」（参考）——エージェントに何をすべきか指示し、どの結果が怪しいか判断し、どのトレードオフが許容できるかを決めるには、人間の理解が不可欠です。

Karpathyはこれを採用選考にも応用しています。コーディングパズルで篩にかけるのではなく、「エージェントを使って実際のプロジェクトを構築し、デプロイし、セキュアにし、さらにエージェントで攻撃してみる」テストの方が実態に合うと述べています。

エージェントが使いやすいインフラを設計する

Karpathyはもう一つの視点を提供しています。多くのソフトウェアはまだ人間がクリックすることを前提に作られています。しかし、ユーザーが「人間のエージェント」になるとき、製品に求められるものが変わります。

Markdown形式のドキュメント、CLI、API、MCPサーバー、構造化されたログ、機械可読なスキーマ——これらがエージェント向けの「センサーとアクチュエーター」です。センサーは世界の状態をデジタル情報に変換し、アクチュエーターはエージェントが何かを変えるための手段です。今後のスタックは、エージェントがセンサーとアクチュエーターを通じて人間と組織のために動く形になります。

起業家・開発者にとってのKarpathyの問いかけはシンプルです。「既存のワークフローをどう高速化するか」ではなく、「ニューラルネットワークが直接担えるようになったとき、どのアプリが消えるか」を問うことがSoftware 3.0時代のスタート地点です。