バイブコーディングとエージェントエンジニアリングの融合への懸念

最近、Heavybit の High Leverage ポッドキャストのために Joseph Ruscio と AI コーディングツールについて話しました：[Ep. #9, The AI Coding Paradigm Shift with Simon Willison](https://www.heavybit.com/library/podcasts/high-leverage/ep-9-the-ai-coding-paradigm-shift-with-simon-willison)。私のハイライトの一部を以下にまとめます。その中には、私自身の仕事において「バイブコーディング」と「エージェント型エンジニアリング」がすでに収束し始めているという、少し不安な気づきも含まれています。 ポッドキャストの素晴らしい点の一つは、時に言葉にできなかった考えを声に出して考えるよう促してくれることです。 ## バイブコーディングとエージェント型エンジニアリングが重なり始めています 「バイブコーディング」という用語が初めて使われてから数週間後、私は [Not all AI-assisted programming is vibe coding (but vibe coding rocks)](https://simonwillison.net/2025/Mar/19/vibe-coding/) を公開しました。そこでは、「バイブコーディング」はコードを書くために AI を責任を持って使用するものとは全く異なる別物であると強く主張し、私はその後それを [エージェント型エンジニアリング (agentic engineering)](https://simonwillison.net/guides/agentic-engineering-patterns/what-is-agentic-engineering/) と呼ぶようになりました。 Joseph がこの 2 つの概念の違いについて持ち出したとき、突然気づきました。私にとってこれらは以前ほど明確に区別されているわけではないのです： しかし不思議なことに、これらの違いはすでに私の中でぼやけ始めており、それがとても不安です。 私は、バイブコーディングとはコードを一切見ないものであり、プログラミングの知識すら持っていないかもしれない。非プログラマーが何かを要求し、結果を得て、それが動作すれば万々歳！もし動作しなければ、そう伝えて指をくわえて祈るものだ、という明確な線引きがあると考えていました。 しかし、その過程でコードの品質やその他の制約について真剣に気にすることはありません。私のバイブコーディングに対する見解は、いつ使用可能でいつ不可能かを理解していれば素晴らしいものだというものです。 個人用のツールであれば、バグがあなた自身を傷つけるだけなので、ぜひご活用ください！ しかし、他者のためにソフトウェアを構築する場合は、バイブコーディングは極めて無責任です。なぜなら、それは他人の情報を扱うことになるからです。あなたの愚かなバグによって他人が被害を受けます。それ以上のレベルが必要です。 これとは対照的に、エージェントエンジニアリングではあなたはプロのソフトウェアエンジニアです。セキュリティや保守性、運用、パフォーマンスなどを理解しています。これらのツールを自分の能力の限り最大限に活用しているのです。これらのツールのサポートのおかげで、取り組める課題の範囲が大幅に拡大したと感じています。 しかし、私は依然としてソフトウェアエンジニアとしての 25 年の経験に頼っています。 目標は高品質なプロダクションシステムを構築することです：もし低品質なものをより速く作っているなら、それは悪いことだと思います。私はより高品質なものをより速く作りたいのです。私が構築するすべてのものが、以前よりもあらゆる点で優れていることを望んでいます。 問題は、コーディングエージェントがより信頼性を持つにつれて、私のプロダクションレベルのコードであっても、彼らが書くコードの各行をもうレビューしなくなっていることです。 Claude Code に SQL クエリを実行してその結果を JSON として出力する JSON API エンドポイントを作成するように依頼すれば、それは正しく実行することをよく知っています。それを台無しにすることはありません。自動テストを追加させたり、ドキュメントを追加させたりすれば、それが良くなることは確実です。 しかし、私はそのコードをレビューしていません。そして今、罪悪感のようなものを感じています：もしコードをレビューしていないなら、これをプロダクションで使うことが本当に責任ある行為なのでしょうか？ 私にとって本当に役立つのは、より大きな組織でエンジニアリングマネージャーとして働いていた頃の記憶をたどることです。他のチームが、私のチームが依存しているソフトウェアを構築しています。 別のチームが何かを引き渡して、「これは画像リサイズサービスです、画像をリサイズする方法はこれです」と言う場合、私は彼らが書いたコードの各行を読みに行くことはありません。 彼らのドキュメントを確認し、それを使って画像のサイズを変更します。その後、自分自身の特徴機能をリリースし始めます。もし画像リサイズ機能にバグがあるように見えたり、パフォーマンスが良くない問題に直面したりした場合、初めてその Git リポジトリを調べて何が起きているのか確認するかもしれません。しかし、大部分の場合は、必要な時まで見ない半ブラックボックスとして扱っています。 私はエージェントについても同じように扱うようになりました。それでもまだ居心地が悪く感じるのは、人間は自分の行動に対して責任を負う必要があるからです。チームは評判を築くことができます。「あのチームなら信頼できる」と言えます。「過去に良いソフトウェアを作ってきたし、プロとしての評判に影響するゴミのようなものは作らないだろうから」と。 Claude Code には専門的な評判がありません！自分が行ったことに対して責任を取ることもできません。しかしそれでも、自分自身で証明し続けています—何度も何度も、 straightforward なものを出力し、私が好むスタイルで正しく実行しています。 ここには [異常の正常化](https://simonwillison.net/2025/Dec/10/normalization-of-deviance/) の要素があります。モデルが私に厳密な監視なしに正しいコードを書き上げたたびに、将来の不適切なタイミングでそれを信頼して失敗するリスクが生じます。 ## ソフトウェア評価の新たな課題 昔は、コミット数が百件あり、良質な README ファイルがあり、自動化されたテストなどが整った GitHub リポジトリを見つけたら、そのプロジェクトを書いた人が相当な気遣いと注意を払ったのだと確信できました。 しかし今なら、半時間でコミット数百件の Git リポジトリを作成し、美しい README とコードの全行に対する包括的なテストを備えたものを生み出すことができます！それは、多くの気遣いと注意が注がれたプロジェクトと見た目が全く同じです。もしかすると同等の品質かもしれません。わかりません。見ていて判断できません。私の*自分自身*のプロジェクトでさえも、そうは言えません。 そこで私は気づきました。テストやドキュメントの質よりも私が重視するのは、「誰かがそのものを*実際に使った*」という事実です。もし過去二週間毎日使い倒した「バイブコーディング」されたものがあるなら、それはほとんど使われていない単に吐き出されたものに比べて、私にとってははるかに価値があります。 ## ボトルネックがシフトした 一日あたりのコード生産量が 200 行から 2,000 行に増えた場合、何が壊れるのでしょうか？ソフトウェア開発ライフサイクル全体が、実は「数百行のコードを生産するのに一日かかる」というアイデアを中心に設計されていたことがわかりました。しかし今や、それはもはや当てはまりません。 下流工程の問題だけではありません。上流工程も同様です。Anthropic のデザインリーダーであるジェニー・ウェンによる [素晴らしい講演](https://simonwillison.net/2026/Jan/24/dont-trust-the-process/) を拝見しましたが、彼女は「私たちはすべて、デザインを *正しく* 完成させる必要があるという考えに基づいたデザインプロセスを持っています」と述べていました。なぜなら、それをエンジニアに引き渡して間違ったものを 3 ヶ月も作り上げてしまった場合、それは壊滅的な事態になるからです。 そのデザインが結果として高価な作業につながるため、私たちは非常に広範なデザインプロセスを構築します。しかし、もし構築に 3 ヶ月かからないのであれば、何らかのミスをした際のコストが大幅に削減されている以上、デザインプロセス自体はもっとリスクの高いものでもよいかもしれません。 ## なぜ私はまだ自分のキャリアを恐れていないのか エージェントとの会話を見渡すと、これは人類の绝大多数にとって「月の言語」であることが非常に明確です。 コンピュータが自分自身でコードを書けるようになった今、ソフトウェアエンジニアとしての私のキャリアが終わることを恐れない理由はいくつかあります。その一つは、これらが既存の経験を増幅する増幅器だからです。あなたが何をしているかを知っていれば、これらのツールを使えば圧倒的に速く進めることができます。[...] 私はこれらのツールを使って作業をするたびに、私たちが行うことの難しさを再認識させられます。ソフトウェアを生成することは *凄まじく* 難しいことです。どんなに AI ツールを与えられたとしても、ここで達成しようとしていることは依然として非常に困難です。[...] 政治評論家のマシュー・イグリアス氏が昨日 [ツイート](https://twitter.com/mattyglesias/status/2049105745132585161) しました。「5 ヶ月が経過しましたが、私は『バイブコーディング』はしたくないと決めました。私が金銭を支払って購入するソフトウェア製品をより多く、より良く、より安く作るために、AI コーディング支援ツールを専門的に管理されたソフトウェア企業が利用することを望んでいます」と。この考え方は私にもしっくりきます。私は YouTube の配管に関する動画を十分に視聴すれば家の配管工事を行うこともできますが、むしろ配管業者を雇いたいと思います。 自社でソリューションを開発する企業による SaaS プロバイダーへの脅威について： 先ほど私が言ったこと、つまり「数週間実際に使用しているサイドプロジェクトでなければ使いたくない」という考えがまさにこれだと気づきました。そのエンタープライズ版としては、「少なくとも他の巨大企業 2 社がその CRM を 6 ヶ月間成功裏に利用していない限り、CRM は使いません」となります。[...] リスクを冒す前に、実証済みのソリューションが必要です。 タグ：[ai](https://simonwillison.net/tags/ai), [generative-ai](https://simonwillison.net/tags/generative-ai), [llms](https://simonwillison.net/tags/llms), [podcast-appearances](https://simonwillison.net/tags/podcast-appearances), [vibe-coding](https://simonwillison.net/tags/vibe-coding), [coding-agents](https://simonwillison.net/tags/coding-agents), [agentic-engineering](https://simonwillison.net/tags/agentic-engineering)

バイブコーディングとエージェントエンジニアリングの融合への懸念

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト