バイブコーディングのバグが特定の箇所に集中する理由
エージェントは、あなたが説明した道筋に合わせて最適化します。実現したいことを説明するのですから、ハッピーパスは丁寧に作り込まれ、その周辺はもっともらしく作られます。ここで効いてくるのが「もっともらしい」という点です。コードはコンパイルが通り、画面も描画されますが、その前提が現実と突き合わせて確認されたことは一度もありません。
だからこそ、失敗は予測できます。失敗は必ず、説明の境界線上で起きます。
4つの集中領域 ― 実害が出る順に
永続化。 画面は更新されるのに、データベースは更新されません。リロードすれば一目で分かります。何かを信じる前に、書き込みのたびにリロードしてください。
空の状態とエラー状態。 結果が0件のとき、リクエストが失敗したとき、入力が弾かれたとき。いずれもプロンプトには含まれていませんでした。ひとつずつ意図的に試してください。ハッピーパスよりも高い頻度で壊れます。
2つ目のアカウント。 所有権、権限、可視性は、アプリを作った単一のセッションを前提に決められています。ほかの誰かがそうする前に、別のユーザーとしてサインインしてください。
4つ目はさらに分かりにくく、 昨日までの機能です。新しい指示のひとつひとつが、動いていたはずの何かを静かに壊してしまうことがあります。しかし会話はすでに先へ進んでいるため、以前の挙動を誰も確認していません。
プロンプトを重ねてもスケールするチェック
手作業のチェックは半日ほどは機能し、そこから劣化していきます。プロンプトを出すたびに確認すべき範囲は広がるのに、根気のほうは増えないからです。必要なのは、平易な言葉で書き出され、自動的に実行されるチェックです。そうすれば、あなたがそのつど決断しなくても、昨日までの機能が検証し直されます。
セットアップを済ませればそれをエージェントに任せられるため、チェックは別の面倒な作業ではなく、開発と並行して行われるようになります。
ここで挙げたことに、ターミナルは一切必要ありません。TestSprite のダッシュボードでプロジェクトを作成し、チェック内容を平易な言葉で記述して、対象のアプリを指定するだけです。チームの開発者は、好みに応じてコマンドラインから同じことを実行できます。その方法は CLI リポジトリにあります。
大半を見つけ出す10分間
サインアップし、サインアウトし、もう一度サインインします。 最も多い完全な失敗であり、実際のユーザーが最初に行う操作でもあります。
作成して、リロードして、残っていることを確認します。 永続化の集中領域をそのまま検出できます。
無効な値を送信します。 ここで確認しているのは、黙って成功したことにされるのではなく、明確に失敗するかどうかです。
新規アカウントでメインのフローを一通り試します。 権限の集中領域を検出できます。
いずれもコードを読む必要はなく、4つ合わせれば、そうしなければ見知らぬ誰かに見つけられていたはずの問題の大半を見つけられます。
同じバグが何度も戻ってくる理由
このやり方での開発について最も多く聞かれる不満は、壊れること自体ではなく、ひとつ直すと別のところが壊れる、という繰り返しです。これはモデルの能力不足ではありません。記録が欠けていることが原因です。
指示はそのつど、現在のコードの状態だけを手がかりに解釈されます。すでに維持しなければならない挙動の一覧が存在しないため、エージェントには、依頼された変更が先週の火曜日に決めたことと衝突していると知る術がありません。エージェントから見れば衝突はありません。先週の火曜日は、その場にいないからです。
書き出されたチェックが、その記録になります。チェックはエージェントを賢くするのではなく、あなたの意図を長持ちさせます。実際の効果として、3回目や4回目の変更が最初の2回を台無しにしなくなります。このやり方での開発が、消耗するものではなく信頼できるものに感じられ始めるのは、ちょうどこの地点です。
本当の場に出す前に
ほかの人がアプリを使うようになったら、チェックは思い出したときではなく、変更のたびに実行されるべきです。
GitHub App は、TestSprite のダッシュボードで設定する webhook です。既存のパイプラインがすでに発行しているデプロイイベントを検知するため、リポジトリ側には何の変更も生じません。
GitHub Actions は、ターミナルから設定し、このステップを自分のワークフローの中に組み込みます。
チェックを自走させる
本ページで紹介した10分間のチェックを、手作業でやるものではなくしてくれるのが TestSprite です。各フローを平易な言葉で一度記述しておけば、変更のたびにアプリに対して実行されます。
これは、このやり方での開発で最も苛立たしいとされる点を直接解決します。書き出されたチェックは、維持し続けなければならない挙動の記録です。そのため新しい指示は、単独で解釈されるのではなく、その記録に照らして検証されます。ひとつ直すと別のところが壊れるというループが、当たり前ではなくなります。
ここでもターミナルやテストファイルは必要ありません。ダッシュボードでプロジェクトを作成し、対象のアプリを指定して、上記の4つのチェックを記述してください。チームの開発者は、好みに応じてコマンドラインから同じことを実行できます。
バイブコーディングは、単にリスクが高いのでしょうか。
リスクの所在が変わります。タイプミスのリスクは減り、検証されていない前提のリスクは増えます。取るべき対応は、すべての行を読む作業に戻ることではなく、振る舞いを体系的に確認することです。
なぜ、ひとつ直すと別のところが壊れるのでしょうか。
指示はそのつど、維持しなければならない挙動の記録にではなく、現在のコードという文脈に照らして解釈されるからです。書き出されたチェックが、その記録になります。
テストを書く必要はありますか。
コードとして書く必要はありません。フローを平易な言葉で記述して残し、変更のたびに自動で実行されるようにしてください。
そのチェックが本物かどうか、どうすれば分かりますか。
意図的に何かを壊し、チェックが失敗することを確認してください。一度も失敗しないチェックは何も守っておらず、この確認は1分で済みます。
いつからチェックを始めるべきですか。
誰かに見せる前です。今チェックを書くコストは数分ですが、ほかの誰かにバグを見つけられた後のコストははるかに高くつきます。