2026 年 2 月 17 日に Red Hat Developer で公開された The uncomfortable truth about vibe coding（バイブコーディングについての不都合な真実）は、バイブコーディング がここ数年で登場した開発手法の中で最もエキサイティングであると同時に最も危険なものでもある、という実務家の主張である。著者はバイブコーディングを、すべての行を自分で書くのではなく AI と対話しながらソフトウェアを構築することと広く定義し、個人的な経験に基づいて書いている。数か月で 5 つのコンセプトを形にし、3 つの MVP（実用最小限の製品）を作り、かつては何四半期分もの夜を費やしていたようなプロジェクトが今では週末で済むようになったと報告している。
記事の主張は、このスピードは単純で自己完結したプロジェクトでは通用するが、プロジェクトが大きくなるにつれて崩れていくというものであり、その解決策はバイブコーディングを放棄することではなく、プロトタイピングの段階が終わったら 仕様駆動開発 に移行することだとしている。
要点
- 著者は、バイブコーディングが特定の用途——手早いプロトタイプ、フラッシュカードアプリ、ランディングページ——ではうまく機能することを認め、自然言語は人の考え方に合っており、開発者が「どう」作るかではなく「何を」作っているかに集中できるようにすると論じる。
- 著者はある失敗パターンを描いている。プロジェクト開始から数か月たつと、小さなことを 1 つ変えるだけで他のいくつもの機能が壊れ、修正するたびに別の何かが壊れる——自分のコードベースを相手にした「もぐら叩き」である。著者は、多くのバイブコーディングのプロジェクトが 3 か月前後で壁に突き当たると述べている。
- 著者はこれを、AI が賢くないせいではなく、仕様なしに構築したせいだとしている。指示はコードが生成された瞬間に陳腐化し、コードがソフトウェアの振る舞いについての唯一の信頼できる情報源となるが、コードはなぜそう振る舞うのかを説明するのが苦手である。そのため、決定の背後にある意図が失われ、コードベースは、AI のコンテキストウィンドウも含めて、誰も把握できない規模にまで膨らんでしまう。
- 仕様駆動開発は、その関係を逆転させるものとして提示される。仕様が、コードが従わなければならない、権威ある、バージョン管理された設計図となり、何かが壊れたときには、開発者はコードを編集するのではなく仕様を洗練して再生成する。著者は、これが最初は余分な作業になることを認めつつ、最新の状態が保たれるドキュメント、仕様レベルでの協働、1 か所で済む変更という形で元が取れると論じる。
- 著者は、開発者は依然として技術的である必要がある——アーキテクチャ、依存関係、制約、トレードオフを理解している必要がある——と論じる。その理解なしに書かれた仕様は「ウィッシュリスト」にすぎないからである。そしてこの変化を、アセンブリから高水準言語への移行になぞらえる。抽象化は変わったが、能力の必要性は変わらなかった。
- 仕様駆動のワークフローの中でバイブコーディングがなお居場所を持つのはどこか、という問いに対する記事のルールは、ユニットレベルである。ユニットテストや機能テストで出力を検証できるなら、その範囲はバイブで作ってよいほど小さい。そうでなければ仕様が必要である。著者はこれを、プロジェクトをもぐら叩きの罠から遠ざけるものとして提示する。各部品は、より大きなシステムに組み込まれる前に、単独で検証できるからである。
- 記事は、バイブで作ることと構築することの橋渡しをするために登場しつつあるツールとして、Amazon の Kiro、GitHub の GitHub Spec Kit、Codeplain、Tessl を挙げている。また、GitHub の研究部門が 2023 年にこの領域を探っていたことにも触れている。構造化された自然言語を使ってコードを生成する実験的プロジェクト SpecLang であり、製品として出荷されることはなかった。
背景
この記事は、測定に基づく研究ではなく、著者自身のプロジェクトや逸話に根ざした一人の実務家の主張である。3 か月という数字は著者の観察であり、報告された統計ではない。記事の処方箋は、どちらかを拒否することではなく、2 つのモードの間の分業である。締めくくりの言葉にあるとおり、探索にはバイブを使い、構築には仕様を使え、ということである。