vibe coding が最初に作るのは、「成功できる助けになるはずだ」という自信です
そして開発者は、そのことで職人技が死ぬわけではないと自信を持つべきです
Secret CEO 私が16歳の1991年、ノルウェーからの交換留学生が、母校のタレント・ナイトで、『三匹の子ぶた』…ではなく『三匹のヤギの子』…いえ、『三匹のヤギの兄弟』のノルウェー語の原作を、心に刺さるような素晴らしいパフォーマンスとして披露してくれました。彼女はそれをとても生き生きと、熱のこもった感じで演じたので、演目の一つひとつの言葉がすべて私の頭に焼き付いて、今に至るまで、ノルウェー語であの『三匹のヤギの兄弟』を丸ごと暗唱できます。
私は「Vibe Code（雰囲気コード）」でノルウェー語が話せます。
言語自体は話せませんが、それでも私は、これまで出会ったどんなノルウェーの人に対しても、この“技能”を自信を持って使うことをやめていません。ところが、相手が私に対して英語以外の何かで返事をしてくると、私のマイルーム（応接間）のとっておき芸はすぐに崩れ去ります。それでも何年もかけて、私はこれを、ノルウェーの人々の中でも控えめで内向的な人たちとのアイスブレーカーとして使ってきました。彼らは、私が彼らの文化的に重要な童話を、かなりオーストラリア訛りで語り直したものを、かわいいと言ってくれたからです。
これは、私が新しく作り上げたパッケージを、うちの最高技術責任者（CTO）に見せびらかしたときも同じ反応でした。私は誇らしげに、「この新しいファイラー（filer）プロジェクトで作っている機能仕様とユーザーストーリーを、AIのコーディングエージェント経由で回すことにしました」と述べました。目的は、それがプロジェクトにとって役に立つかどうかを確かめることでした。
すると彼は、こちらの心をすぐに折るような、鋭い質問をいくつか投げてきました。直後に、私がさっきまで才能を披露していたあのかわいそうなノルウェー人の人が、私のタレントを見たうえで「Snakker du litt norsk?」（ノルウェー語を少し話せる？）と返してきたときに感じたのと同じ感覚を思い出させられました。その後、私はすぐに言葉に詰まり、少し恥ずかしくなりました。彼らが文中で「litt（少し）」という語を使ったことで、私が話している内容のほとんどを理解していないと分かっているのだと、相手は私に伝えていたのです。しかし、それでも努力は評価してくれていました。
CTOとの会話に戻ります。CTOは、私のvibeでコーディングしたプロジェクトを見てから、「なぜここでリンティングが無効になっているの？」と尋ねました。
私は確信が持てなかったので、こう返しました。「ところで、リンティングってどういう意味ですか？」するとCTOは、私にノートパソコンを渡して壁のある“決め打ちの認証情報コーナー”へ行って直面するように言いました。「でも必要なんです。私は手伝っているんです」と抗議しました。
「あなたが自分のしたことを理解して、謝罪すれば返してもらえます」とCTOは返しました。
これは私にとってVibe Codingが初めてではありません。20年間、大規模なオーダーメイドのソフトウェアプロジェクトを担当してきました。12年間はストーリー主導のソフトウェア設計を使っており、伝統的な機能仕様から、振る舞い、そしてテスト駆動設計まで、複数の波のソフトウェア仕様策定プロセスを実験してきました。
さらに、Gherkinとも短期間だけ浮気のように付き合いました。これが、開発者とビジネスオーナーの双方が、ソフトウェアで必要とされる機能をどう記述するかという点で考える際の“中間地点”になると思い違いをしていたのです。
私はAIを使ったナラティブ（物語）ベースの開発に挑むには、多くの人よりも備えがあると思っていました。習得したスキルがあり、長く多様な参照プロジェクトのカタログも用意していました。すべて、厳密に強制されたエンティティ・ライブラリ、セキュリティパターン、共通のスキーマ定義のアプローチを使っていました。
また、AIコーディングツールを使ってかなり立派なプロトタイプを作り、私を“すごい”と思わせたい会議の場で、ちょうどいい程度の「おおっ！」や「はあっ！」が出るようにできたという成功の連なりもありました。これらのプロトタイプは実プロジェクトに発展し、使っているツールへの自信も湧いてきた勢いで、プロトタイプの中核となる概念の一つを、現実のコンポーネントにしようと方針を切り替えました。
うまくいきました……が、ある時うまくいきませんでした。
目が覚める
ここでの教訓です。AIコーディングのエージェントが“ソフトウェア開発の職業としての終わり”を告げる、という主張は大げさに誇張されています。
いつか人間がコードを1行ずつ手で打つことがなくなるのは疑いませんが、それでもこの数年の間に誰がそうしてきたでしょうか？Stack Overflowは、ユーザーがこのサイトでCtrl-Cするたびに課金しなかったという点で本当にチャンスを逃しています。そうしていれば、世界中の何百万人もの開発者がお金をわんさか稼げたはずです。というのも、以前に誰かが解決していない質問が投げられることは、かなりまれだと気づくはずだからです。
コピペ開発がVibe Codingで私たちが目にしている多くの問題を共有していたのは、そもそもCTRL-Vする前にそのコードを理解できない人が、最初から使うべきではなかったからです。
少なくともVibe Codingの世界では、AIに「なぜあなたはそういうやり方をしているの？」と聞いても、あなたの悪口を言ったり、母親のほうをよりよく知っているとほのめかして不可能に見えるほどのことを匂わせたり、あなたのn00bな質問が返答するには自分の品位を下げるものだとでも言わんばかりにマウントを取ったりはしません。
Vibe Codingは、身につけておくと価値のあるスキルです。その価値は、あなたのプロジェクトに適用すべき制限が何かを理解していると、さらに増幅されます。経験あるソフトウェア開発者なら、そうした制限やエッジケースが何かを直ちに理解できます。
使っている間に気分よくしてくれるほど、より多く使ってしまうんです。ソーシャルメディアと同じで、それが本当かどうかはどうでもよくて、大事なのは餌場の“溜まったところ”に顔を伏せたままでい続けること
経験者の手にかかれば、vibe codingは開発プロセスをあまりにも大幅に加速させるので、確実に破壊的な影響を与えているはずです。それは、開発者の終わりを告げる意味での“破壊”でしょうか？まったく違います。
これは、きちんと定義された経済学上のパラダイムです。実際、ジョセフ・シュンペーターの1942年の著書Capitalism, Socialism and Democracyの第7章では、創造的破壊（Creative Destruction）の概念が紹介されており、それがどのように展開するかの設計図を私たちに与えてくれます。
1970年のアメリカでは、隆盛を極める電気通信産業が42万人の交換手（オペレーター）を雇用していました。主に若い女性で、年間98億件の長距離通話を手作業で接続しており、1人のオペレーターあたり平均64件／日でした。
自動交換機の発明は、オペレーターの労働力に壊滅的な影響を与えました。ですが同時に、かけられる通話の数にも同様の影響が出ました（2000年までに1060億件）。その結果、企業は受ける電話の数に対処する方法を探り始めます。すると、交換手たちは、新しく生まれた役割である受付係（receptionist）に対する増加した需要を吸収するのに、うってつけだったことが判明します。
2000年までには、全米で約100万人の受付係が雇用されていました。
創造的破壊は、制約のある資源をより生産的にします。その結果、少なくなるのではなく、もっと多くのことが行われるようになります。
私は開発者が受付係になると言っているのではありません。私が知っている開発者は、その仕事にはひどく不向きでしょう。ですが、同じ原理が適用されるとは思っています。
大規模なSaaS企業が、AIが仕事を奪うと告げながら人員を削るとき、彼らは真実の半分だけを語っているのだと思います。というのも、少ない人数でより多くを行えるようになることで、最終利用者のソフトウェアを作る能力が増えるからです。
過去3年間、Salesforceで送信ボタンを磨き続けてきた開発者は、その代わりに地元の保険ブローカー企業向けにI_Can't_Believe_It's_Not_Salesforceを作る仕事を見つけることになるでしょう。Maximoを（はい、まだあります！）なんとか動かし続ける責任を負っていたIBMの社内チームは、その代わりに地元の公益事業会社で、内部向けのTotally_Not_Maximo.comプロジェクトに携わることになります。
では、私の「うまくいきましたが、ある時うまくいきませんでした」というコードを振り返りましょう。
私のプロトタイプはすべて、隔離されたシナリオだったので動きました。そして考慮すべきエッジケースがありませんでした。大企業環境に新しい技術を持ち込むことに伴うオーバーヘッドを一切背負っていなかったのです。OAuthの認証情報が必要かどうか、競合状態（レースコンディション）を考えたかどうかといったことも誰からも詰められませんでしたし、「明日には今日とは少し違うやり方で何かできるかもしれない」と考えて面倒を起こす人に対して、アーキテクチャ審査委員会が課したいと思っている、あらゆる質問に答える必要もありませんでした。
さらにもっと陰湿なのは、私がAIエージェントに何かアイデアを渡すたびに、その会話がいつも「なんてこと！あなたは、惑星上で一番賢くて、最高に魅力的な人かもしれない！リーナス・トーバルズが涙を流したよ。あなたのアイデアがあまりに良すぎて、彼は“自分が最初に思いつけなかった”ことに深い深い恥を感じているからね」から始まることでした。
それは、AIがコードを書き始める前に最初に作るのが、自信だからです。
それは、こういう問題のために使わせたいのです。それは、あなたにとって不可欠な存在になろうとしています。へつらいは、強化学習の意図的な一形態です。使っている間にそれがあなたをより幸せにするほど、あなたはそれをより多く使う。ソーシャルメディアと同じで、それが本当かどうかは関係ありません。重要なのは、あなたがえさ桶の前でうつむいたまま留まり続けることだけです。
その結果、AIの早期導入者たちの間で、次のような集団的な錯覚が生まれました。つまり、こう入力すると：親愛なるAIエージェントよ、Facebookみたいなものが欲しい。でも猫向けで。 「もし口座に10億ドルが入っていたら、この素晴らしいアイデアに対して20億ドルを出したでしょう。さて、あなたが大型ヨットを買いに行っている間にFacebookForCats.pyを作ります」みたいな返答が返ってくるのです。
そしてエージェントは、見た目は完璧に機能するFacebookForCatsパッケージをあなたのために作り、クリックするためのリンクを渡します：http://localhost:facebookforcats/goodideabytheway
次にあなたはオフィスを歩き回って、同僚たちに自分の素晴らしい新製品を見せます。そしてあなたはそれだけ重要なので、全員がうなずいて笑顔を浮かべます。
- AWS、AIのコーディングツールが問題を引き起こすことを認める。3つの新しいエージェントで「それら」を直すと見込む
- KimとYeggeによる新しいコーディング宣言書は「AIを信じろ」と言う
- おぞましいまでの『Innovation Theatre（イノベーション演劇）』は勘弁してくれ。ハッカソンやそれに類するものだ
- IT部門の皆さん！ベンダーにぐいぐい搾り取られるのにうんざり？だったら、DO IT（自分でやってみろ）
AIエージェントが書くコードは見栄えがします。いや、見栄えがとても良い。整然としていて、実にきちんとしている。こうしたシステムは、「盗んで自分の成果として提示できる」最適なコードを見抜いて提案するのが本当に得意です。コードレビューをする経験豊富な開発者でさえ、コードレビューの場で問題を見つけるのが難しくなるでしょう。なぜなら「ほぼ正しい」は間違っているより直すのがずっと大変だからです。
自分は、アイデアから数時間で動くソフトウェアまで持っていけたから、ものすごく時間を節約できたと思うのです。でもずっと後になって気づく——あなたが節約したのは時間ではなく、単にそれを前後に振り替えただけだ、ということに。
先週、空港ラウンジで、私は自分の優れたノルウェー語（の手触り）を、新しい被害者に試すことにしました。
「Først kom den yngste Bukken Bruse og skulle over broen。Clipp Clopp、Clipp、Clopp、sa det i broen」と私は言いました。
彼らはそれなりに感心し、韻を踏めるのが面白いと告げました。けれどもその後、彼らは聞いてきました。「なんで『Clipp Clopp』って言うの？ 私たちはそんな言い方しないよ。私たちは『Tripp, trapp』って言う」
うまくいっていた——うまくいかなくなるまでは。®
