Prompt iteration
A practical way to debug a prompt by changing one thing at a time.
The concept
Prompt iteration is controlled debugging. The model gave a poor answer, but “make the prompt better” is too vague to act on.
Good iteration isolates the failure. Was the task unclear, the context missing, the output shape underspecified, the model choice wrong, or the evaluation expectation impossible? For a reusable repair prompt, see debugging and iterating prompts.
The current approach
Keep a small test set of real inputs and expected traits. Change one variable, then compare the output against the same cases.
Use this order:
- Clarify the task.
- Add or remove context.
- Tighten the output shape.
- Add examples only if a boundary remains unclear.
- Change model or tool settings if the task needs capabilities the current surface does not have.
This saves time because you learn which change caused the improvement.
A practical example
Failure: a support-reply prompt sounds apologetic but invents refund policy.
First change:
Use only the policy excerpt below for refund eligibility. If eligibility is unclear,
write "Needs agent review" instead of making a promise.
Do not change voice, model, examples, and output format at the same time. If the next output improves, you know policy grounding was the main issue.
What to avoid
- Rewriting the whole prompt after one bad output.
- Adding more constraints before naming the specific failure.
- Judging the prompt from one easy example.
- Treating randomness as a fix. If a prompt only works on a lucky run, it is not ready to reuse.