バイブコーディング崇拝は狂っている
(bramcohen.com)- Claudeのソースコード流出をきっかけに、「バイブコーディング(vibe coding)」への盲信が実際のプロジェクト品質にどのような害を及ぼすかが明らかになった
- バイブコーディングはコード内部をまったく見ないことを原則とするが、これは純粋な迷信にすぎず、実際には計画ファイル、スキル、ルールなど人間による構造設計が必ず伴う
- AIはコード重複・技術的負債の整理のような作業に実際きわめて優れているが、それを活用するには人間が直接コードを見て問題を把握し、AIに説明する必要がある
- AIが自発的に「スパゲッティコードがあるので整理しよう」と認識することはまれで、人間が方向性と文脈を先に与えるときに高品質な成果物が生まれる
- 「悪いソフトウェアは開発者の選択」という言葉のとおり、品質低下はAIではなく意思決定の結果である
- つまり、ソフトウェア品質の低下はAIのせいではなく、開発者が自ら下す選択である
Claudeソースコード流出とバイブコーディングの問題
- Claudeのソースコードが流出し、コード品質が低いという理由で多くの人から嘲笑を受けた
- この問題の原因として、ドッグフーディング(dogfooding)の行き過ぎ、つまり自社製品を過度に盲目的に使う文化が指摘された
- 自社利用そのものはよい考えだが、あらゆる合理的な限界を超えるカルト的活動へと変質しうる
バイブコーディングの実態
- バイブコーディングはコード内部にいかなる貢献もせず、さらには見もしないことを原則とする手法
- しかし**純粋なバイブコーディングは神話(Myth)**である — 実際には計画ファイル（ToDoリスト）、スキル、ルールなど人間が作ったフレームワークが必ず存在し、この構造なしではAIは非常に低い性能しか発揮できない
- コードは英語で書かれていて誰でも読めるにもかかわらず、「内部を見るのは反則だ」という理屈で開発者たちは自分で確認することを拒んでいる
- 実際に人間が1人コードを確認した結果、エージェントとツールの間に大規模な重複が存在することが判明し、これは誰かが少し見れば簡単に気づける問題だった
AIと技術的負債の整理
- ソフトウェアプロジェクトはしばしば技術的負債を抱えたまま始まり、以前はその整理だけで1年かかることもあった
- AIを活用すれば、この整理作業を数週間で終えたり、新機能開発と並行して段階的に解消したりできる
- AIはコード整理に非常に優れているが、自力で問題を検知する能力は乏しい — 人間が「ここにスパゲッティコードがある」と伝え、ガイドを与えるとよい結果が出る
正しいAI活用法 — 対話ベースのアプローチ
- 重複問題を解決する正しい方法として、次のような段階を提示している:
- エージェントとツールの両方に該当する項目の一覧を作る
- 例を確認したうえで各項目がエージェントかツールかを判断する
- 全体の基準を議論し、一般的なガイドラインを定める
- 全項目を監査し、誤分類された項目を修正する
- 両方に存在する項目は2つの版を確認して1つに統合する
- Askモードはこのプロセスのためのもので、例を一緒に確認し、AIが過度に同意しようとするときに誤りを正す過程が核心となる
- 十分な対話の後には、AIがワンショット(one-shot)のように見える結果を出したと感じるかもしれないが、実際には事前の多くの人間との相互作用が前提になっている
- Claudeチームはこのプロセスなしにドッグフーディングを極端に適用し、コード内部を少し見て問題を説明するという最小限の努力すら拒んでいる
実際の活用例
- 自身のワークフローの例: 対話の開始時に「このコードベースで到達不能コードを監査しよう」または「この関数は見るだけでつらい」と言って会話を始める
- 実行可能な方向性が出るまで対話を続け、やるべきことを説明したうえで、AIがばかなことを言うのをやめるまで議論を続ける
- その後、計画を立ててビルドを実行するのが日常的なやり方である
ソフトウェア品質は選択の問題
- AIを使うからといって低品質なソフトウェアを受け入れなければならないわけではない
- AIの助けなしに過大な報酬を得る開発者たちが作ったライブラリでも、品質が悪いことはある
- 悪いソフトウェアは自ら下す決定の結果であり、それに責任を持ち、よりよい品質を追求すべきである
9件のコメント
AI AGENTでFULL AUTO MATIONしながらコード生成、マージ、レビュー、検証まで完全に自律化して、コードが組み上がって自分はまったく気を遣わなくても、たまにエージェント同士がこんがらがった時や開発者が介入する程度で十分だ、そうできない開発者はトレンドについていけない異常者扱いするような空気がやたら広がっていたが……。普段どれだけボイラープレートなコードを量産し、単純なパターンの繰り返しみたいなコードを書きながら高給をもらっていたのか、そしてAIでもうコードを書かなくていいと大口をたたく連中を見ると、情けないの一言に尽きる。
もっとも些細な部分にまでマイクロマネジメントして、ようやくそれらしい品質のコードが作れます。完全自律化なんて、本当にボイラープレートコードを大量生産するときでもない限り、あり得ないと思います。完全自律を語る人は、二つに一つです。よく分かっていないか、あるいは詐欺師かです。
中途半端なプロジェクトが氾濫し…
プログラミングを半端にしか知らない人たちは熱狂し…
dogfoodingは独占ではなく、ドッグプディングと捉えたほうがよさそうです。dog食...
タイトルと内容が違う…？
バイブコーディングが結局は「コードレビューをしない」に短絡されて、そこに理由をこじつけているタイプの非難のように見える。
それにClaude Codeを持ち出すのも筋が通らない。たとえばLinuxのメンテナンス級のエンジニアリング原則のような、そのレベルの品質を問うのであれば、コード品質の問題をこんなふうに断片的には扱わない。ほとんどがプロパガンダ的なアプローチで、実際に自分で試したわけではなく、「そうらしい」と語っているだけだ。
まるで「サムスンの建物デザインはいまひとつだから、まだソニーに追いつくにはほど遠い」と言っているのに近い。
Claude Codeを初めて使ってみたとき、外国人の友人たちに「自分、初めてバイブコーディングしてみた！」と言ったんですが、その友人たちは私の話を聞くと「いや、それはバイブコーディングじゃないよ。本当にコードを一切見ないことこそがバイブコーディングだ」と返してきたんです。韓国でよく言われる「バイブコーディング」は、西洋で定義されているものよりずっと広い意味で使われているようです。Hacker Newsで言うバイブコーディングは、「コードレビューをしないこと」と定義されるのが正しいです。
Hacker Newsの意見
人々が Claude Code の流出したソース品質を例に挙げて、「vibe coding」は失敗だと言うのは奇妙だ
むしろ逆だと思う。従来の「良いコード」のルールを破っていても、人気があり成功した製品を作れることの証拠だ
締め切りのせいでその場しのぎで作ったコードが、そのまま本番に残ることは多い
個人プロジェクトでも最初のコミットはひどいもので、後になって整理用ブランチを作って整える
だが会社では二度目、三度目のドラフトを作る時間はほとんどなく、結局最初のドラフトがデプロイされる
正直、自分の名前が付いたコードが流出しないか心配になることもある。だがこれが現実だ
コード変更時に「これはちょっと無理があるな」と感じたら、その場ですぐ直すのが結局は時間の節約になる
LLMについてはまだ経験が浅いので、確信はない
Claude Codeは本質的にシンプルな製品で、本当の価値はモデル自体にある
つまり、コード品質が低くても大きな問題になりにくい 低リスクな製品 だから、こういう事例が成立した
これも「Vibe coding」の概念に反しているわけではない。高水準の抽象的なアイデアだけを与え、実際のコードはAIが書く構造だからだ
Claude Codeは AI Level 7（人間が仕様、ボットがコード）のレベルで、筆者はLevel 6のほうがよいと主張している
理想的なレベルは人それぞれだ。Level 5以下が限界だと見る人もいれば、Level 2以上は危険だと考える人もいる
分野の複雑さや新規性によって、適切なレベルは変わる
たとえば、私が作るアプリではアルゴリズム部分はLevel 0、UIはLevel 7、ミドルウェアはその中間くらいだ
各コード領域に合ったレベルを見つけることこそ本当の技術だ
動的言語ではこれ以上は不安だ。もしLevel 7以上に行くなら、静的型付け言語へ完全に移行したほうがいいと思う
コーディングは今後、鍛冶仕事のように一部だけが残り、大半は自動化されるだろう
だがそのおかげで、一人でかつてチーム全体がしていた仕事をこなせるようになる
仕組みを完全には理解していないまま機能を受け入れてしまう誘惑が大きい
この記事の筆者は BitTorrent の創始者だ。単なるブロガーではない
私がClaude Codeをもっとも気に入っている用途は コード品質の改善 だ
人がやると時間の無駄に見えることでも、AIならほぼ無料でやってくれるので問題ない
反復的なテストパターンの整理、JSONシリアライズの一貫性維持、重複コードの除去など
結果としてコードベースは小さくなり、保守しやすくなる。いわば 大規模なlint のようなものだ
各モデルの結果を相互検証し、最後にOpusが最終リストを作って修正する
不要な変更は多いが、見つけてくる問題は実際に有用だ
「Dogfooding」の観点が興味深い
論点はコード品質ではなく、ユーザーが AIの結果を批判的に評価できるか どうかだ
経験豊富なエンジニアが判断力を保ったままAIを使うのと、判断そのものをAIに委ねるのとではまったく違う
問題はツールがこの両者を区別できず、マーケティングは後者に向けられている点だ
「Vibe coding」を支持する人たちは、LLMは人間よりはるかに速く 反復（iteration） できるのだから、コード品質は重要ではないと主張する
人間は各段階（作成–検証–修正）のコストが高いが、LLMはトークンコストだけで高速に反復できる
だが私はこのアプローチに懐疑的だ。実際に壊れる事例をあまりに多く見てきた
それでもLLMがさらに進化すれば、彼らの言う通りになるかもしれない
「Vibe coding」のスペクトラムには二つの層がある
一つは技術的背景はないが面白がって好んでいる人たち、もう一つは AI嫌い の人たちだ
その間には静かだが生産性の高い中間層がいる。彼らは楽観的でありながら経験も豊富だ
私もこの6か月でClaude Codeのクレジットに約2500ドル分を使ったが、その大半は実際にはデプロイされなくても 非常に大きな価値 を得られた
「Claude Codeは役に立たない」という主張には同意しない
ほとんどのWebアプリは単純なCRUDレベルだ。99%の企業は5万人のユーザーすら抱えていない
私が働いていた会社では、非効率なコードのせいで1日22時間もプログラムを動かさなければならなかった
この現象は Clayton Christensenのイノベーション理論 を思い出させる
既存企業は収益性の高い現行製品に安住し、新しい低品質技術を無視するが、最終的にはその技術が十分に進化して市場を覆す
Claude Codeもすでに「十分に良い」水準で、AIが進歩し続けるなら、最終的には手作業のコードを上回るだろう
「Vibe coding」を取り巻く人々はいくつかの類型に分かれる
①金銭的な利害関係者、②コーディングに疲れた開発者、③初めて何かを作ってみる新人
②は新しいことを学びたがらず、③は純粋に創作の楽しさを感じている最中だ
AIコーディングは彼らにとって良い 入門ルート になり得る
私もその類だ。30年間コーディングを愛してきたが、想像したものを形にするまでにかかる時間が長すぎた
今はそのギャップが消えつつあり、解放感がある。品質を保ちながら速度を上げる方法を学ぶのが目標だ
大企業の問題をそのままなぞったせいで生産性は落ち、疲労感だけが増えた
今ではAIのおかげで、そうした複雑さを無視して直接結果を得られる
新しいフレームワークやデプロイ方式が出てきても気にする必要はない。AIが全部処理してくれる
技術の世代交代が起きるたびに、こうした衝突は繰り返される