ループ: 意図 → 生成 → レビュー → 洗練
本書のすべては一つのサイクルに帰結する。これを身体に染み込ませよう。
- 意図。 求めるものと、重要な制約を述べる——入力、出力、エッジケース、スタック、スタイル。曖昧な意図は曖昧なコードを生む。
- 生成。 モデルに実装を書かせる。構文を逐一手取り足取りせず、振る舞いを記述する。
- レビュー。 返ってきたものを読む。それは実際に目的を果たしているか。空のリスト、null、失敗したネットワーク呼び出しを処理しているか。それは動作する最もシンプルなバージョンか。
- 洗練。 何が間違っているかを指摘し、具体的な修正を与え、再生成する。基準を満たすまで繰り返す。
ほとんどの初心者はステップ3を飛ばす。生成し、動いた、次へ進む。そして記述しなかったケースでプロダクションが壊れる。レビューのステップこそ、エンジニアリングが起きる場所だ。
このループでの良い最初のプロンプトはこんな感じだ。
Write a TypeScript function `parseDuration(input: string): number`
that converts strings like "1h30m", "45s", "2d" into total seconds.
Requirements:
- Support units: d (days), h (hours), m (minutes), s (seconds).
- Multiple units can combine: "1h30m" = 5400.
- Reject invalid input (empty, unknown units, negative) by throwing
an Error with a clear message.
- No external libraries. Include 5 unit tests covering the edge cases.
Show the function and tests only.
その構造に注目してほしい。正確なシグネチャ、明示的なルール、列挙されたエッジケース、述べられた制約、そしてテストの要求。あなたはモデルが正しく当ててくれることを願っているのではない——悪い推測を生む曖昧さを取り除いているのだ。
洗練のステップも、最初のプロンプトと同じくらい一つのスキルだ。曖昧なフィードバックは曖昧な修正を生む。この二つの修正指示を比べてみよう。
悪い例: "this is wrong, fix it"
良い例: "parseDuration('1h30m') returns 90 instead of 5400 — you're
summing the numbers but ignoring the unit multipliers. Multiply
each value by its unit's seconds (d=86400, h=3600, m=60, s=1)
before summing. Also add a test for the combined case '2d3h'."
良いほうは症状、原因、そして修正方法を名指しする。あなたは同僚のプルリクエストをレビューするようにレビューしているのだ——そして正確に指し示すほど、費やすラウンドは少なくなる。各ループは収束すべきだ。堂々巡りをしていると感じたら、それは意図が仕様不足だったというサインだ。再生成をやめて、仕様を書き直せ。