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

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

I want to add rate limiting to my API. Before writing any code,
give me a short plan: where the limiter should live, what
storage it needs, what happens when a limit is hit, and any
tradeoffs. Don't write code yet — I'll approve the approach first.

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

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