ログインを修正すると、支払いが壊れ、支払いを修復するとログインのバグが再発します。長くなったプロンプトでもこのサイクルを解消できない場合があります。次の変更を依頼する前に、失敗が繰り返されているか、関連する挙動がテストでカバーされているかを確認してください。
Vibe Codingが効かなくなるポイントは固定ではありません。製品やそのリスク、コードの状態によって答えが異なります。別の作業方法を求めるサインは、はるかに簡単に見分けられます。
機能数ではなく、失敗時の影響で判断する
マックアップや一時的なプロトタイプ、小規模チームが使う内部ツールは、試行錯誤を吸収できます。AIツールも、要件が明確で挙動がテスト可能なCRUDアプリケーションでは、多くの作業を担うことができます。
アプリが単独で構築される保証があるわけではありません。意味するものは、間違いが逆転可能であるということです。CRUDアプリケーションが個人データを保存したり、支払いを行う顧客を扱い始めると、状況は変わります。
リスクは見える製品を超えて成長する可能性がある
製品に以下の要素が含まれると、単なる作業画面だけでは不十分です：
- 支払い: サーバーは金額を計算し、Webhook署名を検証し、重複したイベント処理を防ぐ必要があります。
- 個人データ: 認証は始まりにすぎません。ユーザーごとの権限、データの保持・削除、インシデント対応も重要です。
- 同時ユーザー: 二人が同じデータを変更すると、競合や不一致の状態が生じる可能性があります。
- 運用依存関係: デプロイ、監視、バックアップ、復旧は、機能実装とは異なる分野です。
マネージドサービスは書く必要のあるコードを減らしますが、データやアクセス制御、アプリケーション設定のすべての責任を引き受けるわけではありません。Supabaseは、この責任を共有するモデルとして明確に説明しています。
最終段階は固定のパーセンテージではありません
初期の作業は非常に目立つ：画面が表示され、成功パスが動き始めます。後半の作業では、機能間の結合、エラーパス、レガシーデータ、テスト、セキュリティルール、配布制約が明らかになります。見える機能数はほとんど変化しない一方で、検証が必要な境界は急速に増加します。
AIモデルのコンテキストに置かれる会話やコードの量も重要です。Anthropicは、コンテキストにトークンが増えるにつれてモデルが情報の正確な取得能力を低下させる現象を「コンテキストの腐敗」と呼んでいます。一貫したファイル数の閾値はありません。関連のないファイルや長く続く会話がコンテキストを埋め尽くすとき、または意図した変更が狭く定義されていて、以前の決定が見逃しやすいとき、実用的なリスクが高まります。
完成に近い段階で突然の壁を感じる場合、それは検証が必要な接続数が実装すべき機能数よりも速く増加していることが原因です。
3つのサインで停止し、支援を求めるべきです
修正が再び同じ問題を引き起こす
Aを修正するとBが壊れ、Bを修正するとAが再び壊れる。次の修正を依頼する前に、再現手順とテストを凍結してください。重要なサインは、バグが何日か経ってから存在していることではなく、各修正が同じリグレッションチェックに失敗していることです。
結果が正しいか判断できない
認証、権限、支払い、データの回復はUIだけでは判断できません。テストがなければ、またはログはあるが誰も安全を評価できない場合、検証のギャップは実装のギャップよりも大きいです。狭く限定されたコードレビューまたはセキュリティレビューは、この状況を改善するのに役立ちます。
失敗が他人に影響を与える
製品が実際の顧客のお金やデータを扱い始めたり、ダウンタイムが収益に影響を与えるようになったりした場合、「今すぐリリース、後で修正」は異なるコストを意味します。プレリリースのレビュー、バックアップ、ロールバック、監視は今や範囲に含まれるべきです。
さらにクレジットを費やす前に、Try to Fixのループを中断してください
Try to FixとAttempt Fixは、特定のエラーを切り分けて修正するときに役立ちます。しかし、各試行で関係のないコードを変更し、新しい失敗を生み出すようになると、コストが高くなります。
この停止ルールを使用してください：
- 同じ症状に対する2回の失敗した自動修正の後、エージェントを停止してください。
- 正確なエラー、再現手順、変更されたファイル一覧を保存してください。
- 主要な操作を正常に完了できた最後のチェックポイントを復元してください。
- コードを編集せずに、チャットまたはプランモードで根本原因を尋ねてください。
- 1つの限定された変更を承認し、それ以外の何事も行う前に同じチェックを再実行してください。
ロールバックはバグが解決したことを証明するものではありません。それは正常動作が確認済みの基準状態を復元するだけです。次の試行が成功するのは、元の再現が失敗しなくなり、かつ以前に動作していた挙動がまだ通過しているときです。
ツールが狭い変更を説明できない場合は、コードをエクスポートまたは同期し、限定されたレビューを依頼してください。同じエージェントに機能全体を作り直させるためにさらにクレジットを費やすのは避けてください。
アプリ全体ではなく、範囲を絞ったレビューを外注できます
機能作業を一時停止し、現在の動作するバージョンを保持してください。再現手順、期待される結果、実際の結果、関連するログを1つのドキュメントにまとめます。これにより、AIツールと開発者に同じ出発点を提供できます。
その後、小さな依頼をしましょう：
- 認証とユーザーごとの権限のレビューのみ
- 支払いリクエストとWebhook処理のレビューのみ
- デプロイ設定、APIキー、環境変数のレビューのみ
- 再度リグレッションする機能のテストを書く
「私のアプリを完成させる」は価格を決めにくく、検証も難しいです。対象範囲と受け入れ条件を持つ依頼は、提案と結果を比較しやすくします。修正後の同じテストを再実行することを依頼に含めましょう。
次のプロンプトの前に記録すべき4つのこと
まだプロジェクトを引き継ぐ予定がなくても、次のように記録してください：
- バグを再現する正確なクリックパスとアカウント状態
- これまでに動作した最後のコミット
- AIが変更したファイルとその理由
- 次の変更後に通過しなければならないテスト
この記録はチームが問題を繰り返し再発見することを防ぎ、修正によって別の機能が気づかないうちに再び壊れていないかを示します。Vibe Codingの限界は、ツールを放棄するように示す線ではありません。検証と運用がもう一つのパッチを生成するよりも重要になるポイントです。