バイブコーディングで40分で動くアプリを作り上げたとき、それは最高だった。そして2つ目の機能を追加しようとしたら、ジェンガタワーのように全部崩れた。AIエージェントで何か本物を届けたことがある人なら、この感覚を知っているはずだ。バイブコーディングは最初の80%では信じられないほどうまくいき、本当に重要な部分では悪夢になる。
話がすれ違わないよう、言葉を定義しておこう。バイブコーディングとは、自然言語でやりたいことを説明し、エージェントに書かせ、結果をざっと確認して、感覚のまま進み続けること——ちゃんとしたレビューなし、アーキテクチャなし、ただバイブと勢いだけ。速い。楽しい。そしてデモの先では通用しない。これが私の辛口な主張で、私はそれを擁護するつもりだ。
最初の1時間が魔法に感じる理由
どんなプロジェクトの初期段階にも制約がない。壊せる既存コードはなく、守るべき規約もなく、昨日の挙動に依存しているユーザーもいない。エージェントは白紙のキャンバスを受け取り、それを埋める。当然速い。慎重さを求めているのではなく、生成を求めているのだ——そして生成こそ、これらのモデルが最も得意とすることだ。
ちなみに、これには本物の価値がある。プロトタイプ、スパイク、使い捨てのコンセプト検証には、バイブコーディングは正しいツールだ。アイデアを画面に映し出し、作る価値があるか確認して、捨てる。私はこれを毎週やっている。メモなし。
間違いは、そのプロトタイプのスピードが続くと思うことだ。続かない。
どこで崩れるか
コードベースに状態が生まれた瞬間——既存のパターン、実際のデータ、誰かが依存している機能——計算式がひっくり返る。今や、すべての変更が既存のものと整合していなければならない。そしてバイブコーディングには整合性を確保するメカニズムがない。なぜなら「整合的」が何を意味するかを知るほど深く見ていないからだ。
3つ目の機能に差し掛かったエージェントが、APIエラーの処理に3種類目の全く異なる方法を発明するのを見たことがある。頭が悪いからじゃない。他の2つが存在することを誰も教えなかったからであり、バイブの中では何かが厄介な形で壊れるまで気づかない。コードベースは考古学的発掘現場になっていく——6つのスタイル、4つの状態管理アプローチ、2つの日付ライブラリ、そして認証をこなす handleStuff という名前の関数。
バグはさらにひどい部分だ。バイブコーデッドのバグは隠れる。コードは正しく見える——モデルはもっともらしく自信たっぷりなコードを書く——だからざっと確認して、コンパイルが通り、ハッピーパスが動き、先へ進む。バグは3機能後にエッジケースがついに発火して浮かび上がる。そして今、自分が実際には読んでいなかったコードをデバッグしている。書いたというコンテキストすら持っていない。
スキップしたレビューが支払う請求書になる
誰も聞きたくない話をしよう：バイブコーディングのスピードは、一部を未来から借りたものだ。レビュー作業をスキップしているわけじゃない。先送りしているのだ、利子付きで。レビューされていないdiffはそれぞれ小さな借金だ。デモが早く出るのは、たくさん借金をしたから。プロダクトが止まるのは、支払いが一度に来るから——たいてい最悪のタイミングで。
だから、バイブコーディングのプロジェクトは3週目あたりにチームが壁にぶつかる。最初の機能は飛ぶように進んだ。今は速度が落ちていて、誰も理由がわからない。これが利子だ。コードベースに形がなく、形のないコードベースは変更が容易になるのではなく、困難になっていく。
本物になったときに私がすること
私はまだほぼすべてにエージェントを使う。ただ、それがプロダクトになった瞬間からバイブを止める。変化はこう見える：
- すべてのdiffがマージされる前に読む。ざっと見るじゃない。読む。理解できなければ、リリースしない。
CLAUDE.mdまたは同等のものを維持して、規約を固定する——エラーの扱い方、状態の管理方法、認めているライブラリはどれか。エージェントはそれを読む。整合性が運任せでなくなる。- 非自明なものにはエージェントにテストを書かせ、私が実行する。テストが通ることが「正しく見える」と「正しい」の差だ。
- 小さくレビュー可能な単位で作業する。1つの機能、1つの明確なdiff、1回のレビュー。「ダッシュボード全体を作れ」という一気呵成のプロンプトではなく。
これは遅くない、正確に言えば。意図的なんだ。エージェントはまだコードを書く。私はただ、実際に何が起きているかを知っている人間としてループに戻っただけだ。
正直なフレーム
バイブコーディングの混乱を引き継ぐとき、常に実行するコマンドがある：
git log --oneline -20 && git diff HEAD~5 --stat
何がどれだけ変わったか確認する必要がある。バイブ中は誰もトラッキングしていなかったから。バイブコーディングのプロジェクトでまず最初にすることは、説明責任を再導入することだ——diffに対して、テストに対して、規約に対して。
バイブコーディングは悪くない。それは一段階だ。ブレインストーミングであって、原稿ではない。痛い目を見るビルダーは、決して卒業しない人たちだ——プロトタイプのワークフローをプロダクションのワークフローとして扱い、なぜアプリがぐちゃぐちゃになったのかと首をかしげる人たちだ。
何を作るかを発見するためにバイブを使え。そして実際に作るために、ハンドルに手を戻せ。デモはどちらにせよあなたを愛してくれる。プロダクトはコードを読んでいるときだけあなたを愛してくれる。