コードの前にプランを求める

自明でないものなら何であれ、考えることとタイプすることを分離せよ。AIにまずアプローチの概要を述べさせる。これは間違った前提が200行の間違ったコードになる前に捕まえるし、プルリクエストを直すよりプランを直す方がはるかに安上がりだ。

自分の API にレート制限を追加したい。コードを書く前に、
短いプランをください: リミッターをどこに置くべきか、どんな
ストレージが必要か、制限に達したとき何が起きるか、そして
トレードオフ。まだコードは書かないで — 先にアプローチを承認します。

プランが正しそうなら「いいね、ステップ1を実装して」と言う。そうでなければ、コードを解きほぐすのに一時間ではなく、進路を修正するのに三十秒を費やしたことになる。まずプランを立てるという習慣こそ、エンジニア流のプロンプトを希望的観測のプロンプトから最も分かつものだ。

プラン段階はまた、AIが必要以上に重い解法を選ぶのを捕まえる場所でもある——インメモリのマップで済むのにRedisに手を伸ばしたり、一行のライブラリ呼び出しですでに解決することを手で書いたり。一つの問いを念頭にプランを読め。これは動きうる最も単純なものか? アプローチが過剰設計の匂いがするなら、一行も書かれる前に平易な言葉で押し返せ(「これはサーバー一台の趣味プロジェクトだ——分散ストアは省ける?」)。