バイブコーディングとエージェントエンジニアリングの融合への懸念
Simon Willison は、AI コーディングツールの進化により「バイブコーディング」と「エージェントエンジニアリング」の境界が曖昧になりつつあると警鐘を鳴らし、プロフェッショナルな開発における責任の重要性を強調している。
キーポイント
2 つのパラダイムの融合
以前は明確に区別されていた「コードを見ずに試行錯誤するバイブコーディング」と、「専門知識に基づき高品質なシステムを構築するエージェントエンジニアリング」の境界が、著者の実務において曖昧になりつつあると述べている。
責任の所在による使い分け
個人ツールであればバグのリスクは自分だけで済むためバイブコーディングも許容されるが、他者向けのソフトウェアではセキュリティや保守性を無視したアプローチは「無責任」であると断じている。
経験豊富なエンジニアの役割
AI ツールを活用して作業範囲を拡大できる一方で、25 年の経験に基づく専門知識（セキュリティ、パフォーマンス、運用など）が不可欠であり、単に「速く」作るのではなく「高品質」なシステムを作るべきだと主張している。
影響分析・編集コメントを表示
影響分析
この記事は、生成 AI がソフトウェア開発の現場で急速に浸透する中で、単なる「コード生成」から「自律的エンジニアリング」への移行が起きつつある現状を鋭く指摘しています。特に、ツールの利便性が高まるほど、開発者の倫理的責任と専門知識の重要性が相対的に低下するリスク（バイブコーディングの乱用）を警告しており、業界全体として AI 活用における品質基準や責任の所在について再考を促す重要な示唆を含んでいます。
編集コメント
AI ツールの進化が著しい現在、開発者の「責任」という概念を再定義する必要があるという、非常にタイムリーで重要な指摘です。ツールの能力向上に伴い、人間の監督の質がより一層問われる時代に入ったことを示唆しています。
最近、Heavybit の High Leverage ポッドキャストのために Joseph Ruscio と AI コーディングツールについて話しました：Ep. #9, The AI Coding Paradigm Shift with Simon Willison。私のハイライトの一部を以下にまとめます。その中には、私自身の仕事において「バイブコーディング」と「エージェント型エンジニアリング」がすでに収束し始めているという、少し不安な気づきも含まれています。
ポッドキャストの素晴らしい点の一つは、時に言葉にできなかった考えを声に出して考えるよう促してくれることです。
バイブコーディングとエージェント型エンジニアリングが重なり始めています
「バイブコーディング」という用語が初めて使われてから数週間後、私は Not all AI-assisted programming is vibe coding (but vibe coding rocks) を公開しました。そこでは、「バイブコーディング」はコードを書くために AI を責任を持って使用するものとは全く異なる別物であると強く主張し、私はその後それを エージェント型エンジニアリング (agentic engineering) と呼ぶようになりました。
Joseph がこの 2 つの概念の違いについて持ち出したとき、突然気づきました。私にとってこれらは以前ほど明確に区別されているわけではないのです：
しかし不思議なことに、これらの違いはすでに私の中でぼやけ始めており、それがとても不安です。
私は、バイブコーディングとはコードを一切見ないものであり、プログラミングの知識すら持っていないかもしれない。非プログラマーが何かを要求し、結果を得て、それが動作すれば万々歳！もし動作しなければ、そう伝えて指をくわえて祈るものだ、という明確な線引きがあると考えていました。
しかし、その過程でコードの品質やその他の制約について真剣に気にすることはありません。私のバイブコーディングに対する見解は、いつ使用可能でいつ不可能かを理解していれば素晴らしいものだというものです。
個人用のツールであれば、バグがあなた自身を傷つけるだけなので、ぜひご活用ください！
しかし、他者のためにソフトウェアを構築する場合は、バイブコーディングは極めて無責任です。なぜなら、それは他人の情報を扱うことになるからです。あなたの愚かなバグによって他人が被害を受けます。それ以上のレベルが必要です。
これとは対照的に、エージェントエンジニアリングではあなたはプロのソフトウェアエンジニアです。セキュリティや保守性、運用、パフォーマンスなどを理解しています。これらのツールを自分の能力の限り最大限に活用しているのです。これらのツールのサポートのおかげで、取り組める課題の範囲が大幅に拡大したと感じています。
しかし、私は依然としてソフトウェアエンジニアとしての 25 年の経験に頼っています。
目標は高品質なプロダクションシステムを構築することです：もし低品質なものをより速く作っているなら、それは悪いことだと思います。私はより高品質なものをより速く作りたいのです。私が構築するすべてのものが、以前よりもあらゆる点で優れていることを望んでいます。
問題は、コーディングエージェントがより信頼性を持つにつれて、私のプロダクションレベルのコードであっても、彼らが書くコードの各行をもうレビューしなくなっていることです。
Claude Code に SQL クエリを実行してその結果を JSON として出力する JSON API エンドポイントを作成するように依頼すれば、それは正しく実行することをよく知っています。それを台無しにすることはありません。自動テストを追加させたり、ドキュメントを追加させたりすれば、それが良くなることは確実です。
しかし、私はそのコードをレビューしていません。そして今、罪悪感のようなものを感じています：もしコードをレビューしていないなら、これをプロダクションで使うことが本当に責任ある行為なのでしょうか？
私にとって本当に役立つのは、より大きな組織でエンジニアリングマネージャーとして働いていた頃の記憶をたどることです。他のチームが、私のチームが依存しているソフトウェアを構築しています。
別のチームが何かを引き渡して、「これは画像リサイズサービスです、画像をリサイズする方法はこれです」と言う場合、私は彼らが書いたコードの各行を読みに行くことはありません。
彼らのドキュメントを確認し、それを使って画像のサイズを変更します。その後、自分自身の特徴機能をリリースし始めます。もし画像リサイズ機能にバグがあるように見えたり、パフォーマンスが良くない問題に直面したりした場合、初めてその Git リポジトリを調べて何が起きているのか確認するかもしれません。しかし、大部分の場合は、必要な時まで見ない半ブラックボックスとして扱っています。
私はエージェントについても同じように扱うようになりました。それでもまだ居心地が悪く感じるのは、人間は自分の行動に対して責任を負う必要があるからです。チームは評判を築くことができます。「あのチームなら信頼できる」と言えます。「過去に良いソフトウェアを作ってきたし、プロとしての評判に影響するゴミのようなものは作らないだろうから」と。
Claude Code には専門的な評判がありません！自分が行ったことに対して責任を取ることもできません。しかしそれでも、自分自身で証明し続けています—何度も何度も、 straightforward なものを出力し、私が好むスタイルで正しく実行しています。
ここには 異常の正常化 の要素があります。モデルが私に厳密な監視なしに正しいコードを書き上げたたびに、将来の不適切なタイミングでそれを信頼して失敗するリスクが生じます。
ソフトウェア評価の新たな課題
昔は、コミット数が百件あり、良質な README ファイルがあり、自動化されたテストなどが整った GitHub リポジトリを見つけたら、そのプロジェクトを書いた人が相当な気遣いと注意を払ったのだと確信できました。
しかし今なら、半時間でコミット数百件の Git リポジトリを作成し、美しい README とコードの全行に対する包括的なテストを備えたものを生み出すことができます！それは、多くの気遣いと注意が注がれたプロジェクトと見た目が全く同じです。もしかすると同等の品質かもしれません。わかりません。見ていて判断できません。私の*自分自身*のプロジェクトでさえも、そうは言えません。
そこで私は気づきました。テストやドキュメントの質よりも私が重視するのは、「誰かがそのものを*実際に使った*」という事実です。もし過去二週間毎日使い倒した「バイブコーディング」されたものがあるなら、それはほとんど使われていない単に吐き出されたものに比べて、私にとってははるかに価値があります。
ボトルネックがシフトした
一日あたりのコード生産量が 200 行から 2,000 行に増えた場合、何が壊れるのでしょうか？ソフトウェア開発ライフサイクル全体が、実は「数百行のコードを生産するのに一日かかる」というアイデアを中心に設計されていたことがわかりました。しかし今や、それはもはや当てはまりません。
下流工程の問題だけではありません。上流工程も同様です。Anthropic のデザインリーダーであるジェニー・ウェンによる 素晴らしい講演 を拝見しましたが、彼女は「私たちはすべて、デザインを *正しく* 完成させる必要があるという考えに基づいたデザインプロセスを持っています」と述べていました。なぜなら、それをエンジニアに引き渡して間違ったものを 3 ヶ月も作り上げてしまった場合、それは壊滅的な事態になるからです。
そのデザインが結果として高価な作業につながるため、私たちは非常に広範なデザインプロセスを構築します。しかし、もし構築に 3 ヶ月かからないのであれば、何らかのミスをした際のコストが大幅に削減されている以上、デザインプロセス自体はもっとリスクの高いものでもよいかもしれません。
なぜ私はまだ自分のキャリアを恐れていないのか
エージェントとの会話を見渡すと、これは人類の绝大多数にとって「月の言語」であることが非常に明確です。
コンピュータが自分自身でコードを書けるようになった今、ソフトウェアエンジニアとしての私のキャリアが終わることを恐れない理由はいくつかあります。その一つは、これらが既存の経験を増幅する増幅器だからです。あなたが何をしているかを知っていれば、これらのツールを使えば圧倒的に速く進めることができます。[...]
私はこれらのツールを使って作業をするたびに、私たちが行うことの難しさを再認識させられます。ソフトウェアを生成することは *凄まじく* 難しいことです。どんなに AI ツールを与えられたとしても、ここで達成しようとしていることは依然として非常に困難です。[...]
政治評論家のマシュー・イグリアス氏が昨日 ツイート しました。「5 ヶ月が経過しましたが、私は『バイブコーディング』はしたくないと決めました。私が金銭を支払って購入するソフトウェア製品をより多く、より良く、より安く作るために、AI コーディング支援ツールを専門的に管理されたソフトウェア企業が利用することを望んでいます」と。この考え方は私にもしっくりきます。私は YouTube の配管に関する動画を十分に視聴すれば家の配管工事を行うこともできますが、むしろ配管業者を雇いたいと思います。
自社でソリューションを開発する企業による SaaS プロバイダーへの脅威について：
先ほど私が言ったこと、つまり「数週間実際に使用しているサイドプロジェクトでなければ使いたくない」という考えがまさにこれだと気づきました。そのエンタープライズ版としては、「少なくとも他の巨大企業 2 社がその CRM を 6 ヶ月間成功裏に利用していない限り、CRM は使いません」となります。[...] リスクを冒す前に、実証済みのソリューションが必要です。
タグ：ai, generative-ai, llms, podcast-appearances, vibe-coding, coding-agents, agentic-engineering
原文を表示
I recently talked with Joseph Ruscio about AI coding tools for Heavybit's High Leverage podcast: Ep. #9, The AI Coding Paradigm Shift with Simon Willison. Here are some of my highlights, including my disturbing realization that vibe coding and agentic engineering have started to converge in my own work.
One thing I really enjoy about podcasts is that they sometimes push me to think out loud in a way that exposes an idea I've not previously been able to put into words.
Vibe coding and agentic engineering are starting to overlap
A few weeks after vibe coding was first coined I published Not all AI-assisted programming is vibe coding (but vibe coding rocks), where I firmly staked out my belief that "vibe coding" is a very different beast from responsible use of AI to write code, which I've since started to call agentic engineering.
When Joseph brought up the distinction between the two I had a sudden realization that they're not nearly as distinct for me as they used to be:
Weirdly though, those things have started to blur for me already, which is quite upsetting.
I thought we had a very clear delineation where vibe coding is the thing where you're not looking at the code at all. You might not even know how to program. You might be a non-programmer who asks for a thing, and gets a thing, and if the thing works, then great! And if it doesn't, you tell it that it doesn't work and cross your fingers.
But at no point are you really caring about the code quality or any of those additional constraints. And my take on vibe coding was that it's fantastic, provided you understand when it can be used and when it can't.
A personal tool for you, where if there's a bug it hurts only you, go ahead!
If you're building software for other people, vibe coding is grossly irresponsible because it's other people's information. Other people get hurt by your stupid bugs. You need to have a higher level than that.
This contrasts with agentic engineering where you are a professional software engineer. You understand security and maintainability and operations and performance and so forth. You're using these tools to the highest of your own ability. I'm finding the scope of challenges I can take on has gone up by a significant amount because I've got the support of these tools.
But I'm still leaning on my 25 years of experience as a software engineer.
The goal is to build high quality production systems: if you're building lower quality stuff faster, I think that's bad. I want to build higher quality stuff faster. I want everything I'm building to be better in every way than it was before.
The problem is that as the coding agents get more reliable, I'm not reviewing every line of code that they write anymore, even for my production level stuff.
I know full well that if you ask Claude Code to build a JSON API endpoint that runs a SQL query and outputs the results as JSON, it's just going to do it right. It's not going to mess that up. You have it add automated tests, you have it add documentation, you know it's going to be good.
But I'm not reviewing that code. And now I've got that feeling of guilt: if I haven't reviewed the code, is it really responsible for me to use this in production?
The thing that really helps me is thinking back to when I've worked at larger organizations where I've been an engineering manager. Other teams are building software that my team depends on.
If another team hands over something and says, "hey, this is the image resize service, here's how to use it to resize your images"... I'm not going to go and read every line of code that they wrote.
I'm going to look at their documentation and I'm going to use it to resize some images. And then I'm going to start shipping my own features. And if I start running into problems where the image resizer thing appears to have bugs or the performance isn't good, that's when I might dig into their Git repositories and see what's going on. But for the most part I treat that as a semi-black box that I don't look at until I need to.
I'm starting to treat the agents in the same way. And it still feels uncomfortable, because human beings are accountable for what they do. A team can build a reputation. I can say "I trust that team over there. They built good software in the past. They're not going to build something rubbish because that affects their professional reputations."
Claude Code does not have a professional reputation! It can't take accountability for what it's done. But it's been proving itself anyway - time and time again it's churning out straightforward things and doing them right in the style that I like.
There's an element of the normalization of deviance here - every time a model turns out to have written the right code without me monitoring it closely there's a risk that I'll trust it at the wrong moment in the future and get burned.
The new challenge of evaluating software
It used to be if you found a GitHub repository with a hundred commits and a good readme and automated tests and stuff, you could be pretty sure that the person writing that had put a lot of care and attention into that project.
And now I can knock out a git repository with a hundred commits and a beautiful readme and comprehensive tests of every line of code in half an hour! It looks identical to those projects that have had a great deal of care and attention. Maybe it is as good as them. I don't know. I can't tell from looking at it. Even for my own projects, I can't tell.
So I realized what I value more than the quality of the tests and documentation is that I want somebody to have used the thing. If you've got a vibe coded thing which you have used every day for the past two weeks, that's much more valuable to me than something that you've just spat out and hardly even exercised.
The bottlenecks have shifted
If you can go from producing 200 lines of code a day to 2,000 lines of code a day, what else breaks? The entire software development lifecycle was, it turns out, designed around the idea that it takes a day to produce a few hundred lines of code. And now it doesn't.
It's not just the downstream stuff, it's the upstream stuff as well. I saw a great talk by Jenny Wen, who's the design leader at Anthropic, where she said we have all of these design processes that are based around the idea that you need to get the design right - because if you hand it off to the engineers and they spend three months building the wrong thing, that's catastrophic.
There's this whole very extensive design process that you put in place because that design results in expensive work. But if it doesn't take three months to build, maybe the design process can be a whole lot riskier because cost, if you get something wrong, has been reduced so much.
Why I'm still not afraid for my career
When I look at my conversations with the agents, it's very clear to me that this is moon language for the vast majority of human beings.
There are a whole bunch of reasons I'm not scared that my career as a software engineer is over now that computers can write their own code, partly because these things are amplifiers of existing experience. If you know what you're doing, you can run so much faster with them. [...]
I'm constantly reminded as I work with these tools how hard the thing that we do is. Producing software is a ferociously difficult thing to do. And you could give me all of the AI tools in the world and what we're trying to achieve here is still really difficult. [...]
Matthew Yglesias, who's a political commentator, yesterday tweeted, "Five months in, I think I've decided that I don't want to vibecode — I want professionally managed software companies to use AI coding assistance to make more/better/cheaper software products that they sell to me for money." And that feels about right to me. I can plumb my house if I watch enough YouTube videos on plumbing. I would rather hire a plumber.
On the threat to SaaS providers of companies rolling their own solutions instead:
I just realized it's the thing I said earlier about how I only want to use your side project if you've used it for a few weeks. The enterprise version of that is I don't want a CRM unless at least two other giant enterprises have successfully used that CRM for six months. [...] You want solutions that are proven to work before you take a risk on them.
Tags: ai, generative-ai, llms, podcast-appearances, vibe-coding, coding-agents, agentic-engineering
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み