「vibe codingはもう古い」——Karpathyが提示した次の基準「agentic engineering」とは
AIにコードを書かせることにはもう慣れた。でも、どこまで任せてよくて、どこからは自分で見るべきなのか——その線引きを、感覚だけで決めていないだろうか。
- vibe codingの提唱者自身が、なぜ「もう古い」と言い出したのか
- agentic engineeringの判定軸「検証できるか」とは何か
- 別の実務家（Simon Willison）も独立に同じ結論に至っていること
- 研究現場でのAIエージェント活用に照らした、任せる範囲の判断基準
- 明日から実務で変えられる3つの手順
vibe codingの提唱者自身が「もう古い」と言った
「vibe coding」という言葉は、2025年2月にKarpathy自身が作った。コードの中身をいちいち追わず、AIに雰囲気で指示してどんどん動くものを作っていくスタイルを指す言葉として広まり、誰でもプロトタイピングができる時代の象徴になった。
その言葉を作った本人が、2026年4月のSequoia Ascentという講演で「vibe codingはもう古い」と言い切った。作った当人が自分の言葉を退けるというのは、なかなか無い展開だ。
Karpathyが代わりに提示したのが「agentic engineering」という次の基準である。
判定軸は「検証できるか」
Karpathyの中心テーゼはこうだ。従来のソフトウェアは「仕様化できること」を自動化する。LLMと強化学習は「検証できること」を自動化する。
つまり、あるタスクについて「人間の介在なしに出力を検証できるか」を問う。できるなら、そのタスクは今すぐか近い将来に自動化できる。できないなら、まだ人間の判断が鎖の中に必要になる。
vibe codingが「誰でもプロトタイピングできる」ことで裾野を広げる考え方だったのに対し、agentic engineeringは「プロ品質の天井を維持する」ことに軸足を置く。エージェントの出力が正しいはずだと期待するのではなく、実際にチェックする姿勢そのものが違う。
Karpathyはさらに踏み込んで「思考は外注できても、理解は外注できない」と述べている。エージェントに任せた結果を検証するには、そもそも正しい出力とは何かを人間が理解している必要がある、という含意だ。
別の実務家も、独立に同じ結論にたどり着いていた
この考え方が一過性の思いつきではないと言えるのは、Karpathyと直接つながりのない実務家であるSimon Willisonが、ほぼ同時期に同じ言葉「agentic engineering」を使い、似た定義にたどり着いていたからだ。
Willisonは、Claude CodeやCodexのような「コードを生成し実行してテスト・反復できるツール」を使う実務として、これを3つの柱に整理している。
- ゴール定義：人間が問題と望む結果を明確に言語化する
- ツール準備：適切なハーネス・ドキュメント・サンドボックス環境を用意する
- 検証：アーキテクトとしてレビュー・テスト・統合する
Karpathyの「検証できることを自動化する」という判定軸と、Willisonの3本柱の3つ目「検証」は、独立に別々の場所から出てきた同じ答えだ。流行語というより、実務家コミュニティが手探りの末に収斂しつつある考え方だと見てよい。
研究現場での実感と重ねると
あたま研究現場でコーディングエージェントを使っていても、この線引きには心当たりがある。テストがしっかり書けるものや、結果が機械的に判別できる問題は任せられる。でも、人間の裁量によるところが大きいタスクは、まだ任せきれない。
あたま抽象的な言い方になってしまうけれど、この感覚こそがKarpathyの言う「検証できるか」の判定そのものだったのだと、今回改めて整理していて気づいた。
たとえば、動作をテストで機械的に確認できるタスクは任せやすい。一方、分析結果をどう解釈するか、研究をどの方向に進めるかといった、人間の裁量が本質的に絡むタスクは、エージェントに検証可能な形で切り出すこと自体が難しく、結果として任せられない。この境界線は、タスクの難易度ではなく「検証可能かどうか」で引かれている。
実務で変えるなら、まず「検証の手段」から用意する
では、vibe codingで満足していた人は、明日から何を変えればいいのか。
「もっと上手に指示を書く」ことではない。判定軸が「検証できるか」なら、変えるのは指示の前、つまり任せ方の順番である。ここからは、Karpathyの判定軸とWillisonの3本柱を踏まえた、筆者なりの整理になる。
- 任せる前に、検証の手段を先に決める：テストを書く、期待する出力の例を用意する、確認コマンドを指定する。Willisonの「ツール準備」と「検証」にあたる部分で、エージェントは検証手段があるほど暴走しにくく、結果の良し悪しも判断できる
- 検証できないタスクは、検証できる部分だけ切り出して任せる：判断が絡む作業を丸ごと渡さず、機械的に確かめられる部分（集計、変換、リファクタリングなど）だけをエージェントに頼み、判断は自分で持つ
- 結果は「動いた」で受け取らず、自分の言葉で説明できるか確かめる：差分とテスト結果を読んで、何が変わったかを人に説明できるか。説明できないなら、理解を外注してしまっている
vibe codingは「動けばよし」で進める。agentic engineeringは「動いたと、どう確かめたか」まで含めて任せる。違いは、AIの腕前ではなく、人間側の準備と読み方にある。
最初は、手元の作業を一つ選んで「これは自分で検証できるか」と問うだけで十分だ。答えがNoなら、そのタスクはまだ丸ごと任せない。それだけでも、任せ方は変わってくる。
まとめ
vibe codingの提唱者であるKarpathy自身が、次の基準として「agentic engineering」を提示した。判定軸は「人間の介在なしに出力を検証できるか」であり、これはSimon Willisonという別の実務家が独立にたどり着いた結論とも一致する。AIエージェントに何を任せるかを迷ったときは、タスクの複雑さではなく「その結果を自分で検証できるかどうか」を基準に線を引くと、判断がぶれにくくなる。実務では、検証の手段を先に用意し、検証できる部分だけを切り出して任せ、結果は自分の言葉で説明できるところまで読む。
あたまこの記事が役に立てば嬉しいです。よかったら他の記事も見てみてくださいね。
コメント