失敗する場面

限界について正直であろう。なぜなら、ここが監督されていないバイブコーディングが人々を焼く場所だからだ。

• 深く、新規性のあるロジック。 微妙なアルゴリズム、並行処理、95%正しいことが壊れていることを意味するあらゆるもの。モデルは間違っていても自信満々だ。
• 広範囲に及ぶファイル横断の変更。 大きなコードベースを通して筋を見失い、見えないところを静かに壊す。
• セキュリティとお金。 認証、決済、権限、もっともらしく見えるバグが現実の結果をもたらすあらゆるもの。仕事がかかっているかのようにレビューせよ。実際そうかもしれないのだから。
• 仕様が不十分な問題。 あなたが正しいものがどういうものか分からなければ、AIはあなたの心を読めない。ゴミの仕様を入れれば、ゴミのコードが出てくる。

失敗のパターンはほとんど常に同じだ。見た目は正しく、ハッピーパスでは動き、もし読んでいれば捕まえられたはずのやり方で間違っているコード。その対策はレビューのステップだ。それを飛ばすことはできない。

二つの問いで、どんなタスクもこの地図の上に置ける——パターンはありふれているか、そして結果は点検しやすいか:

                  検証しやすい        検証しにくい
                ┌──────────────────┬──────────────────┐
   一般的な     │   純粋な利点     │   ゆっくり,      │
   パターン     │   (足場,         │   テスト要求     │
                │   定型           │                  │
                ├──────────────────┼──────────────────┤
   まれ /       │   読めば可能     │   危険地帯       │
   新規         │                  │   (新ロジック,   │
                │                  │   認証, 金銭     │
                └──────────────────┴──────────────────┘

先のルールの逆に注目してほしい。これらはまれで、微妙で、検証が高くつくケースだ。パターンがありふれていないのでモデルは推測しているか、バグがハッピーパスでは見えないので素早い点検では捕まらない。だからといってここでAIを避けよということではない——速度を落とし、ステップを小さくし、テストを要求し、すべての行を敵対的なものとして読め、ということだ。