Evaluating & iterating prompts
Prompting feels like editing text, so people tune by gut: change wording, eyeball one example, ship. That's how you fix one case and silently break five. Prompts are product logic and deserve the same discipline as code.
The core practice
- Build a small eval set — 20–100 representative inputs with expected outputs or a grading rubric, including the edge cases that bite you (eval).
- Change one thing, then run the whole set — not a single example.
- Compare against the previous version — a prompt edit is a deploy; check for regressions, not just the case you were fixing.
- Version prompts like code (they belong in source control / a prompt registry).
How to grade
- Exact/programmatic — for structured or classification tasks (parse + compare).
- LLM-as-judge — for open-ended output, scored against a rubric (mind judge biases).
- Human review — for the highest-stakes or subjective cases; spot-check the judge.
Why "it worked when I tried it" is a trap
A single success says nothing about the distribution of inputs. Models are sensitive to phrasing, ordering, and sampling, so the same prompt varies run to run. Only an eval set across many inputs tells you whether a change is a real improvement or noise.
Treat each prompt change as a code change: it needs a test set, a diff against the baseline, and a regression check before it ships.
This is the prompt-engineering end of a spectrum that continues into full system evaluation and LLMOps.
Connects to: building eval sets · prompt versioning · grading structured output