# Vibe coding は床を、agentic engineering は天井を上げる——Karpathy が語る Software 3.0 と「指示の粒度」の話 ## 導入 2026 年 4 月の Sequoia AI Ascent で、Andrej Karpathy が Stephanie Zhan との fireside chat に登壇しました。本人の [bearblog 投稿](https://karpathy.bearblog.dev/sequoia-ascent-2026/) が要点を整理しているのですが、結論を一言にすると **「Vibe coding は床を上げる。Agentic engineering は天井を上げる」** という対比です。 この一行は、ここ数年「AI でコードが書ける」と言われ続けてきた話を、一段上のレイヤーに引き上げます。本稿では、彼が示した枠組み（Software 3.0、macro actions、jagged intelligence）を整理し、実装現場でこの先何を変えるべきかを書き残しておきます。 ## Vibe coding と agentic engineering は別物 Karpathy は今回の発表で、Vibe coding は「終わった」とまでは言っていません。彼が強調したのは、**Vibe coding と agentic engineering は別の役割を担う** ということです。 - **Vibe coding**：誰もが「こういうものが欲しい」と説明するだけでソフトウェアを作れるようにする動き。開発の **下限**（floor）を上げる。 - **Agentic engineering**：プロのソフトウェア品質基準（セキュリティ・テスタビリティ・保守性）を保ちながら、エージェントの監督と検査をエンジニアリングの規律として組み立てる動き。**上限**（ceiling）を上げる。 > "Vibe coding raises the floor. Agentic engineering is about extrapolating the ceiling." 10 倍エンジニアという言葉が長らく使われてきましたが、agentic engineering を組み立てられる人は **「10 倍を遥かに超えるところまでピークが伸びる」** とも語っています。プロが磨くのは「より速く書く力」ではなく「監督・指示・検査の力」になっていく、という見立てです。 ## December 2025 が転換点だった ターニングポイントとして語られたのが 2025 年 12 月。それ以前の agentic coding ツールは「便利だけど散らかっている」状態で、生成された差分を直し続ける時間が無視できないコストでした。それが 2025 年 12 月以降、**生成されたコードのチャンクが一貫して使える品質に達した** と Karpathy は表現しています。 > "the chunks just came out fine. Then I kept asking for more and they still came out fine." これは単なるモデル性能の話ではなく、「人間がエージェントに渡す作業の単位」を変えました。以前はコード 1 行〜数行レベルの提案を採否していたのが、いまは macro action と呼ぶレベルに移っています。 ## 指示の単位は「macro action」へ Karpathy が挙げた macro action の例は次のようなものです。 - 「この機能を実装する」 - 「このサブシステムをリファクタリングする」 - 「このライブラリを調査する」 - 「このサービスをセットアップする」 - 「テストを書き、実行し、失敗を直す」 - 「複数アプローチを比較して、計画を提案する」 「行を書く」のではなく、「**実装単位を委譲する**」のがエンジニアの仕事になります。指示の粒度の進化を整理すると次のとおりです。 ```mermaid flowchart LR A[Software 1.0<br/>人間が 1 行ずつ書く] B[補完／提案時代<br/>1 行〜数行を採否] C[2025/12 以降<br/>機能・サブシステム単位を委譲] A --> B --> C style C fill:#fff3b0 ``` 実務上の意味は明確で、**「ソースコードを 1 文字ずつ書く能力」よりも「何を委譲し、どう検査するか」の能力に重心が移る** ということです。 ## Software 1.0 / 2.0 / 3.0 という整理 Karpathy はソフトウェアの世代を 3 つに分けています。 | 世代 | 何を書くか | レバー | |---|---|---| | **1.0** | 人間が明示的にコードを書く | プログラミング言語 | | **2.0** | データセット・損失関数・ニューラルネット | 学習データと目的関数 | | **3.0** | プロンプト・コンテキスト・ツール・例・メモリ・指示で LLM をプログラミング | コンテキストウィンドウ | 3.0 では **コンテキストウィンドウが「主たるレバー」** になります。何をシステムプロンプトに置き、何を Tools として渡し、何をメモリに刻むか——その設計判断が、出力の品質を決めます。Claude Code や Codex が「コンテキストの組み立て方」を競い合っているのは、ここに直結する話です。 ## Jagged intelligence——LLM は「ギザギザ」している もう 1 つ重要な概念が **jagged intelligence**（ギザギザの知性）です。LLM の能力は領域ごとに極端な凹凸があります。Karpathy の表現を借りると、**「数学やコードのように検証可能で学習が密な領域では尖り、検証しづらい領域では雑なまま」** なのです。 100K 行のコードベースをリファクタしながらゼロデイ脆弱性を見つけるのに、「車を 50m 走らせて洗車場に行ってください」と平気で指示する、というのが彼の比喩です。プロが組み立てる agentic engineering は、**この凹凸を前提に、エージェントを置く場所と置かない場所を分ける** 設計をします。 ## 実用アドバイス（明日から試せる内容） 1. **委譲する単位を「macro action」にそろえる**：1 行単位の補完で立ち止まらず、「機能を実装する」「テストを書いて通す」レベルの指示に切り替えます。Claude Code / Codex の `plan → run → verify` の3段階を使い倒すと、自然にこの粒度になります。 2. **検査の仕組みを先に置く**：generate と verify を別の責務に分け、テスト・lint・型・diff レビューを「自動で回るループ」として用意します。エージェントの jagged な挙動を捕まえるのは、人間の目より自動検証の方が向いています。 3. **コンテキスト設計を「資産」として扱う**：プロンプト・Tools・MEMORY ファイル・サブエージェント定義は、コードと同じくバージョン管理し、レビューの対象にします。これが Software 3.0 における「ソースコード」です。 4. **得意な領域だけ任せる**：jagged intelligence の前提に立ち、検証可能で学習が密な領域（コーディング・テスト・スキーマ移行など）から委譲を広げます。曖昧な意思決定は人間に残します。 ## まとめ - Vibe coding は床を上げる動き、agentic engineering は天井を上げる動きで、別物として扱うのが整理しやすいです - 2025 年 12 月以降、人間がエージェントに渡す単位は「行」から「機能・サブシステム」（macro action）に移りました - Software 3.0 ではコンテキストウィンドウがレバーになり、プロンプト・Tools・メモリの設計が「ソースコード」と同等の資産になります - LLM の能力はギザギザなので、検証可能な領域から委譲を広げ、曖昧な判断は人間に残す配置を設計します

flowchart LR
    A[Software 1.0<br/>人間が 1 行ずつ書く]
    B[補完／提案時代<br/>1 行〜数行を採否]
    C[2025/12 以降<br/>機能・サブシステム単位を委譲]
    A --> B --> C
    style C fill:#fff3b0