Simon Willisonが今回書いているのは、AI時代のソフトウェア開発でよく聞く2つの言葉、vibe coding と agentic engineering の距離が、思ったより縮まってきたという話です。
この2つ、ざっくり言うとこんな違いがあります。
vibe coding
コードの中身を細かく気にせず、AIに「こんな感じで作って」と頼んで進めるやり方。
うまく動けばOK、ダメならまた投げ直す、みたいなノリです。
agentic engineering
ちゃんとしたソフトウェアエンジニアが、AIを補助輪として使いながら、品質・保守性・セキュリティ・運用まで意識して作るやり方。
つまり「AIに丸投げ」ではなく、プロの責任の中でAIを使う という考え方ですね。
Simonは以前、この2つはかなり違うものだと考えていました。
特に vibe coding は、個人の遊びや試作なら面白いけれど、他人が使う本番サービスでやるのはかなり危ない、という立場です。これはかなり筋が通っていると思います。自分のメモアプリなら多少雑でもいいけれど、他人のお金や個人情報が絡むサービスだと話は別ですから。
でも、ここが面白いところで、彼は最近その境界が 自分の中で崩れ始めた と言っています。
Simonの告白で特に刺さるのがここです。
彼は、Claude Code のような coding agent に、たとえば「JSON API のエンドポイントを作って、SQLを実行して、結果をJSONで返す」ような単純な仕事を任せると、もう かなりの確率でちゃんとやってくれる と感じています。テストもドキュメントも追加してくれる。たしかにそれは便利です。ものすごく便利です。
ただし、その便利さの代償として、自分はもう全部のコードを読まなくなっている と彼は言います。
これ、かなり重要なポイントだと思います。
AIツールが「便利」なのは当然なんですが、便利さが積み上がると、人間の確認コストを飛び越えてしまうんですね。すると、
ちゃんとレビューしてないのに、本番で使っていいのか？
という、ちょっと嫌な問いが残ります。
Simonはこれを、昔の大きな組織での経験になぞらえています。
別チームが作った「画像リサイズサービス」を使うとき、普通はそのチームのコードを1行ずつ読んだりしませんよね。ドキュメントを見て使い、問題が起きたら初めて中身を見に行く。ソフトウェアではよくある現実です。
彼は今、AI agentもそれと同じように扱い始めている、と言います。
つまり、「一応ブラックボックスとして使う」 という感覚です。
ただ、ここでひっかかるのが責任の問題です。
人間のチームなら「この会社・このチームは信頼できる」と言えるし、失敗すれば評判に返ってきます。でも Claude Code には評判も責任もない。そこが人間とAIの決定的な違いです。
この点は、かなり本質的だと思います。
AIは結果だけ見ると立派でも、失敗したときに責任を取る主体ではない。だからこそ、どこまで信頼するかの線引きが難しいんですよね。
Simonはさらに、AIがたまたま正しいコードを書いたときに、それが積み重なると “正常化された逸脱” に近い状態になるのではないかと懸念しています。
これは要するに、
「今回もうまくいったし、前回もうまくいったし、じゃあ今回も大丈夫だろう」
と油断して、本当に危ない場面でチェックを怠る リスクです。
これ、かなり人間っぽい落とし穴です。
便利な道具って、成功体験が増えるほど信頼が雑になりやすいんですよね。包丁でも電動工具でも同じですが、AIは特に「中身が見えにくい」のが厄介です。
この記事のもう1つの面白い論点は、ソフトウェアをどう評価するか が変わってきた、という話です。
昔は、GitHubで
みたいなリポジトリを見ると、「これはちゃんとした人が作ったんだな」と思えました。
でも今は、AIを使えば 短時間でそれっぽいリポジトリを量産できる ので、見た目だけでは判断しづらい。
Simonはここで、何より大事なのは
「実際に使われているかどうか」
だと気づいたと言います。
たとえば、vibe coding で作られたツールでも、本人が毎日2週間使っているなら、それはかなり価値がある。逆に、見た目は立派でも、ほとんど使われていないものは信用しづらい。これはすごく実感のある話です。READMEがきれいでも、実運用で壊れるソフトは山ほどありますから。
要するに、今後は
“どれだけ整って見えるか” ではなく “どれだけ実戦で鍛えられているか”
が大事になる、ということだと思います。
AIで1日に書けるコードが、200行から2,000行になったら何が起きるのか。
Simonは、ソフトウェア開発の全体が、まだ「1日に数百行しか書けない」前提で組まれていたことに気づきます。
これ、地味に大きな話です。
たとえば設計です。
Anthropicのデザインリーダー、Jenny Wenの話として、Simonは「設計をちゃんと詰めるのは、間違えたものを3か月かけて作ると痛いからだ」という趣旨を紹介しています。
でも、もし実装が3か月ではなく数日や数週間で済むなら、設計にそこまで重厚なプロセスをかけなくてもいいかもしれない。失敗コストが下がるからです。
これはかなり面白い発想です。
AIは単に「コーディングを速くする」だけじゃなく、設計・レビュー・実装・運用のバランスそのものを変える 可能性があるわけです。
開発のどこがボトルネックになるかが、じわじわ移動しているんですね。
Simonは、自分のキャリアがAIで終わるとはあまり思っていません。理由はシンプルで、こうしたツールは 経験者を強くする増幅器 だからです。
経験がある人は、AIを使うことでかなり遠くまで速く行ける。
でも逆に言うと、経験がない人がいきなり全部を理解した気になれるわけではない、ということでもあります。
ここで彼が引用している Matthew Yglesias の意見もかなり本音っぽくていいです。
要するに、
vibe coding したいわけじゃない。
ちゃんとした会社がAIを使って、もっと安く・速く・良いソフトを作って、自分がそれを買いたい。
という感覚です。
これ、かなり現実的だと思います。
多くの人は「自分でコードを書きたい」のではなく、ちゃんと動くサービスを使いたい わけです。
たとえば家の配管はYouTubeを見れば自分でも触れるかもしれないけれど、できればプロの水道屋さんに頼みたい。Simonもまさにその例えを使っています。
最後にSimonは、SaaS（Software as a Service、つまり月額課金などで使うクラウドサービス）の話にも触れています。
もし企業がAIを使って自分たちで内製ツールをどんどん作れるようになると、既存のSaaSは脅威を受けるのではないか、という論点です。
ただ彼の見方は少し独特で、企業向けでもやっぱり
というものじゃないと安心できない、と言っています。
これも納得感があります。
企業は「安いから試す」より「失敗しないから選ぶ」が強い。
だから、AIで簡単に作れることと、他社が安心して買うことは、必ずしもイコールではありません。
この記事の核心は、AIコーディングが“おもちゃ”から“実務”に移ってきた結果、扱い方の倫理と責任があいまいになってきた ということだと思います。
Simon WillisonはAIに否定的なわけではありません。むしろかなり前向きです。
でもそのうえで、
という不安を、かなり正直に語っています。
個人的には、この話は「AIでコードが書けるか」よりも、
「AIが書いたコードを、私たちはどう信用するのか」
という問いのほうが本丸だと思います。
AIは確かに強い。
でも、強い道具ほど、使う側の判断力が試される。
Simonの記事は、その現実をかなり率直に突きつけてくる一篇でした。
参考: Vibe coding and agentic engineering are getting closer than I’d like
