Andrej Karpathy『Vibe Codingの次はAgentic Engineeringである』

Sequoia AI Ascent 2026で最も共有されたセッションの一つが、Andrej Karpathyによるこの対談である。表面的にはAIコーディングの話に見えるが、中心にあるのは「ソフトウェア開発の責任をどこに置くか」という実務の問いである。

Karpathyの主張は明快だ。vibe codingは入口として強力であり、誰でもソフトウェアらしきものを作れるようにする。しかし本番の開発で問われるのは、その先にあるagentic engineeringである。違いはAIに任せる量ではない。品質責任を手放さずに、どこまで大きな仕事を委任できるかである。

この対談を時系列で追うと、Software 3.0、vibe coding、採用、インフラ、教育の話が散らばって見える。だが、一本の線で読むと「コードを書く人」から「エージェントに仕事を渡し、検証し、理解を保持する人」への移行である。本記事ではこの線に沿って整理する。

“

この記事は Andrej Karpathy: From Vibe Coding to Agentic Engineering の内容を基に、2026-05-09 取得の英語字幕から再構成している。

---

読む前の補助線

この動画を読むときの中心問いは「AIにどこまで仕事を渡し、どこから人間が品質責任を持つべきか」である。動画内では会話の流れに沿って論点が移るが、記事化するときは順番をそのまま追うより、開発チームとプロダクト責任者が判断に使える単位へ並べ替えた方が理解しやすい。

特に注意したいのは、「agentic engineering」を大きな流行語として受け取らないことだ。今回の対談で価値があるのは、未来予測そのものより、どの条件が変わり、どの責任が残り、どの組織能力を先に作るべきかが見えてくる点にある。

逆に読み違えると、速く作れたことを、そのまま正しく作れたことと取り違えることが起きる。だから本記事では、動画の発言を単純な時系列ではなく、テーマごとに整理しながら、spec、テスト、レビュー、権限設計、そして開発者自身の理解へ接続して読む。AIに渡す作業を大きくするほど、依頼文、検証手順、ロールバック条件まで同じ単位で設計する必要がある。

また、この一本だけで閉じて読むより、Sequoia AI Ascent 2026の他セッションと並べると位置づけがはっきりする。ある動画はモデル能力を語り、別の動画は開発組織やロボティクス、インフラ、運用を語る。本記事ではその中で、Andrej Karpathyの発言がどの論点を担っているのかを明確にする。

---

2024年末に起きたのは「補助」から「委任」への断層である

Karpathyは冒頭で、ここ数カ月でプログラマーとしてこれまで以上に遅れを感じたと語る。これは単にモデルが賢くなったという話ではない。開発者がAIに渡せる作業単位が変わった、という話である。

まず押さえるべきは、この章の話が単独の予測ではなく「AIにどこまで仕事を渡し、どこから人間が品質責任を持つべきか」という問いの入り口になっている点である。何が新しくなったのかと同時に、何をまだ人間側で設計しなければならないのかを分けて読む。

以前のAIコーディングは、コード断片を出す補助輪に近かった。

人間は提案された関数やUI片を読み、壊れている箇所を直し、最後は自分の手で辻褄を合わせていた。便利ではあるが、責任の中心は完全に人間側に残っていた。

その段階では開発プロセスは大きく変わらない。検索や補完が強くなっただけで、設計、実装、検証、統合の大半は従来のままである。

実務では、この主張を「何が可能になったか」だけで終わらせない方がよい。AIに渡す作業を大きくするほど、依頼文、検証手順、ロールバック条件まで同じ単位で設計する必要がある。そう読むと、この論点は新機能の紹介ではなく、次に整えるべき開発・事業プロセスの話になる。

2024年末ごろから、KarpathyはAIに追加の塊を渡しても通る体験を持ち始めた。

一つの修正だけでなく、周辺ファイルを読み、環境を観察し、エラーを見て、再実行する。こうした連続作業がつながったとき、AIは補助ではなく委任先になる。

開発者の驚きは、コード生成の巧さよりも、タスクの連なりをAIが抱え始めたことにある。ここがvibe coding以降の大きな断層である。

開発チームとプロダクト責任者にとって重要なのは、この変化を個人の工夫で吸収しないことである。spec、テスト、レビュー、権限設計、そして開発者自身の理解を組織の標準に近づけるほど、同じモデルやツールを使っても成果の安定度が変わる。

ただし委任が可能になるほど、責任の所在は曖昧になりやすい。

AIが作ったものを人間が深く読まずに受け入れると、局所的には動くが、設計上は脆いものが混ざる。Karpathyはこの危うさを、楽観的にではなく実務的に扱っている。

したがって本当の論点は、AIがどこまで作れるかではない。AIに大きく任せながら、どうやって品質責任を人間と組織の側に残すかである。

ここで焦点を外すと、速く作れたことを、そのまま正しく作れたことと取り違えることにつながる。だからこの論点は、動画内の一発言ではなく、意思決定の前提を点検する材料として読む方がよい。

この視点で読むと、対談全体はAIツール礼賛ではなく、委任可能性が上がった時代の開発規律についての話になる。

---

Software 3.0では「コードを書く」より「文脈を渡す」が中心になる

Karpathyは以前からLLM is the new computerと説明してきた。今回の対談では、その実務的な意味がかなり具体的に語られている。Software 3.0とは、コードを書かなくなるという意味ではない。コードと同じくらい、文脈をどう渡すかが重要になるという意味である。

ここでは「agentic engineering」を、抽象的なキーワードではなく実務上の判断材料として扱う。動画の順番に沿って理解するより、開発実務・AIエージェントで起きる責任分担の変化として見る方が、論点の重みがつかみやすい。

Software 1.0では、人間が明示的なルールをコードとして書いた。

入力、分岐、状態、例外処理を人間が細かく決める。クロスプラットフォームなインストーラを作るなら、OS差分や依存関係を巨大なシェルスクリプトに詰め込む発想になる。

これは今も必要な場面があるが、すべてをその形式で書くと、環境差分に弱く、保守が重く、agentが持つ観察能力を使い切れない。

開発チームとプロダクト責任者にとって重要なのは、この変化を個人の工夫で吸収しないことである。spec、テスト、レビュー、権限設計、そして開発者自身の理解を組織の標準に近づけるほど、同じモデルやツールを使っても成果の安定度が変わる。

Software 3.0では、実行系としてのLLMに文脈を渡す。

Karpathyが挙げたOpenClawの例では、インストール手順は複雑なスクリプトではなく、agentにコピーして渡すテキストとして考えられる。agentは環境を見て、必要な操作を判断し、デバッグしながら進む。

ここでプログラミングのレバーは、コードそのものからコンテキストウィンドウへ移る。何をコピーしてagentに渡すべきかが、新しい設計対象になる。

ここで焦点を外すと、速く作れたことを、そのまま正しく作れたことと取り違えることにつながる。だからこの論点は、動画内の一発言ではなく、意思決定の前提を点検する材料として読む方がよい。

MenuGenの例は、さらに極端な転換を示している。

従来なら、メニュー画像をOCRし、品名ごとに画像生成し、UIに重ねるアプリを作りたくなる。だがモデルに画像を渡して、画像として返させるなら、中間アプリ自体が不要になる可能性がある。

AIを既存ソフトの高速化として見るだけでは不十分である。Software 3.0では、中間アプリを作るべきか、そもそもモデルに直接仕事を渡すべきかから問い直す必要がある。

実務では、この主張を「何が可能になったか」だけで終わらせない方がよい。AIに渡す作業を大きくするほど、依頼文、検証手順、ロールバック条件まで同じ単位で設計する必要がある。そう読むと、この論点は新機能の紹介ではなく、次に整えるべき開発・事業プロセスの話になる。

この発想は、プロダクト設計にも効く。機能を増やす前に、その機能が本当にUIとして存在すべきか、agentに渡す文脈として存在すべきかを分けるべきである。

---

vibe codingは入口であり、agentic engineeringは品質責任の技法である

この対談の核は、vibe codingとagentic engineeringを分けた点にある。両者は対立概念ではない。前者がソフトウェア作成の入口を広げ、後者が本番品質を守る。

この章の論点は、技術の優劣だけでは完結しない。spec、テスト、レビュー、権限設計、そして開発者自身の理解をどう整えるかまで含めて読むと、対談の発言がそのまま組織設計やプロダクト設計の宿題に変わる。

vibe codingは床を上げる。

プログラミング経験が浅い人でも、アプリを作り、画面を直し、動くものを試せる。これは大きな民主化であり、創作や検証の速度を上げる。

ただし、床が上がることと天井が上がることは違う。誰でも作れるようになるほど、プロが担うべき品質責任はむしろ鮮明になる。

ここで焦点を外すと、速く作れたことを、そのまま正しく作れたことと取り違えることにつながる。だからこの論点は、動画内の一発言ではなく、意思決定の前提を点検する材料として読む方がよい。

agentic engineeringは、従来のprofessional softwareのquality barを落とさないための規律である。

Karpathyは、vibe codingによって脆弱性を入れてはいけない、以前と同じように自分のソフトウェアに責任を持つ必要があると語る。速くなることは許されるが、責任が消えるわけではない。

ここではspec、テスト、レビュー、権限設計、ログ、ロールバックが中心になる。agentを使うほど、従来より軽くなる領域と、従来より厳密にすべき領域を分ける必要がある。

実務では、この主張を「何が可能になったか」だけで終わらせない方がよい。AIに渡す作業を大きくするほど、依頼文、検証手順、ロールバック条件まで同じ単位で設計する必要がある。そう読むと、この論点は新機能の紹介ではなく、次に整えるべき開発・事業プロセスの話になる。

採用や評価も、小さなパズルを解く能力から、大きな仕事を安全に仕上げる能力へ移る。

Karpathyは従来型のコーディング面接への違和感を示す。短時間でアルゴリズム問題を解けるかより、agentと一緒に大きなプロジェクトを作り、攻撃や異常系に耐えられるかが重要になる。

開発組織は、AI利用を禁止するか許可するかではなく、AIを使ったうえで品質をどう測るかを設計しなければならない。

開発チームとプロダクト責任者にとって重要なのは、この変化を個人の工夫で吸収しないことである。spec、テスト、レビュー、権限設計、そして開発者自身の理解を組織の標準に近づけるほど、同じモデルやツールを使っても成果の安定度が変わる。

vibe codingが「作れる人」を増やす運動だとすれば、agentic engineeringは「壊さずに作れる組織」を増やす運動である。

---

検証可能性が高い領域から、agentic engineeringは進む

Karpathyは、なぜコードや数学の領域で進歩が目立つのかをverifiabilityで説明する。正しさを確認しやすい領域ほど、AIは反復しやすく、改善しやすい。

ここで見たいのは、話者の断言の強さよりも、その断言が成り立つ条件である。速く作れたことを、そのまま正しく作れたことと取り違えることを避けるには、便利になった部分と、むしろ重くなる判断を分ける必要がある。

コードは、出力の正しさを比較的確認しやすい。

ビルドが通る、テストが通る、型が合う、差分が見える。もちろん完全ではないが、少なくともモデルが試行錯誤するための外部フィードバックがある。

agentic engineeringでは、この外部フィードバックを意図的に増やすことが重要になる。AIに任せる前に、AIが自分で失敗を検知できる環境を作るべきである。

実務では、この主張を「何が可能になったか」だけで終わらせない方がよい。AIに渡す作業を大きくするほど、依頼文、検証手順、ロールバック条件まで同じ単位で設計する必要がある。そう読むと、この論点は新機能の紹介ではなく、次に整えるべき開発・事業プロセスの話になる。

検証できないものを丸投げすると、速度ではなく不確実性が増える。

プロダクトの意図、顧客との約束、セキュリティ上の許容範囲、法務的な判断は、テストだけでは閉じない。AIがもっともらしく答えても、正しいとは限らない。

したがって、agentに渡す仕事は、検証可能な小さなループへ分割する必要がある。人間は最終判断だけでなく、検証可能な仕事の形を設計する責任を持つ。

開発チームとプロダクト責任者にとって重要なのは、この変化を個人の工夫で吸収しないことである。spec、テスト、レビュー、権限設計、そして開発者自身の理解を組織の標準に近づけるほど、同じモデルやツールを使っても成果の安定度が変わる。

この視点は、開発基盤そのものをagent-nativeに変える。

人間向けの管理画面を開き、設定を探し、DNSや権限を手でつなぐ前提では、agentは能力を出しにくい。agentが読むドキュメント、実行できる安全なコマンド、監査できるログが必要になる。

今後の開発基盤の差は、UIの美しさだけでなく、agentに渡したときにどれだけ安全に完了できるかで決まる。

ここで焦点を外すと、速く作れたことを、そのまま正しく作れたことと取り違えることにつながる。だからこの論点は、動画内の一発言ではなく、意思決定の前提を点検する材料として読む方がよい。

Karpathyが言う「what is the thing I should copy paste to my agent?」は、冗談ではなく設計原則である。ドキュメント、API、権限、テストは、agentに渡せる形へ変わる。

---

人間の仕事はAPI暗記ではなく、spec・taste・understandingに寄る

では人間の役割は何になるのか。Karpathyの答えは、意外なほど保守的である。人間は不要にならない。むしろ、人間が保持すべき責任がはっきりする。

開発チームとプロダクト責任者にとって、この章は採用すべきツール名を決める話ではない。AIに渡す作業を大きくするほど、依頼文、検証手順、ロールバック条件まで同じ単位で設計する必要がある。 その視点で読むと、動画内の具体例が次の運用設計につながる。

API名やボイラープレートの暗記価値は下がる。

agentは細かな引数、ライブラリ差分、CLIオプションを調べながら実装できる。人間がすべてを覚えている必要は薄れる。

一方で、データモデル、ID設計、セキュリティ境界、性能特性の理解は下がらない。むしろ、agentが局所最適を作るほど、人間の構造理解が重要になる。

開発チームとプロダクト責任者にとって重要なのは、この変化を個人の工夫で吸収しないことである。spec、テスト、レビュー、権限設計、そして開発者自身の理解を組織の標準に近づけるほど、同じモデルやツールを使っても成果の安定度が変わる。

Karpathyはagentを、優秀だが危ういインターンのように扱っている。

対談で触れられたメールアドレスの突き合わせの例では、agentは一見動く処理を作るが、永続IDやアカウント統合の設計としては危うい判断をする。

だから必要なのは細かなマイクロマネジメントではなく、最初に壊れないspecを与えることである。人間は実装者から、意図と制約の設計者へ寄る。

ここで焦点を外すと、速く作れたことを、そのまま正しく作れたことと取り違えることにつながる。だからこの論点は、動画内の一発言ではなく、意思決定の前提を点検する材料として読む方がよい。

tasteも残る。

ソフトウェアは動けばよいわけではない。どの体験が自然か、どの複雑さを隠すべきか、どの挙動が顧客の信頼を壊すかは、テストだけでは決められない。

agentic engineeringにおける人間の価値は、実装速度ではなく、よい完成形を見分ける力に移る。これはプロダクト、デザイン、エンジニアリングをまたぐ能力である。

実務では、この主張を「何が可能になったか」だけで終わらせない方がよい。AIに渡す作業を大きくするほど、依頼文、検証手順、ロールバック条件まで同じ単位で設計する必要がある。そう読むと、この論点は新機能の紹介ではなく、次に整えるべき開発・事業プロセスの話になる。

人間の仕事は軽くなるのではない。低レイヤーの暗記から、意図、制約、品質、完成度を定義する方向へ移るのである。

---

thinkingは外注できても、understandingは外注できない

対談の終盤でKarpathyが強調するのが、理解の問題である。AIに考える作業を渡すことはできる。しかし、理解そのものを手放すと、agentを正しく使えなくなる。

最後に重要なのは、学びを一般論で終わらせないことである。この章の主張を「明日から何を変えるか」へ落とすなら、spec、テスト、レビュー、権限設計、そして開発者自身の理解を点検することが出発点になる。

thinkingの一部は外注できる。

選択肢を列挙する、実装案を比較する、エラーを読む、テストケースを追加する。こうした思考作業は、agentにかなり渡せるようになっている。

これは大きな生産性向上である。人間はゼロから考える代わりに、AIが出した候補を評価し、修正し、方向づけることができる。

ここで焦点を外すと、速く作れたことを、そのまま正しく作れたことと取り違えることにつながる。だからこの論点は、動画内の一発言ではなく、意思決定の前提を点検する材料として読む方がよい。

しかしunderstandingを外注すると、判断の足場が消える。

なぜその設計なのか、どこが危険なのか、どの前提が変わると壊れるのかを理解していなければ、AIの出力を評価できない。レビューは形式だけになる。

これは教育にも影響する。初学者はAIで速く作れるが、基礎理解を飛ばすと、あとでagentを監督できない。学習の目的は暗記ではなく、判断可能性を得ることになる。

実務では、この主張を「何が可能になったか」だけで終わらせない方がよい。AIに渡す作業を大きくするほど、依頼文、検証手順、ロールバック条件まで同じ単位で設計する必要がある。そう読むと、この論点は新機能の紹介ではなく、次に整えるべき開発・事業プロセスの話になる。

開発組織にとってのボトルネックは、理解を保持したまま委任する仕組みである。

単にAI利用量を増やすだけなら簡単である。難しいのは、仕様、レビュー、設計判断、事後検証を通じて、組織の理解が失われないようにすることだ。

agentic engineeringはツール導入ではなく、理解を薄めずに委任量を増やす組織設計である。

開発チームとプロダクト責任者にとって重要なのは、この変化を個人の工夫で吸収しないことである。spec、テスト、レビュー、権限設計、そして開発者自身の理解を組織の標準に近づけるほど、同じモデルやツールを使っても成果の安定度が変わる。

Karpathyのメッセージは楽観でも悲観でもない。AIが強くなるほど、人間が理解し続けることの価値が上がるという、かなり実務的な結論である。

---

この対談から開発組織は何を学ぶべきか

この対談を開発組織向けに圧縮すると、学びはAIツールの使い方ではなく、開発責任の再設計に集約される。

まず押さえるべきは、この章の話が単独の予測ではなく「AIにどこまで仕事を渡し、どこから人間が品質責任を持つべきか」という問いの入り口になっている点である。何が新しくなったのかと同時に、何をまだ人間側で設計しなければならないのかを分けて読む。

第一に、プロトタイプ速度と本番品質を混ぜないこと。

vibe codingは強いが、それだけで運用品質は担保されない。試作は速く、本番は厳しく、という二層構造を明確にすべきである。

PoCで許した粗さを、そのまま本番へ持ち込む組織は事故を起こす。速さを得るほど、gateを設計する必要がある。

実務では、この主張を「何が可能になったか」だけで終わらせない方がよい。AIに渡す作業を大きくするほど、依頼文、検証手順、ロールバック条件まで同じ単位で設計する必要がある。そう読むと、この論点は新機能の紹介ではなく、次に整えるべき開発・事業プロセスの話になる。

第二に、評価指標を「書けるか」から「壊れずに仕上げられるか」へ移すこと。

agent時代の優秀な開発者は、自分で全部書く人ではない。意図を定義し、作業を分け、agentに渡し、検証し、仕上げられる人である。

採用課題、オンボーディング、レビュー文化は、この能力を測る方向へ変えるべきである。

開発チームとプロダクト責任者にとって重要なのは、この変化を個人の工夫で吸収しないことである。spec、テスト、レビュー、権限設計、そして開発者自身の理解を組織の標準に近づけるほど、同じモデルやツールを使っても成果の安定度が変わる。

第三に、ドキュメントとインフラをagent-firstへ寄せること。

人間だけが読むREADME、人間だけが触る管理画面、人間だけが覚える手順は、今後の摩擦源になる。

コピーしてagentに渡せる指示、権限の境界、監査ログ、再現可能なテストを持つチームほど、AIの速度を品質に変換できる。

ここで焦点を外すと、速く作れたことを、そのまま正しく作れたことと取り違えることにつながる。だからこの論点は、動画内の一発言ではなく、意思決定の前提を点検する材料として読む方がよい。

Karpathyの対談は、AIがコードを書く未来を語ったのではない。責任の置き場を変えずに、開発の重心をどこへ移すべきかを語ったのである。vibe codingが入口を広げたのだとすれば、次に競争力を分けるのはagentic engineeringを組織能力として持てるかどうかである。

---

関連記事

• AnthropicのBoris Cherny回
• Sequoia基調講演『This is AGI』
• vibe codingとAIエージェントツール
• Cursor AI IDE deep dive