バイブコーディングのカルトは狂っている

2026年4月7日原文(bramcohen.com)

概要

Claudeのソースコード流出 とその質の低さが話題
Dogfooding（自社製品の徹底利用） の行き過ぎが原因
Vibe coding という極端な開発手法の問題点
AIを活用したコード品質向上 の可能性
ソフトウェア品質は 開発者の意識と選択 によるもの

Claudeのソースコード流出とDogfoodingの暴走

Claudeのソースコード が流出し、その質が低いと 世間の笑いもの に
原因は dogfooding （自社製品の徹底利用）の過剰な実践
本来dogfoodingは 自社製品の品質向上 のための手法
しかし、 極端なdogfooding は「vibe coding」という形に発展
Vibe coding とは、製品の内部構造に一切関与せず、表面的なやり取りのみで開発を進める姿勢

Vibe Codingの問題点

人間の貢献が全くない わけではなく、言語や設計の基盤は人間が構築
計画ファイル（ToDoリスト）やルール、スキル などのインフラ整備も人間の役割
「 純粋なvibe coding」は神話であり、実際は人間の介入が不可欠
内部重複や冗長性 の存在を誰も積極的にチェックしない
- 例： エージェントとツールの重複 を誰も指摘しない
コードは英語で書かれており、誰でも読める にもかかわらず、開発者は中身を見ない

ソフトウェア開発における技術的負債とAI活用

ソフトウェア開発には技術的負債がつきもの
かつては 一年間掃除だけで終わる ほどの負債が一般的
AIを導入することで、短期間で負債整理が可能
AIはコードの整理や改善が得意
人間とAIで対話しながら方針を決める ことで、より高品質なコードが実現

適切なAI活用によるコード改善の流れ

例： 「エージェントとツールの重複をリストアップし、分類・統合する」プロセス
- 人間がAIに問題点や方針を説明
- Askモード でAIと議論し、曖昧な部分や誤りを修正
- 十分な対話後、AIが高速にタスクを実行
Claudeチームはこのプロセスを怠り、dogfoodingに固執
全く中身を見ずに抽象的な指示だけで開発 を進める姿勢

良質なソフトウェア開発のために必要なこと

AIを使っても、品質の悪いソフトウェアに甘んじる必要はない
悪いソフトウェアは開発者の選択の結果
人間の意識と主体的な関与 が重要
AIと人間の協働で高品質なソフトウェア開発 が可能
「悪いソフトウェアは決断の産物」 という認識の重要性

Hackerたちの意見

それから、私が何をすべきだと思うかを説明して、私が考えを出し尽くすまで、そして機械が修正が必要なバカなことを言わなくなるまで、ずっと話し合いを続けるよ。著者のようなユーザーは、Claudeの最も貴重な資産だと思う。AI自体は製品じゃないからね。出力を形作るのは人々のフィードバックなんだ。

└

著者のようなユーザー彼はかなり面白い人だと思う。彼の作品は、これまで多くの人に影響を与えたんじゃないかな。

ちなみに、この人がビットトレントを作った人だよ。昔のことだけど、ただのランダムなブロガーじゃないからね。

└

ブラムが最近いろいろやってるのを見ると嬉しいな。HNに二回目の登場だね。

└

彼のバックグラウンドを考えると、自分の立場を支持する証拠を示すべきだって分かるはずなのに（完全に裏付けのない愚痴を言う代わりに）。

それは、バイブコーディングの概念に対する大きな違反にはならないよ。内部を少し読み取っているけど、問題をどう解決すべきかについての高レベルで概念的、抽象的なアイデアを出しているだけだ。実際の執筆はほとんど、いや、文字通り全てを機械がやっている。Claude CodeはAIレベル7（人間が仕様、ボットがコーディング）で生成されているけど、著者はAIレベル6（ボットがコーディング、人間が多少理解）での方がずっと良い結果が得られると主張している。私も同意するけど、これについては人それぞれ意見が違うことを指摘したい。中には、最大AIレベルは5（ボットがコーディング、人間が完全に理解）にすべきだと言う人もいるし、もちろんAIレベル2（人間がコーディングして少しアシスト）を超えると地に足がつかなくなると思っている人もいる。

└

ある人は、最大AIレベルは5にすべきだと言っている > もちろん、AIレベル2を超えると地に足がつかなくなると思っている人もいるこの枠組みが時々細かさを失わせることがあると思う。人生のほとんどのことと同じように、これらのアプローチにはニュアンスがある。最近、私のメインプロジェクトでは「自律エンジニアリング」の概念に本当に傾いているので、AIレベル7が完璧だと思っている。出力に対して厳格なQAプロセスを通じて資格を与えられる限り（つまり、出力が正しく見えればコードが何をするかは重要ではない）。でも、このプロジェクトではAIの「ハンズオフ」メソッドに本当に傾いているけど、AIがどれだけうまくやるかによってレベル5や4に落ちる部分もある（特にフロントエンドデザイン）や、機能の重要性によって（私の場合はE2EE）。最も重要なのは、スケールを「上」や「下」に動かす必要がある時を認識し、構築しているシステムを理解することだよ。

└

今はレベル5だけど、たくさんのガードレールを実装してるし、nullがない型付き関数型言語を使ってるから。TDDの赤/緑もやってるし、仕様書を書くのにもかなりの時間をかけてる。ダイナミック言語でここまで安心できるとは思えないな。追加のツールと、もう一つの最大20アカウントがあればレベル7には行けるかもしれないけど、今作ってるプロダクトに対してはあまりにも気を使ってるから。もっと気にしないものなら別だけどね。個人的には、7以上を目指すなら、静的型付けで安全な（表面積が小さい）言語を選んだ方がいいと思うよ。自分でコードを書くことはないだろうし。

└

https://visidata.org/ai レベルのリストありがとう。これで、どういう風に進んでいるのか、他のエンジニアと比べて自分がどこにいるのかを理解するのに役立つよ。自分は大体AIレベル5くらいで、インターフェースを完全に理解してテストできるときにはAIレベル6に行くこともあるけど、実装は完全には理解してないかな。エージェントがチームメンバーとして働くのと、チームで作業するのとあまり変わらないよ。

└

面白いレベルの分解だね。いいと思う。ただ、レベル7がほとんどのプロジェクトに存在するとは思えないな。大抵の非トリビアルなプログラムには、実装に関する深い知識がないと仕様を作るのは不可能だよ。そんなの無理だよ。面白い問題のほとんどでは、仕様には実装の詳細やアーキテクチャ、重要なデータ構造が含まれなきゃいけない。結局、別の言語でコードを書いてるだけで、手動で構造体の宣言を書いた方が良かったってこともあるかもね。

└

面白いリストだね。これから数年で最も進歩するのは、そのリストの最高レベルに自分を押し上げる人たちだと思う。今は激しい変革の時期で、自分の生活スタイルが終わったことを受け入れたくないコーダーがたくさんいる。今でも鍛冶屋はいるけど、大半は工場や安い第三世界の労働で作られてる。今、コーディングでも同じことが起きてると思うけど、5年前のチーム全体がやってたことを、単独のビルダーやデザイナーができるようになるんだ。

└

仕事ではレベル4だけど、サイドプロジェクトは恥ずかしいことにレベル6に達しちゃった。機能をそのまま受け入れるのはすごく魅力的で、どう動いてるのか理解する時間を取らないで済むから。

Hacker Newsで議論の続きを見る

ハクソク