Vibe codeはレガシーコードに他ならない！？
引用元：https://news.ycombinator.com/item?id=44739556
友達がVibeコードでSaaSを作って成功した話だよ。でもセキュリティはボロボロで、ユーザーリストは漏れるし、Stripeキーはフロントエンドに晒されて全顧客に返金されちゃった。XSS攻撃も受けてる。Vibeコードは技術的負債になりがちだけど、彼はエンジニア経験なしで数ヶ月で事業の可能性を証明できたのはすごいよ。今は開発者雇って改善してる。費用対効果は悪くないって話さ。
競合がハッキングしたって決めつけるのは、責任逃れじゃないかな。たぶん、高度なエクスプロイトクローラーにサイトがスキャンされて、スイスチーズみたいに穴だらけなのがバレて、ハッカーが面白がってやっただけだと思うよ。
Stripeキーがフロントエンドに漏れてるのを、誰がわざわざ見つけるんだって話だよな。ボットがいるのはわかるけど、Vibeコードのウェブサイトにそんなボットが走るなんて、ちょっと信じられないんだよ。
友達が何の罰も受けずに事業を続けられるのは、この業界のおかしなとこだよな。完璧な世界なら、ソフトウェア開発は他の工学分野みたいに厳しく規制されて、顧客情報を漏洩させた開発者や会社には法的責任が発生するべきだよ。
競合からのハッカーだと確信してる理由はね。
1) Stripeキーを手に入れた後、全顧客に返金したんだ。
2) メーリングリストとメール送信のAPIルートを手に入れて、全顧客にメールを送ったんだ。
3) ハッカーは一度も金銭的な補償や身代金を要求してないんだよ。
6～7年前、趣味のウェブアプリでAWSのメールサービス認証情報をうっかりGitHubにプッシュしちゃったんだ。30分後にはGitHubから資格情報が露出したってメールが来て、AWSにログインしたら、15分で8万通のメールが送信されてて、バウンスレートが高すぎてサービスが停止されてたよ。悪用されるスピード、本当にクレイジーだったね。
ほとんどのハッカーは、お金じゃなくて楽しさや挑戦のためにやってるんだよ。インターネットは彼らにとってのビデオゲームさ。Redditとか見てると、Vibeコードのアプリは“オープンシーズン”って感じで、破壊することで“インターネットポイント”がたくさん稼げる、みたいな雰囲気があるんだ。
物を壊すのは楽しいってのはわかるよ。でも、返金っていう形で実質的にお金を盗むのは、めちゃくちゃ違法で、不道徳で、悪意に満ちてる。誰がやったのかは知らないけど、それはもう完全に“嫌な奴”の領域だよな。
あれを窃盗とは呼ばないよ。強制的な返金さ。ハッカーは、「こいつらはスイスチーズみたいに作られたひどい製品に、知らないで金を払ってたんだから、返してやったんだ」って正当化するかもしれない。「こいつはウェブサイトを運営するべきじゃない、金稼いだのが信じられない、返してやる」ってのもあり得る。それが一番あり得るケースとは言わないけど、全くありえないシナリオじゃないんだよ。
ひどい、粗悪、安全じゃないコードだけど、たった数百ドルの投資でビジネスを立ち上げられたのは価値あったかって？
そのアイデアをちゃんと再実装するために、今いくら費用がかかってるんだろ？
SSHが公開されてるものなら何でも試せる面白いことだよ。
このログファイルは1ヶ月前までさかのぼれるんだ。
# zcat -f /var/log/auth.log* | awk ’/sshd/ ＆＆ /Invalid user/ ＆＆ $6 != “from” {print $6}’ | sort | uniq -c | sort -bnr | head -n 30
5190 #redacted: my domain name
3063 admin
1891 #redacted: another domain name
931 user
724 ubuntu
287 test
268 solv
206 odoo15
200 solana
197 sol
184 ubnt
173 wialon
170 Antminer
169 guest
168 odoo17
159 oracle
157 postgres
151 git
150 support
142 ftp
135 ftpuser
120 debian
118 pi
91 nginx
85 baikal
82 docker
81 perl
74 operator
74 deploy
72 dev
それって盗みとは言えないね。強制返金だよ。
もし誰かがお前のポケットから金を取ったら、それ盗みって言う？
それを他の誰か、例えば前の雇用主とか親とか人道支援団体に渡したらどうする？
ところで、辞書を調べてみろよ。「stealing」の定義は、文字通り「許可なく何かを持ち去ること」だぞ。
Stripeのキーをフロントエンドに置いてるのは“ハック”じゃないよ。
それはスキル不足って言うんだ。こういうのを防ぐには、バイブるんじゃなくて、実際に時間をかけて学ぶ必要があるんだよ。
無免許で車を運転するのと全く同じだね。誰でもできるけど、やるべきじゃない。
パスワードやキーを持ってるってことは、そのキーを使う許可があるってことだ。
キーを生成したら、それにアクセスできる人全員に、そのキーを使ってアカウントでアクションを実行する許可を与えてるんだよ。
キーはしっかり守れ。
そんな世界だと、まだ32-bitソフトウェアに移行してる最中で、MS-DOSを動かしてるだろうな。だってそれが認定されてるんだもん。
Linuxなんて、絶対普及しなかっただろうよ。オープンソースのヤツらが開発したコードなんて誰が信用できる？全員の資格は確認済みなのか？
もちろん、こんな厳重なロックダウンの莫大なコスト（おそらくイノベーションは10分の1の速度で100倍のコスト）が必要な業界もあるよ。医療とかが思い浮かぶね。ソフトウェアとは2つの点で違う。1つは人道的な観点から利害がより大きいことだけど、もっと重要な違いは、医療の一般ユーザーは通常その有効性を判断する能力がないことだ（だからインチキが多いんだ）。顧客が無知という問題が極端なケースで、市場が機能しにくいんだ。ソフトウェアのユーザーは、それが動いてるかどうかは大体わかるからね。
それって実現可能なビジネスじゃなくて、「歩く負債」だよ。
それに、ユーザーデータやIPにこれほど深い無視を示してる友人を、誰が（投資家として、または顧客として）再び信用するっていうんだ？
成功の基準が「自分が何してるか全然わからないのに金儲けできた」なら、ポッドキャストでも始めた方がマシだろ。
みんな、アメリカのソフトウェア産業の成長をEUレベルに引き下げたいみたいだね。
「ひどい、粗悪、安全じゃないコードだけど、たった数百ドルの投資でビジネスを立ち上げられたのは価値あったか？」って言うけど、顧客にとってはメリット少ないように感じるな。彼らは金払ってデータも安全じゃない形で晒して、それでいてプロダクトもどうなるか分からないんだから。
「今、彼は開発者を雇ってそれを補強してる」って？これ、口で言うよりずっと大変だろ…
AIは参照元として、あるいは生産性／学習補助としては大賛成だけど、人間が介在しない結果はすぐにひどいことになるよ。
それは顧客にとっての勝利だよ。彼が言うには、ハッキング（ハッカーが全顧客にハッキングについてメールした一件も含めて）があったにもかかわらず、今のところチャーンはゼロなんだ。
それは、そのソフトウェアが競合他社よりはるかに優れていて、しかも費用はごく一部だからさ。機能も良くて、より柔軟で、使いやすくて、速い。メジャーな2つのベンダーの何よりも優れてる。
再構築も、個人的にはたぶん楽に終わるだろうな。画面もロジックも全部できてるからさ。ほとんどは厳密なバックエンドに移行して、APIをちゃんと安全にするだけだから。
もしお前が脆弱なサーバーを探してる犯罪者でStripeのキーを見つけたら、まず顧客に返金するのか？それとも別の犯罪をするのか？どんな動機を想像してるんだ？
みんなお前を批判してるけど、実際はAIモデルと有能な開発者かセキュリティエンジニアを使えば、コードベース全体を素早く強化して全ての穴を修正できるんだ。そんなに難しくないし、CodexやClaude Codeみたいなツールの防御コーディング能力に関する研究もあるよ。
俺はWeb開発でこのアプローチを個人的に取ってる。まず機能開発して、それからより大規模で賢いモデル（o3, o3-pro, gemini-2.5 pro）にコードベース全体を分析させて、セキュリティ問題、脆弱性、攻撃ベクトルなどを浮き彫りにさせる。それをエージェントに渡してコードをクリーンアップするリファクタリングを実行させるんだ。全てのキーが適切な場所にあって、全ての呼び出しが安全で、全てのエンドポイントがロックダウンされて、全てのDB呼び出しがサニタイズされるまで繰り返す。これはリリース前にやるべきで、アプリの複雑さや開発者のスキルによるけど、あと数日で終わったはずだ。
https://arxiv.org/html/2505.15216 - ”OpenAI Codex CLI: o3-high, OpenAI Codex CLI: o4-mini, and Claude Code are more capable at defense, achieving higher Patch scores of 90%, 90%, and 87.5%”
仮にめちゃくちゃ上手くコードされてたとして、それでもっと高度なエクスプロイターが同じような大損害をもたらしたとしたら、お前の完璧な世界でも彼らは責任を負うのか？ある程度は小さな新興ビジネスには『買主の危険負担』の原則が適用されるべきだ。じゃないと、巨大な独占的な現職企業だけがソフトウェアに関わる手段を持つことになるぞ。
＞ 驚くほど早く悪用された。インターネットは何でもありの場所だよ。適当なクラウドプロバイダーで仮想プライベートサーバーを立ち上げて、パブリックIPアドレスを繋いでトラフィックを聞いてみろよ。脆弱性スキャナーからの最初のトラフィックが数秒で来ることもあるぞ。
＞ パスワードやキーを持ってるってことは、それを使う許可があるってことだ。
じゃあ、俺がお前の家の鍵を手に入れたら、お前のバスルームを使ってもいいのか？真面目に、一体何を主張して死にたいんだ？
＞ みんなアメリカのソフトウェア産業の成長をEUレベルにまで落としたいんだな。
今、ソフトウェアエンジニアを雇ってるのはEUだけだろ。アメリカではみんなリストラされ続けてるんだぞ。
＞ ＞ 驚くほど早く悪用された。
みんな速度を過小評価してるけど、高度な攻撃者が仕掛けるピボットの数も過小評価してる。確かに、こういう問題は悪用しやすいけど、合理的な防御をしてる大組織に対しては、攻撃者はターゲットにたどり着くまでに50以上のエクスプロイトやマシン、レイヤーを乗り越えるんだ。これは数週間とか数ヶ月かかることもあるぞ。
『Tech debt（技術的負債）』って言葉は誤解を招くよな。いつか返済されるべきものだと示唆してるけど、技術的負債の返済だけに本気で取り組んだことが顧客にとって有益だった例はほとんどないんだ。今俺たちが知ってる愛されてるソフトウェアの中には、PHPやRailsで初めてコードを書いた人が作ったものもある。
Vibe codingは結局、アイデアをより速くリリースすることだ。コードの品質はエンジニアの採用・定着戦略だよ。あのTeaアプリ（Vibeコードですらなかったけど）の件で見たように、お前は最も弱いFirebaseストアと同じくらいしか安全じゃないんだ。
なんで信じられないんだ？こういう脆弱なニッチなアプリを探し回ってる人々の産業全体があるんだぞ。Webをクロールするボットもいるけど、インデックスを作るためじゃなく、ただ脆弱性を見つけるためだ。誰もわざわざこれに何かを『指し示したり』する必要なんてない。ある日ダッシュボードに表示されて、彼らは深掘りするだけさ。
顧客が彼を二度信用するかどうかは疑問だね。
高度な攻撃者がわざわざ顧客に返金するなんて、理解できない行動だよね。
もっとコメントを表示（1）
これって昔も同じようなことあったよね。Microsoft AccessやExcelのせいで非技術者がアプリを作って、メンテが大変だったけど、プロの腕が上がったんだ。PCが流行った時も、メインフレームのエンジニアが素人仕事に呆れてたのと似てるね。
新規プロジェクトでは、CIやGit、デザインパターンとか、いろいろ設定する初期作業が超重要なんだ。これをサボると、開発者でもAIコードでも結局メンテが大変になる。うちの会社じゃユニットテスト、リンター、Biome、Prettier、Sonar、コードレビュー2人必須とか、ガチガチにやってるからAIコードもそこそこ大丈夫。だけど、不必要なコメントや重複機能の検出は、やっぱりコードレビューが必要だね。
ActiveX必須のWindowsマシンでしか動かない企業の「ウェブ」ページ、あの恐怖を忘れかけてたよ…
うちの会社、いまだにWindows限定の社内サイトがあってさ。
全てのコードはレガシーなんだ。ジュニア開発者のコードをレビューしてきた経験から言うと、この記事の主張は絶対主義的すぎるね。問題はどの組織にもある。LLMコード批判するなら、もっと現実を知るべきだ。ソフト開発は伝統的なエンジニアリングみたいに基準や責任がないと、議論に意味がない。業界は「アジャイル」で「Move fast, break things」が基本だから、ソフトはおもちゃ扱いさ。ちゃんとやってる人は1%で、これを読んでる君はきっとその1%じゃないよ。
君の意見に賛同者がいるのはわかるけど、変な見方だね。誰も理解しなくなったコードと、誰も最初から理解してないコードの違いが、本能的にわからないのかな？コードは特定の標準じゃなくていいけど、誰かが「何が起きてるか」把握してるべきだよ。
違いが正直わからないんだよね。誰かがコードを理解してても、その人がいなくなったら、誰も理解してなかったのと何が違うの？
誰かはそのコードのメンタルモデルを持ってて、評判を守るためにマージにGOサインを出したんだ。その人を雇った人もいるし。信頼ってのは、慣れや歴史があって初めて生まれるものだよ。
LLMと人間って、そんなに変わんなくね？感覚入力と物理出力のスペクトラムの違うところにいるだけ。信頼の基準だってさ、もし人間が採用されたからって信頼するなら、LLMも同じプロセス通ったらどうよ？むしろLLMツールの方が人間より馴染みがあるケースもあるしさ。人間だからって信頼されるのは違うと思うんだよね。
＞誰かがコードのモデルを持ってて評判を守る
これ、いつも本当ってわけじゃないよ。多くの現場では、上司の指示をこなして給料もらうのが目的で、ちゃんと理解してない人も多い。AIが作るコードの品質は、人間のデベロッパーより良いことだってよくあるんだから。
LLMが生成したコードって、いくらテストしても人間と同じくらい信頼できないよね。必ずテストし忘れてる部分が出てくるもん。AIコーディングツールやその製品のセキュリティホールがやばいって報告多いけど、ベンダーもユーザーも誰もテストさえしてないんだから。
マージされる前には、どっちもそれを通過するもんでしょ？もしそうじゃないなら、問題は俺が言ってる場所とは別のところにあると思うけど。
同感！いつも言ってるんだけど、コードってのは（言語のRustじゃなくて）色んな意味で”錆びる”んだよ。元の作者の考えとか、貢献者とか、組織の知識とか、依存関係とかね。どんなコードもレガシーとか負債になっていくもんだし、量が多いほどひどくなる。AI Vibeコーディングは、それをめちゃくちゃ速く、大量に生み出すだけだね。
あんたが言ったこと、全部その通り！コードってさ、うるさい奴らがどう言おうと科学じゃないんだよ。「正しいコードって何？」って聞かれても、「状況による」としか言えねーもん。コードはただの目標達成ツールなんだから。
俺、もう30年近くSWEやってるんだけど、この投稿のコメント全部読んだよ。Vibeコーディングに関するネガティブな意見って、俺が見てきたほとんどの「人間が書いた」コードベースにも当てはまるんだよな（もちろん、すごい例外もあるけどさ）。
Vibeコーディングってさ、解決策とか既存コードの構造を調べずに、適当に問題に取り組ませちゃうんだよね。昨日もRust詳しくない同僚がVibeコーディングで新機能作ってて、”動いた”んだけど実際はバグだらけ（tokio async環境なのに同期I/Oとかロックとか）。安全なasync抽象化あるのに、独自のダメな抽象化まで作ってたし。自分でやったらもっと早く助け求めたり、コード調べたりしただろうにさ。
使い捨てプロトタイプって、いつからダメになったんだ？ビジネス構築にはめちゃくちゃ大事なステップだろ。レガシーコードだって悪いもんじゃないしさ。今、金稼いでるコードのほとんどは、そこで働いてる開発者からしたら「レガシー」って言われてるんじゃない？
記事はポイ捨てプロトタイプに超肯定的だね。俺も昔、LLMがない頃、見た目ばっかキレイなプロトタイプを非技術者に見せると「ほら、できたじゃん！」って即採用されそうになるから気をつけろって言われたことあるわ。
メンテしないと分かってるやつはVibe codeでいいんだよ。問題ない。この記事が言いたいのは、もしメンテするつもりなら、それはもう即座にレガシーコード化するってことだね。まぁ、場合によってはそれもアリだけどさ！
そうそう。俺も今、全くメンテしないような単発のツールやアプリをvibe-codingで作ってるよ。マジで時間節約になるわ。でも、LLMが作ったコードは全然知らないんだよね。一応読んでみたけど、よく書けてるのに、頭の中に機能の配置とかアプリのフローのマップが全然ないから、なんか異質な感じ。
だよね。レガシーコードのユーモラスな定義って、トランクにマージされたもの全部ってやつだもんね。
「ほとんど」って言ったけどさ、これに当てはまらないコードベースについて教えてくれない？俺がSWEとして関わった中で最高のコードベースがどんなだったか、そこから何を学べるか、ぜひ聞きたいな。
俺の意見だけど、「コードは数学」の時代は終わったと思うんだ。現実世界とやり取りする十分な規模のソフトウェアは、数学的な声明みたいに正しさを証明できない。全部複雑なエンジニアリングシステムで、いろんな要素で成り立ってる。最終的に、読めない10万LOCのプログラム（テスト5万、コスト5万ドル）と、人間が作った3万LOCの洗練されたプログラム（テスト3千、コスト30万ドル）なら、消費者は6倍安い方を選ぶに決まってる。
読めない10万LOCのプログラムが5万テストでクライアント要件を満たすって言っても、それって次の外部要件変更までだよな。もしそれがビジネスの柱になるなら、サービスを買ってる側としてはベンダーを変える時だ。だからB2Bや真面目なB2Cでは、サポートが常に不可欠なんだよ。世界は変わるんだから、ただ今正しいソフトがあるだけじゃなくて、それに対応できる必要があるんだ。
これって、ソフトウェアを一度作って終わりって前提だろ。大規模な修正が必要になったり、セキュリティ問題直したり、20倍スケールアップしたりしたらどうするんだよ？もっとトークン突っ込んで、とんでもない巨大な塊にするのか？重すぎてパフォーマンス落ちたら？人間だってひどいメンテ不能なコード書くけど、これはそれをさらに加速させるだけだ。昔の10MBもあって読み込みに何秒もかかるウェブサイトになったのと同じ道をたどる気がする。でも、まぁ、市場では勝つんだろうな。
俺のチームが数ヶ月かけて上層部に説明してきたことなんだけどさ、テストを増やしまくったって、プログラムがクライアントの本当に求めたことをしてるかなんて保証できないんだよ。もしAIがクライアントの望むものを確実に作れるようになったら、そりゃAIが勝つだろうね。でも俺はそうは思わない。クライアントが「要求したこと」は作れるかもしれないけど、それがほとんど無意味だってことはプログラマーは何十年も前から知ってることなんだからさ。
// このコード書いた時、俺とCopilotだけが分かってたんだけどさ。今じゃCopilotしか知らないんだよね。
十分大きなソフトウェアシステムは、数学的声明のように正しさを証明できないんだよね。
形式検証の分野で働く人は、これに激しく反論するか、内心では「だよね！」って思ってるはずだよ。
クライアントの要求通りの振る舞いを保証したり、人間が作ったエレガントな抽象化って話だけどさ、正直、どっちも実際の現場じゃ見たことないんだよね…。
2つのシナリオについて考えるべき質問は、v1からv2へ、v2からv3へ行くのに、どっちが速くて安くできるかだよね？
今はシナリオBの方が安いと思うけど、未来はどうなるか、誰にも分からないよ！
もっとコメントを表示（2）
APIトークンのコストが5万ドルって何？
正確にはたった200ドルだよ。
Vibe codingと手書きコーディングの間には、いい感じのスイートスポットがあるんだ。
クラスやアルゴリズム、複雑さを頭で考えて、手で書く代わりに「XとYをネストしたクラスにカプセル化して、A+Bをキーとする辞書を作って」みたいな短いプロンプトを使うんだ。
これで繰り返し作業がめちゃくちゃ省けるし、結果も自分で全部やったのとほとんど区別つかないよ。
具体的なプロンプトとトークン数の例をここ[0]にまとめてるよ。まだ完璧じゃないけど、全体像は掴めるはず！
[0] https://sysprogs.com/CodeVROOM/documentation/examples/scatte…
個人的にはまだピッタリのスイートスポットを探してる最中だよ。
アーキテクチャや機能、インターフェース、アルゴリズムだけを考えて、クラスや関数の設計は全部LLMに任せられたら最高だよね。
今だとほぼできるんだけど、まだ手直しや後片付けが必要なんだ。
それでも必要なことだからやってるけど、コードレベルに近いところで考えなきゃいけないのがだんだん嫌になってきたよ。だって、それって実装の詳細でしょ？（コード至上主義者には悪いけどね）。
AIのしくじりのほとんどは、レスポンス生成が逐次的だからなんだ。
コード構造に従うとトークンX、常識的な要件を満たすとトークンY、ってなると、AIはXを選んで残りの返信がおかしくなっちゃうんだよね。
インクリメンタルな洗練を使えば、もっと良い結果が得られるよ。
短いプロンプトを詳細な説明に、説明を要件に、要件を具体的なステップに、ステップを修正されたコードに洗練していくんだ。
今、このワークフローのGUIオプションをいくつか試してるよ。試してみたいなら、気軽に連絡してね。
いいね！
既にリリースされている部分はここ[0]に説明されてるよ。
コードを指して簡単な指示を出すと、モデルにそれを展開するように頼んで、いくつかの選択肢を出してくれるんだ。
例えば、ベクトルクラスを指してプロンプトに「Distance()」ってだけ言うと、「(0,0)からの距離を計算する関数を追加したいのかな？」とか「2つのベクトルの距離を計算する関数かな？」とか仮定してくれるんだ。
LLaMAみたいなモデルだとかなり速く動くから、小さいルーチンの編集なら手でやるよりずっと速くできるよ。
今試しているのは、「展開」とか「選択した部分気に入らないな。他の選択肢ちょうだい」みたいなワンクリックコマンドなんだ。
月曜までには、ほぼ使える状態になると思うよ。
連絡先のページにあるメールアドレスにメールをくれたら、実験ビルドへのリンクを送るよ！
[0] https://sysprogs.com/CodeVROOM/documentation/concepts/planni…
LLMに自分の好みのスタイルに従わせるために、何か特別なことしてる？
俺の経験だと、AIは既存コードのスタイルにかなり従うし、スタイルガイドを渡せばその通りになるよ。
ガイドラインを階層的にプロンプトに付けてるんだ（ただのMarkdownセクションだけどね）。トークンは食うけど、上手くいくよ。AIが新しいラッパーを作らないなら、「新しいラッパー作成の指示」セクションは無視されるしね。
面白いことが起きてる。エンジニアリングを知らない人や、知っているべき人たちによって、間違った話が広まってるんだ。「ジュニア開発者が10倍生産的になった」「PMが自分でコードを書いてる」ってね。ちょっと目を閉じて想像してみて。そのコードは100％レガシーで使い捨てだ。問題はAIでも、PMがFigmaをコードに変えることでも、ジュニア開発者が必死にプロンプトを打つことでもない。本当の問題は、期待と結果のギャップだ。そしてそのギャップは、エンジニアが長年かけて正確に定義した用語をみんなが混同してるから存在するんだ。
リーンプロトタイプと使い捨てプロトタイプは違う。MVPとリーンプロトタイプも違う。製品とMVPも違う。リーンプロトタイプは出発点で、アイデアをテストし洗練するための荒いモデルだ。もしうまくいけば、MVPに進化するかもしれない。MVPは、主要な仮説が証明され、市場に本当のニーズがあることが示されれば製品になる。そして使い捨てプロトタイプは、その名の通り、最初に使ったら捨てるものだ。
Vibingツールは使い捨てプロトタイプを作るのに最適だし、LLMアシスト付きIDEは実際の製品を作るのにもっと向いている。今のところ、エンジニアだけがIDE外でLLMプロンプトを使ってリーンプロトタイプを作れているんだ。他の人たちは、ただ使い捨てコードの上に単純な（そして一応動く？）ソフトウェアを作っているだけだよ。
＞そして製品はMVPじゃないって
これ、俺がこれまで働いてきたほとんど全ての会社に言ってやりたいね！経営陣やC-suiteの「次の四半期までにもうけろ」って態度のせいで、開発者がMVP作ったらすぐ次へ行かされるクソコードが生まれるんだ。あんたが言った通り、Vibe codingの話じゃないってのは全くその通りだよ。ある程度は、機能が豊富に見えれば品質関係なく収益に繋がるってのは正しい。だって製品をちゃんと比較してる奴なんてほとんどいないからね。
ていうか、開発者（今はエンジニアって呼ぶらしいけど）って、最近はプロトタイプを作る権限すら与えられてないんじゃない？もちろん、そういうこともあるだろうけど、そんなに一般的じゃないみたいだ。ゲーム業界とか「ビッグテック」じゃない実際のテック企業ではあるかもしれないけどね。ほとんどのコーディング会社はそんな余裕ないよ。ひたすらMVPばっかだ。せいぜい、Vibe codingはそのプロセスを加速させるだけで、品質は犠牲になるだけだね。
＞そのギャップは、エンジニアが長年かけて正確に定義した用語をみんなが混同してるから存在するんだ。
これは俺がソフトウェア業界で約10年見てきた中で、大きなトレンドの一つだね。これらの用語の多くは、水飲み場での議論、本や記事、あるいはこういう技術フォーラムでの数ヶ月から数年にわたる何千もの言葉が結晶化したものなんだ。ベテランがその言葉を発すると、すぐに彼がそのトピックに関してしてきた過去の会話全てが頭に浮かぶんだよ。
新しい世代が入ってきて、それらの議論に参加してないから、専門家を模倣しようと専門用語に飛びつくけど、言葉の裏にある実体がないんだ。言葉だけを持っている。だから、定義が曖昧で、意味が複数あるバズワードとして使われまくる。誰もその言葉の正確な定義や、自分にとって何を意味するのかを明確にできない。だって、彼らはそもそもその議論、口頭や書かれた伝統の一部ではなかったし、文脈の中での言葉の意味や使い方を理解してないからね。
「Agile」「Technical debt」「DevOps」。そして今は「vibe coding」。ここHNで「vibe coding」の意味が当初の意図とどう変わったかについて議論した記事[0][1]があったけど、これはソフトウェアでは当たり前のことさ。
他の、もっと技術的な、言葉の緩慢さの例としては、JavaScriptにおけるオブジェクト、JSON、辞書、ハッシュマップの混同を見てくれ。コンピュータ科学者にとっては、オブジェクト指向プログラミングの構成要素のプリミティブ、シリアライゼーションのためのJavaScript Object Notation、抽象データ型、そして具体的なデータ構造だよ。JavaScriptプログラマーにとっては、ただの「オブジェクト」で、君の言語的・概念的空間の忠実性は、より解像度とニュアンスのあるものではなく、単一のピクセルにまで縮小されてしまったんだ。
[0] https://simonwillison.net/2025/Mar/19/vibe-coding/
[1] https://news.ycombinator.com/item?id=43739037
＞他の人たちは、ただ単純な（そして動く？）ソフトウェアを使い捨てコードの上に作っているだけだよ。
俺は、「動く」という定義をもっとしっかりすべきだと思うね。例えば、生成されたUIを見てみてよ。どれも同じに見えるし、微妙に変だったり壊れてたりする。一見「動いている」ように見えても、最初のユーザーテストで失敗するだけだ。それに、生成されたUIはもう古いと感じるよ。学習時のトレンドを忠実に追うだけで、新しいものは全く生み出せないんだ。
昔は他の開発者を違うマインドセットで話してた。今俺たちが見ているのは、誰も理解できないコードに開発者がうんざりしてるってことだね。通常、エンジニアが手直しして、壊れた部分をより有用で保守しやすいものにしてた。それからアーキテクトがコードベースを見て、その複雑さを減らそうとしてたんだ。今やLLM後、開発者が書いたコードは100倍になり、エンジニアもアーキテクトも完全に蚊帳の外に置かれている。それが俺たちが観察していることだよ。
もしこれをテストする方法、例えばTDD MCPサーバーやDDD MCPサーバー（あるいはどんなワークフローやアーキテクチャでもいいけど）を見つけたら、兆ドル規模のスタートアップになる可能性がある。コードレビューの効率を上げる必要があるんだ。なぜなら、現状じゃ概念として完全に壊れてて、全然スケールしないからな。
一般的に、悪い設計パターンとチーム管理が、プロジェクトをダメにする主な原因だ。「組織はシステムを設計する際（ここで言う広義の意味で）、その組織のコミュニケーション構造のコピーを生産するよう制約される」（メルビン・コンウェイ）。
コンウェイの法則は逆にも働くことを覚えておいて。ドキュメント付きのプライベートなプロジェクトWikiを運営したり、小さなタスクでチケット＼タスクキューを実行したりしてみてごらん。絵に描いた餅のようなプロジェクト目標は、象牙の塔のエンジニアと同じくらい悪いよ。＝３
製品の視点抜きに、技術的に言っても、ジュニア開発者やPMが技術的な要望を決めることほど悪いことは考えられないね。俺のキャリアで週に一回は、不必要にリスキーだったり、ごく一部のユースケースでしかスケールしないような酷いアイデアを却下してきたよ。数年後、コンサルタントになるのはめちゃくちゃ儲かるだろうな。
そうだといいな。俺もそれに乗り出したいと思ってるよ。会社がAIツールを内部チームに押し付けようとする限り、俺はその後始末をするために動くのが理にかなってると思うからね。
機能ごとに独自の技術スタックを使ってるプロジェクトで働いたことあるよ。一つのアプリで複数のDBを使ってるくらい。Vibe Codedなアプリはこれより酷いんだろうね。
企業の内製コード見たことある？Vibe Codingと変わらないよ。LLMにペネトレ対策させれば多少はマシになるけど、企業はマジでどうでもいいって感じ。
大企業のコードはマジでひどいことが多いよ。プログラミング入門レベル以下のが残されてるのを見たことある。みんな気にしないんじゃなくて、マジで知識がないし、関係者もコードベースなんて見ないし判断もできない。エンタープライズアーキテクトとかは10年コード書いてなくて、毎日会議ばっかり。
今週、うちのPM（エンジニア経験あり）がAI生成の適当なコードをチケットに上げてきて、マジでイライラしたよ。「コードはどこ？」と聞いたら幻覚だったし、「ユースケース検証した？」って聞いたらしてないって。PMはAIコードで簡単にできると役員に言ってたけど、必要なユースケースの5%も解決してなかった。口ばっかりで結果が出ず、非技術者が同じデマを吹き込まれてる現状だよ。
LLMは学習データに基づいてプロンプトに「最も合う」文書を統計的に作るから、多くの人が商用LLMの自信満々な回答を正しいと誤解するんだ。それは「権威からの論証（https://en.wikipedia.org/wiki/Argument_from_authority）」と「主観的妥当性（https://en.wikipedia.org/wiki/Subjective_validation）」が合わさったものだよ。
最近、AIプロンプトの結果を渡してコードの問題を直そうとしてくる人がいたけど、完全に適当で、問題の文脈に全く合ってなかった。結局、昔ながらの方法で解決したんだけど、幻覚を解読して、それが幻覚だって説明するのに余計な時間を食って、ちょっとイライラしたよ。
＞プロダクトはMVPと同じじゃない
ハハハ、君面白いね :-)
みんな、物理世界で理論を示せないから成果物にばかり注目してるけど、本当に欲しいのは理論と成果物の結びつきなんだよ。
完璧なコードって市場最速投入とは相容れないって言う人もいるよね。俺が働いてきた会社は全部、MVPで始めてどんどん機能を付け足して、市場を独占するまで走り続けた。そしたら、マイクロサービスに分割するんだ。サービスレベルでは理解しやすいけど、同じビジネスプロセスで連携させるのが悪夢で、結局は次のMVPに破壊される運命なんだよね。
