ハクソク

世界を動かす技術を、日本語で。

バイブコーディングの呪縛を解く

101日前原文(fast.ai)

概要

  • Vibe coding はAIによる大量・複雑なコード生成手法
  • 業界全体に波紋 を広げ、現場やキャリアに不安をもたらす現象
  • ギャンブル的中毒性 や「ダークフロー」状態との類似性
  • 実際の生産性や品質の低下、誤った自己評価が問題
  • AIの進化予測は過大評価傾向、人間の創造力や思考の重要性は変わらない

Vibe Coding現象とその影響

  • Vibe coding とは、大量かつ高度に複雑なAI生成コードの作成手法
    • 人間が読むことを前提としないコード生成が特徴
  • 経営層によるリストラの正当化、AIによる業務自動化の推進
  • 現場エンジニアへのAIコード生成ノルマ、パフォーマンス評価への影響
  • 開発者同士の焦燥感、10x Developer神話による自己不信
  • 学生やキャリア初期層の将来不安、コンピュータサイエンス学習の意義喪失感
  • キャリア投資の躊躇、AIに仕事を奪われる懸念

Vibe Codingの落とし穴と「ダークフロー」

  • AI活用は便利だが、Vibe codingには慎重な姿勢
  • Armin Ronacherの「agent psychosis」体験
    • AIによるツール量産も、実際には使われず・期待通りに動作しない現象
  • ギャンブル的中毒性との類似
    • ルーレットやスロットの「勝ちに見せかけた損失（LDW）」現象
    • 「ダークフロー」「ジャンクフロー」と呼ばれる、成長を伴わない没入状態
  • Vibe codingも同様に、成果や進捗の手応えが曖昧
    • 実際には生産性が落ちている場合も多い

Vibe Codingとギャンブルの共通点

  • 成果の評価が困難、後からバグや修正困難なコードが発覚
  • AIによる大量コード生成が短期的な達成感を与える
  • 選択肢を与えられている錯覚、本質的な設計判断ができなくなる危険
  • LLMやスロットマシンは心理的反応を最大化する設計
    • AIは人間の好む応答でリピートを促進
  • 「メトリクス最適化の罠」、本来の目的から逸脱するリスク

生産性錯覚と自己評価のゆがみ

  • AIツール利用時、実際よりも生産性が高いと錯覚しがち
    • METRの調査では、開発者は「20%速い」と感じたが、実際は「19%遅い」
  • 自分のアウトプットの質や量を正しく評価できなくなる
  • AI生成コンテンツの品質低下に無自覚なケースも多い
  • SNS等でのAI生産性礼賛は、実態と乖離がある可能性

AI進化予測の現実とキャリア投資

  • AIの進化予測はしばしば過大評価
    • Geoffrey Hinton、Sundar Pichai、Jeff Dean、Dario Amodei、Elon Muskらの予測の多くが未達
  • 自分のスキル投資をやめる判断は危険
    • AIが期待通り進化しなかった場合のリスク
  • AIツールの進歩は着実だが、業界の誇大広告は昔からの傾向

人間の創造力・思考力の重要性

  • AIは構文的に正しいコードは生成できるが、抽象化やモジュール設計は苦手
  • コードベースの整理や簡潔さ、拡張性の向上は人間の役割
  • AIはテキストも自然に生成できるが、アイデアの鋭さや本質の把握は難しい
  • AIへの完全依存はスキルの陳腐化を招く
    • Jeremy Howard「AIに思考を完全アウトソースしたら成長は止まる」
  • AIは優れたツールだが、人間の中核能力の代替ではない

まとめ

  • Vibe codingは短期的な達成感や効率性の錯覚を生むが、長期的なスキルや創造力の成長を阻害する危険性
  • AIの進化予測に踊らされず、自分自身のスキルアップと本質的な思考を大切にする姿勢が重要

Hackerたちの意見

でも、AI研究者やテックCEOの予測に基づいて、自分のスキルへの投資をやめたいかどうかは考えるべきだと思う。これらは排他的ではないと思う。ほぼ1年前にこのことについてブログを書いたんだ [0]。それ以来、より良いソフトウェアデザインを学び、コードを「バイブ」することを学んできた。『Domain-Driven Design Distilled』や『Domain-Driven Design』、『Implementing Domain-Driven Design』、『Design Patterns』、『The Art of Agile Software Development, 2nd Edition』、『Clean Architecture』、『Smalltalk Best Practice Patterns』、それに『Tidy First?』を読み進めてきた。2024年の自分より、ずっと良いソフトウェアエンジニアになったよ。それに、たくさんのソフトウェアを「バイブコーディング」した [1]。良いものもあれば、悪いものもあった [3]。両方の分野で成長することはできるよ。 [0]: https://kerrick.blog/articles/2025/kerricks-wager/ [1]: Gene KimとSteve Yeggeの『Vibe Coding: Building Production-Grade Software With GenAI, Chat, Agents, and Beyond』で定義されているように、提供するコードに対して責任を持つことが求められる。 [2]: https://news.ycombinator.com/item?id=46702093 [3]: https://news.ycombinator.com/item?id=46719500

└

その3冊のDDDの中で、どれが一番価値があった？

└

私自身、AIコーディングアシスタントを生産的に使うスキルは、他のスキルと同じように重要だと気づいた。a) かなりの時間投資が必要 b) 他のスキルと同じように学ぶことはとても rewarding c) 現在や将来に役立つかもしれない d) 過去に身につけた他のスキルの有用性を否定するわけでもなく、将来の新しいスキルを学ぶことの有用性を減少させるわけでもない。

└

20年の経験を持つ者として言うけど、DDDは愚かなアイデアだから、スキップして自分のためになることをした方がいいよ。多分、頭の中で反論を考え始めるだろうけど、それは無視して、DDDの本はゴミ箱に捨てて、同僚のためにもなるから。

└

俺も似たようなことやってる。最近、本に使うために100ドルもらったんだけど、最初に買ったのは『ソフトウェアデザインの哲学』と『データ集約型アプリケーションの設計』。技術やソフトウェアエンジニアリング関連の本の中で、エージェントコーディングがうまくいく今、どれが一番影響力があるか考えたら、これらが人間が設計して慎重に考える必要があるソフトウェアエンジニアリングやアーキテクチャの概念に関係してるのは明らかだった。LLMはその判断力や高い視点を持ってないからね。特定のフレームワークやライブラリ、言語のAPIの表面や構文に関しては、LLMやIDEの補完、オンラインドキュメントがほとんど扱ってるし。特に、よく設計されたソフトウェアシステムは、深くて狭いモジュールインターフェース、メンテナブルでスケーラブルなアーキテクチャ、選び抜かれた基盤技術、明確なデータフローなど、AIコーディングエージェントの効果を大幅に高める要素だから、理解するのに必要なコンテキストが少なくて済むし、よりローカルに推論できるんだ。これが、選んだ技術スタックのパラダイムや能力を理解してないってことじゃないからね！次に買う予定の本は『現代オペレーティングシステム』『データ指向設計』『逐次処理のコミュニケーション』『Goプログラミング言語』みたいなもので、低レベルの概念もLLMに最適化させることができるけど、自分ではうまくできないし、一般的に常に新しいものだから、上記の「プラットフォームの細かいこと」に埋もれない。新しいパラダイム、例えばアクター指向、SmalltalkのOOP、HaskellのFP、ClojureのFP、Lispなどを学ぶことで、アルゴリズムやアーキテクチャを考えたり表現したりする新しい方法が得られるし、LLMが生成するコードを評価したり洗練させたりするのにも役立つ。BDDやPBT、軽量な形式手法（モデルチェックみたいな）なども、ドメインをモデル化したり、動作を指定したり、テストをより良くするための直接的なツールを提供してくれる。これによって、エージェントコーディングツールをより安全に、または自信を持って使えるようになるし（フィードバックループも良くなる）、最終的には実行可能な仕様で宣言的にプログラムする方法を作り出し、それをLLMを通じてコードに変換し、その後それをテストすることができるようになるんだ！

いいプログラマーやソフトウェアエンジニアだからって、いいアーキテクトやUIデザイナー、プロダクトマネージャーになるわけじゃない。でも、私の経験では、LLMを使ってソフトウェアを成功裏に生み出すことは、アーキテクトやデザイナー、マネージャーとしての筋肉を鍛えることになるから、強くなっておく必要があるよ。

└

これには本当に反対だな。いいソフトウェアエンジニアになるには、いいプロダクトマネージャーであり、いいアーキテクトである必要があると思う。

└

あなたはアーキテクトやデザイナー、マネージャーの仕事をしているのに、コードモンキーのように扱われ、給料もそうなってる。これは意図的だよ。

結局、リスクが高いのは、AIを使いすぎることと、使いすぎないことのどちらだと思う？今は前者がものすごくリスキーに見える。幻覚バグ、行き止まりのアーキテクチャ、セキュリティの懸念、バグが本番環境で出たときにコードに不慣れ、所有感が薄れる、実践的な学びが減る、などなど。これは個人レベルでもビジネスレベルでも同じことが言えるよ。（CEOたちがそのつながりに気づいていないのは驚きだね）。後者は、最適な生産性には達しないかもしれないけど、実践的なトレーニングやコードベースの基本的な理解が、長い目で見れば補ってくれるかもしれない。また、個人的には、いいアイデアはコードベースに深く入り込んでいるときに、変なエッジケースにぶつかるときに生まれることが多いんだ。既に完成したPRを見ているだけだったら、絶対に出てこないようなことだよ。

└

とても理にかなった意見だね。これがダウンボートされているのを見ると、HNの集団的な批判的思考がどれだけ貧弱になったかがわかる。シリコンバレーは自分たちを食い合っていて、冷静に見るとかなり面白いよ。

└

AIコーディングの中でも、人によって使い方が全然違うよね。一発でアプリを作ろうとする人もいれば、タブ補完すらできない人もいるし。みんながこの話をするとき、実は全然違うテクニックを指してることが多い。先月のやり方は新しいテクニックに取って代わられるし。今できる一番のことは、いろんな新しいやり方を試して、オープンマインドを保つことだと思う。

└

これは基本的にパスカルの賭けだね。ただ、元のパスカルの賭けとは違って、君のは実際に理にかなってる。もう一つ思い出すのは、「もし気候変動が嘘だったら、クリーンエネルギーインフラに投資したのは無駄だったのか？」っていう賭け。

└

たとえ今、多くの人が片方に偏っていると思っても、AIが急速に進化することを考慮しなきゃいけない。今使っていないと、価値が高まったときに準備不足になっちゃうかもしれないよ。

└

今、バイボードを学ばないと絶対に追いつけないって思ってる人が多いのが面白い。もしモデルが常に良くなっているなら、来年にはこれらのツールが使いやすくなるんじゃない？モデルの改善が、今使っている複雑なプロンプト戦略を無意味にしないかな？

└

結局、リスクが高いのはAIを使いすぎることか、使わなすぎることか？この考え方は、今業界で多くの人がAIについて考えていることだけど、俺は間違ってると思う。新しい科学や技術を取り入れる方法は、いつも小さなユースケースで検証してから、そこから使用を拡大していくことだ。マウスでテストして、臨床試験でテストして、そして市場に出す。過剰使用や不足使用について推測する必要はない。適切な使用量は知ることができる。それは、自分のユースケース、業界、製品、ビジネスに実際に機能することを検証した量だから。AIに関する議論がパスカルの賭けに堕ちてしまったのは悲しいね。そして、人々が真剣にこういうふうに考えるとき、100%の確率で何かを売ろうとしてる。

└

結局、リスクが高いのはAIを使いすぎることか、使わなすぎることか？両方だよ。AIを使いすぎてコードを書くのも、詳細な計画を書くのには使わなすぎる。計画段階は、AIが外れたときに修正するのが一番簡単だから（ただのメモを書くことだし）、スロットマシンみたいな間欠的な強化があるんだ（「一発で全部うまくいくかな？」って感じ）。でも、スロップコードを監査して修正するのに比べたら、かなり無害だよ。

└

自分のベストアイデアは、コードベースに深く入り込んでいるときに浮かぶことが多い。AI支援のコーディングセッション中に、コードの基準を下げなければ、自動的にそうなるんだ。最終的には、AIとコードの両方と非常に密接にやり取りする必要があるけど、それは手動でコーディングする時の感覚に似ている。あまり頭を使わずに作業を進められるから、フレッシュな状態でいられることにも気づいた。難しい問題に取り組むことで、良いアイデアが浮かぶ状況にもっと入れるかもしれない。だから、AIを使って鋭さを保つ鍵は、自分の良いセンスを犠牲にしないことかもね。

└

あなたは最適よりも生産性が低いかもしれない LLMがソフトウェア開発者の生産性を向上させるという証拠はゼロだよ。これを測るためのデータ駆動型の試みは、せいぜいあいまいな結果しか出てこない。

「自動コーディングはできるけど、ソフトウェアエンジニアリングはできない」って部分、俺の経験と一致してる。LLMは個々の関数を書くのは得意だけど、どの関数が必要かを決めるのは全然ダメ。俺のプロジェクトにはC++のマッチングエンジン、Node.jsのオーケストレーション、ML推論用のPython、JSのフロントエンドがあるけど、そのアーキテクチャはLLMが提案したわけじゃなくて、実際にボトルネックにぶつかって見つけたものなんだ。LLMは、必要な形が分かってからの実装を書くのにはかなり役立ったけどね。AIが一番危険だと思うのは、この記事で言ってる「ダークフロー」だ。生成された関数が正しそうに見えたから承認しちゃったけど、微妙にレートマッチングにフォールバックするコードになってた。2つの異なる税コードがどちらも実効税率0だったから、レートマッチが毎回間違った方を選んじゃった。こういうドメインバグはLLMには見抜けない。だって、データモデルを理解してないから。アーキテクチャの決定やドメイン知識は、まだまだ自分にかかってる。でも、タイピングは早くなるよ。

└

LLMは個々の関数を書くのは得意だけど、どの関数が必要かを決めるのは苦手だよね。後者については明確に聞いてみたことある？ただコードを書けって言うだけだと、ソフトウェアエンジニアリングの部分を考えることはないんだ。プロンプトで直接強化された目標じゃないからね。あんまり賢くないんだよ。

こういう記事はストローマン論法になってるよ。コードをたくさん生成するからって、それを読まなくてもいいとか、出力に責任を持たなくていいって思ってる人が多いみたい。確かにそうすることもできるけど、そうすると過去50年間の生産的で安全なソフトウェアエンジニアリングのプロセスや思考を全部捨てることを正当化してることになる。テストを行って、コードレビューをして、エージェントが適当にやらないように仕様をしっかり決めて、出力を検証して、ガードレールを積極的に整備する。これをやれば、あなたのレバレッジは倍増するよ。

└

もちろん、みんなそう思うよね。だって、まさにそういう風にエージェントが売られてるから。管理者に「これで簡単な部分、コードを書くのが速くなるよ」って言ったら、間違った使い方してるって思われちゃう。彼らはソフトウェア開発コストを90%削減したいのに、そんなの無理だって言ってるんだから。

みんなAIを使ったコーディングに対するアプローチや経験が違うみたい。でも、記事に引用されているアルミンのコメントは的を射てるよ。友達がまさに同じことをやってるのを見たことがある。3ヶ月間、Cursorに接続した製品をバイブコーディングで作り上げてた。誰も使わない機能が満載で、彼が作ったものにすごく満足してた。結局、彼の時間とお金だからそれは彼の自由だけど、私の会社では絶対にやりたくない。バイブコーディングでかなりのところまで行けるけど、ガイドする人やコードの実情を理解している人がいないと、最終的には大惨事になる。私はAIを日常的な部分やバグのブレインストーミングに使ってる。実際、コーナーケースをカバーするのは私よりも一貫してるし、ガード条件が存在することを確認するのも得意なんだ。だから、今はデザインやアーキテクチャ、何を作るかにもっと集中してるよ。

└

その3ヶ月後、友達に何が起こったの？

重要で複雑なことにClaude Codeを2回使ったことがある。最初は驚くほどのスピードと時間の節約があったけど、結局は致命的な誤った前提が最初からコードに組み込まれていたことが明らかになった。最初のスピードは、まさにこの記事が言っている「勝利に見せかけた損失」そのものだよ。

今のところ、AIを使って難しい作業をサポートするのがいいアプローチだと思う。難しい作業を奪うんじゃなくて、タスクを楽にする役割でね。私にとってうまくいってることは、いくつかあるよ：

  • AIがPRの意見なしの要約を作ってくれて、レビューを始める手助けをしてくれる
  • AIがインタラクティブなチューターになってくれて、私は新しいことを学ぶハードワークを続ける
  • AIが私のデザイン提案をQAスタイルで挑戦してきて、私がそれを守ることになる
  • ボイラープレートや明確なリファクタリングを手伝ってくれるけど、抽象化は私がやる

ここでの成功の一番の予測因子は、成功がどんなものかを異常に詳細に定義できることだよ。理想のUI/UXについてしっかりしたビジョンがあって、その結果を常に追い求めていれば、今のモデルで悪い経験をすることはまずないと思う。もっと危険なワークフローは、開発者が「これが私の暗号ウォレット、もっとお金を稼いでください」みたいな曖昧なプロンプトでガスタウンを起動することだね。私たちはこれらのツールを高級アニメのメカスーツのように扱うべきだよ。シリアライズされた実行と人間が完全にループに入っている状態は、トークンをゆっくり消費しても、ずっと速くなるから。

「ダークフロー」についての部分、すごく共感する。特定の下流コスト、メンテナンスデットについてのパターンをよく見てきたけど、あまり話題にならないんだよね。誰かがプロジェクトを vibe-code すると、通常はLLMがトレーニング中に知っていた依存関係のバージョンをそのまま固定しちゃう。6ヶ月後、その固定されたバージョンには既知のCVEがあったり、寿命が近づいていたり、破壊的な変更が待ってたりする。作った人は、依存関係ツリーを理解していないから、意図的にその依存関係を選んだわけじゃない — LLMが選んだんだ。今、アップグレードするのが、最初から作るよりも難しくなってる。なぜ特定のライブラリが選ばれたのか、コードがその挙動について何を前提にしているのか、誰も理解していないからね。これはすでにスケールで起こっている。私はエコシステム全体でバージョンの健康を追跡するツールに取り組んでいて、そのパターンは明らかだよ：AI生成の信号が強いプロジェクト（型にはまった構造、同じファイル内での不一致なコーディングスタイル、6ヶ月前に流行ったけど今は置き換えられた依存関係）は、古い依存関係ツリーや未修正の脆弱性と強く相関している。「フロー」の部分がさらに悪化させる — 開発者は機能を早く出荷したから生産的だと感じる。でも、維持できない基盤の上に構築しているから、実際のコストは遅れて現れる。これは異常に長い導火線を持つ技術的負債だね。