Martin Fowler の記事で扱われている vibe coding は、ざっくり言うと、
LLMに「こんなの作って」とお願いし、動かして、直してと頼み続ける。でも、LLMが生成したコードはほとんど見ない。
という開発スタイルです。
ここで面白いのは、単に「AIにコードを書かせる」話ではないことです。
ポイントは “forget that the code even exists”、つまりコードの存在を忘れること。
この割り切りが、vibe coding の便利さでもあり、危うさでもあります。
正直、この発想はかなり攻めています。
普通のエンジニアは「コードを読む」「理解する」「直す」まで含めて仕事だと思いがちですが、vibe coding はその前提をひっくり返します。
まるで「料理はよくわからないけど、注文だけ出してフルコースが出てくる」みたいな感覚です。便利だけど、厨房の中がどうなっているかは知らない、という感じですね。
この用語は、2025年2月に Andrej Karpathy が X で使ったのがきっかけです。
Karpathy は経験豊富なプログラマーで、彼の投稿ではかなり率直に、こんな雰囲気のことを言っています。
この「mostly works（だいたいうまくいく）」感が、まさに vibe coding の空気感なんですよね。
完成度より勢い。理解よりノリ。
技術文化としてはかなり現代的で、ちょっと笑ってしまうけど、実際かなり多くの人がこの方向に引っ張られているのではないかと思います。
この記事で Fowler は、vibe coding と Agentic Programming を分けて考えようと強く言っています。
つまり、**“AIに書かせる”だけでは同じではないということです。
この区別はかなり重要だと思います。
世間では「AIに全部やらせる」と一括りにされがちですが、実際にはコードを読むか読まないか**で、開発の性質がまったく変わるからです。
Fowler は、vibe coding は プログラミングを知らない人でも使えるのが大きな利点だと述べています。
たとえば、
こういうものには向いている、という話です。
ここはかなり納得感があります。
昔なら「アプリを作るにはプログラミングを学ばなきゃ」で止まっていた人でも、今はAIに自然言語でお願いして形にできます。
これは本当にすごい変化です。
ソフトウェア開発の入口が、急に低くなった感じがあります。
ただし、**“作れる”ことと“安全に運用できる”ことは別**です。
ここを混同すると危ない。
Fowler はまさにそこを何度も釘刺ししています。
この記事で特に強く警告されているのが security、つまり安全性です。
LLMは、便利な一方で攻撃対象になりやすい。
vibe coded なアプリは、気づかないうちに
といったリスクを抱えやすい、と Fowler は言います。
ここで出てくる Lethal Trifecta という言葉は、要するに「危険が重なると致命的」という警告です。
専門的な細部を知らなくても、**“便利だから大丈夫”とはまったく言えない**と理解しておくのが大事です。
個人的には、この警告はかなり重いと思います。
AIで作ること自体は楽しいし、速い。
でも、スピードが上がるほど、雑に作ったものがそのまま外に出てしまう。
昔なら数時間かけて書いた脆いコードが、今は数分で量産できる。
これ、便利さの裏返しとしてはかなり怖いですよね。
Fowler は、vibe coding だと 低品質なコードが大量に生まれやすいと指摘します。
低品質なコードが増えると何が困るかというと、
ということです。
ここで重要なのは、人間だけでなくLLMにとっても扱いにくいという点です。
つまり「AIが書いたからAIが直せるだろう」とは限らない。
むしろ、ぐちゃぐちゃなコードはAIにとっても厄介です。
Fowler は、今のところは よく整理されたソフトウェアのほうがLLMにとっても扱いやすいと見ています。
このあたり、AI万能論へのかなり現実的なブレーキになっています。
もう一つの大きな問題は、LLMの有名なクセである hallucination、つまりもっともらしい間違いです。
LLMは、間違った事実を自信満々に言うことがあります。
そしてそれはコード生成でも起こります。
結果として、
といったことが起きやすい。
Fowler は、LLM生成コードに対しては懐疑的に扱うべきだと言っています。
これはすごく大事な態度だと思います。
「AIが言ってるから正しい」で済ませると、地味に危険です。
むしろ、動いたとしても疑うくらいがちょうどいいのかもしれません。
記事の結論はかなり明快です。
vibe coding は、使い捨てのソフトウェアに向いている。
特に、
こういう条件なら、かなり有用です。
逆に、
には向かない、と Fowler ははっきり言っています。
この線引きはとても健全だと思います。
AIで何でも作れる時代だからこそ、「何でもAIに任せていいわけではない」と言ってくれる人は貴重です。
この記事を読んで感じたのは、vibe coding は「本格的なソフトウェア開発の置き換え」というより、試作品づくりの爆速化として見るほうがしっくりくる、ということです。
昔は、
の繰り返しにけっこう時間がかかりました。
でも今は、LLMに投げてかなり先まで一気に進められる。
この価値は本当に大きいです。
一方で、コードを見ないまま進めるというのは、便利さと引き換えに理解を後回しにする行為でもあります。
短期的には最高でも、長期的には厳しい。
だからこそ Fowler の「捨てられるものに使うべき」という結論は、かなり筋が通っていると思います。
vibe coding は、LLMに雰囲気で指示しながらコードを作らせ、そのコード自体はほぼ意識しない開発スタイルです。
プログラミング未経験者でも使える一方で、セキュリティ、正しさ、保守性に大きなリスクがあります。
Martin Fowler の記事は、この言葉を単なる流行語として消費するのではなく、
「何が新しくて、何が危ないのか」をきちんと分けて考えようと促しています。
この姿勢、かなり大事です。
AI時代の開発は便利になったぶん、雑に使うと危険も増えます。
だからこそ、vibe coding は「魔法」ではなく、用途を選んで使う道具として捉えるのが正解だと思います。
参考: Vibe Coding
