バイブコーディングは、まるで告白のように扱われます。誰かが、モデルが書いたコードを一行も読まずに動くアプリを作ったと認めると、部屋の反応はまるで安全点検をサボったと告白したかのようになります。ここで擁護したい主張はこうです。その反応はおおむね間違っている、と。構文を自分でタイプしないことは、自分が何をしているか分かっていないことと同じではありません――それは判断力をどこに振り向けるかの違いであり、人々が作るものの大部分にとっては、それこそが正しい配分なのです。
この言葉自体はまだ生まれてほんの数年しか経っていないのに、すでに背負う意味が多すぎます。外からは同じに見える、まったく異なる二つの振る舞いに使われています。
- 欲しいものを丁寧に説明し、結果を現実の基準に照らして確認してから出荷する人。
- 曖昧なアイデアを貼り付け、スクリーンショットをちらっと見て、うまくいくことを願いながら本番に push する人。
バイブコーディングを批判する人々は、たいてい、正しくも後者の人物を指しています。しかし彼らはまるで前者の人物が存在しないかのように、あるいは両者が怠惰の度合いだけが違う同じスペクトル上にいるかのように語ります。実際は、まったく同じスペクトル上にはいません。一方はワークフローであり、もう一方はワークフローの不在です。
かつてのスキルは本当は何のためにあったのか
コードを一行ずつ読み、スタックトレースを3ファイル先のヌルポインタまでたどる――それ自体が目標だったことは一度もありません。それは、変わっていないひとつの目標――このものは自分が必要とすることを、安全に行っているか、明日もそれを信頼できるか――に答えるための、当時唯一利用可能な手段だったのです。30年間、その問いに答える唯一の方法は、言語に十分に精通してその仕組みを直接調べられることでした。だから流暢さが能力の代理指標となり、やがてその代理指標自体が目的そのものと取り違えられるようになりました。人々は「差分を読める」ことを、目的のための手段ではなく道徳的な美徳のように扱い始めたのです。
検証がその流暢さを必要としなくなれば――ビルドが何をテストし、何が通過し、レビュアーエージェントが何を指摘したかという記録を自ら生成するようになれば――その代理指標はもう必要なくなります。本来の問いに戻れるのです。動くか。信頼できるか。私たちがすべてのビルドに検証記録を組み込んだのは、まさにこの問いが「人間がソースコードを読んだかどうか」を経由しない答えを必要とするからです。なぜなら、ほとんどのビルダーにとって、プロンプトがあろうとなかろうと、それはもともと起こり得なかったことだからです。誰もWordPressプラグインのPHPコードを読んではいませんでした。
そのスキルは実際にどこへ移動したのか
それは仕様策定へと移動しました。そして仕様策定は聞こえるよりずっと難しいものです。誰かが本当に優れたビルドプロンプトを書くのを見れば、シニアエンジニアが設計文書に対して発揮するのと同じ規律が見えるはずです。
- 受け入れ基準は何か?
- 明示的に対象外なのは何か?
- チェックアウト時にカートが空だったエッジケースでは何が起きるか?
- 誰がこのデータを見られて、誰が見られないのか?
曖昧なプロンプトが曖昧なアプリを生むのは、曖昧なチケットが曖昧なプルリクエストを生むのとまったく同じ理由からです――ゴミの制約からはゴミの出力しか出ません。それを成立させるのにモデルは関係ありません。AIツールでうまく製品を出荷している人たちは、思考をスキップしているわけではありません。彼らはその思考を早い段階に、つまり最初のエラーの後の2時間ではなく、最初のメッセージを送る前の15分に移動させただけなのです。
移動したスキルの残りの部分は、レビュー段階での判断力であり、それはコードを読むというより、ビルドの要約とその検証記録を読んで、適切な懐疑的な問いを投げかけることに近いものです。「返金処理に対応」というのは、返金が途中で失敗するケースにも実際に対応しているという意味なのか?ハッピーパスだけでなく、空の状態もテストしたのか?これは本物のスキルであり、「Pythonを読めるようになる」が時間と適性を持つ一部の人にしか教えられなかったのとは違う形で、教えられるものです。私は、プログラミング経験ゼロの店主が、自分の在庫アプリについて、そのコードを書いていないエンジニア以上に鋭い検証の問いを投げかけるのを見たことがあります。なぜなら、その人は自分のビジネスを知っていて、自分にとって何が「壊れている」状態を意味するのかを正確に把握しているからです。それは本物のスキルの代わりを務める劣ったスキルではありません。その人のビルドにとっては、構文よりもずっと関連性の高いスキルなのです。
嘲笑を実際に正当化するストーリー
ここで一歩譲歩します。批判者たちは何もないところからこれを作り出しているわけではありません。バイブコーディングには本当にひどいバージョンが存在し、嘲笑が的を射るのに十分なほどよくあるものです。
- ログインシステムを構築し、緑のチェックマークを見て、そのログインシステムがどのデータにアクセスできるのか、トークンなしでリクエストが来たときに何が起きるのかを一度も問わずに出荷してしまう人。
- 自然言語プロンプトから構築したデータベースクエリを、ユーザー入力がエスケープされずにそこへ到達するかどうかを確認せずに出荷すること。
検証記録は、ビルドが実行されテストが通過したことを教えてくれます。しかし、そのテストが正しいものをカバーしていたかどうかは教えてくれませんし、あなたがその記録を見ようとしなければ、デプロイを止めてもくれません。
それが、どれだけツールが優れたものになっても動かない土台です。自分のビルドにとって「完了」が何を意味すべきかを把握し、チェックマークを盲目的に信頼するのではなく、実際にその記録を読む責任は、依然としてあなた自身にあります。
手を抜くことは、新しい種類の能力ではありません。それは古い種類のいい加減さが新しい服を着ているだけであり、まさにその通りの評判を受けるに値します。批評家たちが犯している間違いは、それが唯一のあり方だと決めつけていることです——その失敗が存在するからといって、規律が存在しえないわけではありません。規律は存在します。ただ、かつての規律とは違う見た目をしているだけであり、構文の流暢さでしか能力を測ってこなかった人々には、まだそれを見抜く方法がないのです。
あと数年もすれば、この言葉はおそらく色褪せていくでしょう。「ハッカー」という言葉が「器用ないじくり回し屋」という意味から、もっと不穏な何かへと狭まり、その後また緩やかに広がっていったように。最終的に残るのは、本当の違い——ずっと重要だったもの——です。すなわち、丁寧に仕様を定義し、自分の成果を確認するビルダーと、そうしないビルダーの違いです。そこに至るために使ったツールは、そもそも本質的な問題ではなかったのです。
