プロダクトの視点を超えて考えてみると、技術的に言って、ジュニア開発者やPMが技術的に何を望むかを決めるのより悪いことは思いつかないね。キャリアの中で、週に一度はひどいアイデアを却下しなきゃいけなかった。無駄にリスクが高かったり、マイナーなユースケースを超えてスケールしない可能性があったりするから。数年後にはコンサルタントとして非常に利益が出るだろうと予想してるよ。

そのギャップが存在するのは、人々がエンジニアたちが何年もかけて正しく定義した用語を混同しているから。これは、私がソフトウェア業界で約10年観察してきた大きなトレンドの一つだ。これらの用語は、実際には水冷却器の周りでの議論や、書籍や記事、こういった技術フォーラムでの数ヶ月、場合によっては数年にわたる議論の結晶なんだ。ベテランがその言葉を口にすると、過去の会話がすぐに思い出される。新しい世代が入ってきて、その議論に参加していないから、専門家を模倣しようとして専門用語を使うけど、その言葉の裏にある実質を持っていない。単にその言葉だけを持っている。今やそれは、定義が曖昧で、複数の人にとって異なる意味を持つバズワードとして使われている。誰もその言葉の正確な定義や、自分にとっての意味を明確にできない。なぜなら、彼らは最初からその議論に参加していなかったからで、その文脈での意味や使い方を理解していないから。「アジャイル」「テクニカルデット」「DevOps」、そして今は「バイビングコーディング」。HNには「バイビングコーディング」の意味の変化についての記事があったけど、これはソフトウェア業界ではよくあることだよ。言語の雑さの他の技術的な例としては、JavaScriptのオブジェクト、JSON、辞書、ハッシュマップの混同がある。コンピュータサイエンティストにとっては、オブジェクト指向プログラミングの構成要素、シリアライズのためのJavaScriptオブジェクト表記、抽象データ型、具体的なデータ構造がそれぞれある。でも、JavaScriptプログラマーにとっては、ただの「オブジェクト」なんだ。言語的・概念的な空間の精度が、もっと解像度やニュアンスのあるものから、1ピクセルに減ってしまったんだ。[0] https://simonwillison.net/2025/Mar/19/vibe-coding/ [1] https://news.ycombinator.com/item?id=43739037

他の人たちは、ただ使い捨てコードの上にシンプル（で動いてる）ソフトウェアを作ってるだけだ。私は「動いてる」の定義をもっと明確にすべきだと思う。例えば、生成されたUIはみんな同じに見えて、微妙に間違っていたり壊れていたりすることが多い。最初は「動いてる」と思えるかもしれないけど、最初のユーザーテストで失敗することが多い。生成されたUIはすでに時代遅れに感じるし、トレーニングの瞬間に流行に従っているだけで、新しいものを生み出すことには失敗している。

そして、製品はMVPとは同じではない それ、僕が働いたほとんどの会社に言ってみてよ！最近のディレクターやC-suiteの「次の四半期までに形にしろ」っていう態度が、開発者がMVPを作って次のことに移らされるようなクソみたいな状況を生んでる。君が言ったように、実際には「バイブコーディング」なんて関係ないんだよね。ある意味、彼らの言ってることは正しい。機能の豊富さの認識が、品質に関係なく利益に影響を与えるから、実際に製品を比較してる人は少ないし、実現可能だと仮定して。開発者（今はエンジニアって呼ばれてるみたいだけど）は、最近プロトタイプを作る権限すら与えられてるのかな？確かにそういうことはあるけど、あまり一般的ではない気がする。ゲーム業界や本当のテクノロジー（「ビッグテック」じゃなくて）ではそういうことがあるかもしれないけど、ほとんどのコーディング会社はそういう余裕を持たせてくれない。結局、MVPばかりだよ。せいぜい、バイブコーディングはそのプロセスを加速させるだけで、品質は落ちる。

完璧に作られたコードは、マーケットに最初に出ることと相反するって言えるかも。僕が働いたどの会社も、MVPをそのまま進めて、どんどん機能を追加していって、市場を独占するまで行くんだよね。それから、マイクロサービスって呼ばれるものに分かれて、サービスレベルでは理解しやすいけど、同じビジネスプロセスに統合するのは悪夢みたいな状況になる。次の…MVPによる避けられない混乱につながるんだ。

過去には、異なるマインドセットを持つ他の開発者について話してた。今見ているのは、誰も理解できないコードに対する開発者の疲れだね。通常、それがエンジニアの介入を呼び起こして、壊れた部分をもっと有用でメンテナンスしやすいものにしてくれる。そしたら、アーキテクトがコードベースを見て、複雑さを減らそうとする。今は、LLM以降、開発者が書いたコードが100倍になって、エンジニアやアーキテクトは完全に無視されてる。これが今観察していることなんだ。これをテストする方法を見つけたら、例えばTDD MCPサーバーやDDD MCPサーバー（または好きなワークフローやアーキテクチャ）で、トリリオンダラーのスタートアップの可能性があるよ。コードレビューの効率をスケールさせる必要がある。今のところ、その概念は完全に壊れていて、十分にスケールしないから。

そして、製品はMVPとは同じじゃないよ ハハハ、面白いね :-)

企業が内部用にコードを書くのを見たことある？バイブコーディングと変わらないよ。ただ、LLMにペンテストを通すためにコードベースを強化するよう頼むと、何かしらのことをしてくれる。企業は本当に気にしないんだよね。

今週、うちの会社のPM（エンジニアのバックグラウンド持ち）がAI生成のゴミをチケットに投稿してきたんだ。めっちゃイライラした。こっちが「xyzコードはどこ？」って聞いたら、存在しない、妄想だった。さらに「abcのユースケースは検証した？」って聞いたら、してないって。で、PMが「この機能は簡単だ、AI生成のコードでできる」って経営陣に話を持って行ったけど、実際にはこの機能を出すために解決しなきゃいけないユースケースの5%も解決できてなかった。今の状況はこんな感じ：口だけで結果は少なく、技術的じゃない人たちがいろんな角度から同じクソみたいな話を聞かされてる。

すべてのコードは負債だけど、すべてのコードがレガシーというわけではない。私はOPじゃないけど、Vibeはレガシーだと思う。なぜなら、それを維持する資格のある人がもういないから（そもそもそんな人はいなかった）。

私の手作りコードは、少なくとも3ヶ月間はレガシーコードじゃない。その後は、変更するためにドキュメントが必要だ。バイビングコードは初日からレガシーで、スタイルが変わるとともに。

それは公平だね！できるだけ少ないコードで済ませたいというのには同意するよ。私たちは、たくさんの赤（削除行）があるプルリクエストが大好きだ。ライブラリについて言うように、自分の問題にならないコードを持つことも可能だよね。抽象化がどれだけ漏れやすいかが重要なんだ。今のところ、LLMはひどい抽象化を作っていて、良いコードを書くのが上手くなるまでどれくらいかかるかは不明だ。コードの理解をもっと簡単に、安く、楽しくするためのツールにもっと投資するのが楽しみだよ。友達のグレンがこの方向性を示してくれた： https://glench.github.io/fuzzyset.js/ui/ ジェフリー・リットが言うように、LLMは私たちのコードを理解するための使い捨てのビジュアライザーやデバッガーを作るのに役立つかもしれない。

ごめん、でもどうしてすべてのコードがレガシーコードなの？そんな深く理解して、問題の原因を頭の中で追跡できるプロジェクトを書いたことないの？エディターを開く前に機能をどう追加するかをイメージできる？古いからってだけでレガシーコードってわけじゃないよ。

でも、もっと深く考えた方がいいと思うよ。全てのコードはレガシーコードなんだから。だから、バイブコーディングがコードを書くのを早くする能力は特別じゃない。誰も理解してないコードだからね。君の手作りコードもダメだよ。これは「でも人間も」ってやつで、今の時点で認識されるべき誤謬だと思う。全てのコードがレガシーコードってわけじゃないし、開発者の頭の中で生きている小さなコードもある。レガシーコードの実用的な定義は、量が多くて、根付いていて、今の組織の誰にも所有されていないことだ。バイブコードは、作られた瞬間にその要件のうち二つを満たすことが多いんだ。

それはレガシーの意味じゃないよ。レガシーっていうのは、それを理解していた人たちがいなくなって、理解するのが難しいからメンテナンスが大変なコードが残ることを指すんだ。

クライアントの要求に応じた動作を保証するために 人間が作り上げた、エレガントな抽象化を持つ 正直、これらの選択肢を見て、どちらも実際には見たことがないなって思う…

読めない100K locのプログラムが50Kのテストに支えられて、クライアントの要求に対する動作を保証する それが外部の要求による次の変更が必要になるまで。で、このソフトウェアはビジネスの柱の一つなんだ。サービスを買っているなら、ベンダーを切り替える時だね。だから、サポートはB2Bや本格的なB2Cの重要な部分なんだ。世界は変わるし、それに反応する必要がある。今正しいソフトウェアを持っているだけじゃダメなんだよ。

// このコードを書いたとき、理解していたのはCopilotと私だけだった。今はCopilotだけが知っている。

あなたの2つのシナリオについての質問は、v1からv2に行くのがどっちが早くて安いか？v2からv3は？今のところ、シナリオBの方が安いと思う。でも未来はどうなるかわからないね！

現実世界と相互作用する十分に大きなソフトウェアシステムは、数学的な命題のように正しいと証明できるものではない。形式的検証に関わる人たちは、あなたに激しく反対するか、密かにあなたが正しいことを知っているだろう。

もっと進むかもしれないね。AIが特定の問題をモデル化（最適化）した実行可能なニューラルネットワークを生成する日が来ると思う。つまり、ニューラルネットワークのランタイムやVMで動くモデルみたいな。NNが何をしているかは、正しく仕事をしている限り気にしないよね。でも大事なのは「正しく」というキーワードで、ユーザーが信頼するためには「決定論的に」も付け加えたい。

コードにするためのワードドキュメントはなかったっけ？

これをやってるスタートアップのためにエンジェル投資家を探してるんだ。「アセンブリ」で特定のことをするモデルを訓練して、完全な「プログラム」も作る。最終的にはプロンプトを与えたら実行可能ファイルを出力するんだ。例えば、量子コンピュータよりも実際の問題を解決するのが進んでる。15を因数分解できるからね。これをHNで言うのは三回目なんだけど（もう一年以上前から）、みんな文句を言ったりClaude Codeを擁護したりするのに忙しくて気づいてないみたい。

良いソフトウェアは常にメンテナンスの状態にあるんだ。ユーザーが新しいことをしたいと思うから、要件は常に変わる。数年前、私のスタートアップでの冗談は「この機能を出したら終わりで、もう二度とコードを書く必要はない！」ってやつだった。良いソフトウェアは将来の変更を考慮して作られるから、自動テストスイートやドキュメント、コードのメンテナンス性にすごく気を使ってる。LLMにブラックボックスのゴミコードを生成させるのはひどいアイデアに思える。LLMがコーディングが上手くなりすぎて、私たちが気にしなくなるなんて、完全にSFの世界だよ。コードを書くことは、役に立つソフトウェアを提供する技術の一部に過ぎないんだから。

これがどんな問題を解決するの？逆にどんな問題を生み出すかは教えられるけど。

それって、アセンブラ以外にどんな抽象化レイヤーが必要なのかってことだよね？もし人間が手作りしたASMがコンパイルされたCよりも優れてるなら、LLMにASMを任せてもいいんじゃない？それともう一つの疑問は、良いASMの例が十分に公開されてるかどうかだね。

これが物理学者たちの気持ちなんだろうね。誰かがロガン風の量子力学のナンセンスを語り始めると。

次のステップは、人間が読めることを意図していないプログラミング言語になるんじゃないかな？マルボルグは数十年前のものだし。最初の「ハローワールド」は遺伝的アルゴリズムで作られたらしいよ。

そうだね、LLMを人間の認知に最適化されたコードでトレーニングして、そのコードをコンパイラに戻して行動を作り出すのは、まるで電話ゲームみたいだよね。直接行動を作れないのかな？

それは価値があったの？うん、ひどくて、質の悪い、安全でないコードだけど、彼は数百ドルの投資で実行可能なビジネスを証明したんだ。彼のアイデアを正しく再実装するために誰かを雇うのにどれくらいかかるんだろう？

でも、彼の顧客は二度目も彼を信頼するかな？

競合他社のせいだとは思わない方がいいね。責任を逃れようとしてるみたいだし。実際に起こったのは、彼のサイトがどんどん進化してるエクスプロイトクローラーにスキャンされたってことだと思う。インターネットに公開されてるサイトを運営してる人なら、何のことか分かるよね。彼のサイトが脆弱だとマークされて、ハッカーがスイスチーズみたいに穴だらけだって知って、楽しんじゃったんだ。

ほんと、スクリプトキディはどこにでもいるし、脆弱なコードがあったら、見つかるのは時間の問題だよ。

友達が何の影響も受けずにそのまま続けられるってのが、この業界の問題そのものだよ。完璧な世界だったら、ソフトウェアの作成は他の工学分野のように厳しく管理されて、開発者や企業が顧客情報を漏らしたら法的な責任を負うことになってたはず。

それは価値があったの？うん、ひどい、雑な、不安定なコードだけど、彼は数百ドルの投資で実行可能なビジネスを証明したんだ。でも、顧客にとってはあまり良い結果には感じないね。お金を払って、データを不安定にさらけ出してるのに、製品はやっとやろうとしてることをやってるかどうかって感じ。 > で、今は開発者を雇って改善しようとしてる。これ、思ってるよりずっと大変だよ… AIを参考や生産性向上の助けとして使うのには賛成だけど、人間が関与しない結果はすぐにひどいことになるからね。

彼が作ったものは、ほぼ定義上、プロトタイプだった。問題は、よくあることだけど、そのプロトタイプが本番環境にデプロイされちゃったこと。今回は、あまり詳しくない友達のせいでもあるけど、ソフトウェアエンジニアリングの歴史が示すように、顧客や上司のプレッシャーでこうなることもある。だから、実現可能性を証明したり顧客にデモするために設計されたプロトタイプが、実際のソフトウェアになっちゃうことが多いし、AIがその望ましくない結果をさらに簡単にしてしまう。うちの業界では、過去の失敗を繰り返す運命にあるみたいだね—永遠に。

だから、データ漏洩に対して強い金銭的罰則が必要なんだ。セキュリティを軽視する会社は、雰囲気の衛生状態で閉店させられるレストランと同じように、閉鎖されるべきだよ。「ああ、何人かを中毒にしちゃったけど、見て、どれだけ早く準備したか！」

すでに市場にプレイヤーがいる場合、ビジネスが成立することを証明する必要があったの？いや、ないよね。安い選択肢が出てきたときに、みんながプロバイダーを切り替えるかどうかを検証する必要がある？これもない。じゃあ、彼は何を学んだのか？最初は人々が払うかもしれない部分的な解決策を作れるってこと（更新に関するデータはなし）だけど、最終的には本当に製品を作るために人を雇わなきゃいけなくなる。それが彼の差別化要因（価格）を食いつぶすんだ。マーケティングにお金を使わなきゃいけないって気づくまで待ってみて。良いニュースは、これらの経験を通じて、アイデアがあっても実行する能力がなければあまり価値がないって「検証」できることだね。

それは価値があったのか？うん、ひどい、粗悪で、安全性のないコードだけど、彼は数百ドルの投資で実現可能なビジネスを証明した。そして重要な要素は？顧客への完全な軽蔑だね。

使い捨てのために作られたプロトタイプが悪いことになったのはいつから？ビジネスを構築するための最も重要なステップだと思うよ。レガシーコードも悪いことじゃない。今、実際に収益を生んでいるコードの大半は、そこで働いている開発者から見たら「レガシー」と見なされてるだろうね。

うん。レガシーコードの面白い定義は、トランクにマージされたもの全てだよね。