Improving prompts systematically

Prompting is an empirical loop, not a one-shot art

The people who are good at this don't write one clever prompt — they measure and iterate. The loop: write a prompt → run it against a set of representative inputs → score the outputs → find the failure pattern → change one thing → re-run → keep what's better.

You need an eval set (again)

You can't improve a prompt you can't measure. Curate 20–50 representative inputs with success criteria (or reference outputs), including the edge cases and past failures. Score with the right metric (LLM-as-judge for open-ended, exact match for structured) — this is the Evaluation course applied to prompts. Without it, "the new prompt feels better" is unfalsifiable and you'll ship regressions.

Change one variable at a time

Prompts are sensitive — an added example, a reordered instruction, a temperature change all shift behavior. Isolate changes so you know what caused an improvement. Track prompt versions (they live in code) so you can diff and roll back.

Common anti-patterns to fix

The kitchen-sink prompt — 15 instructions, half contradictory. Simplify and chain.
Instruction buried in the middle of long context. Move key rules to the start/end.
Negative-only instructions. Convert to positives.
Relying on the prompt for safety. Add code guardrails.
Over-fitting to one input — a prompt tuned to ace a single example often regresses on others. Always test on a set.

Model changes are prompt changes

When you upgrade or switch models, re-run your eval — prompts don't transfer perfectly across models. And keep temperature intentional: low (0–0.3) for deterministic/structured tasks, higher for creative ones.

The mindset

Treat prompts like code: versioned, tested against a suite, changed deliberately, and gated on an eval. That discipline — not cleverness — is what makes prompt engineering reliable.

Worked example

Scenario. Someone "improved" the classification prompt and accuracy quietly dropped in production.

Diagnosis + fix. There was no eval set, so the regression was invisible. Build one: 40 labeled tickets including past misclassifications. Re-run both prompt versions — the "improved" one added a helpful-sounding instruction that hurt two categories. Roll back via the versioned prompt, make the change in isolation, re-run until it beats the baseline on the whole set, and add a CI check so no prompt change merges below the accuracy threshold. When you later switch models, re-run the same suite.

Takeaway. Improve prompts the way you improve code: an eval set gates changes, you change one thing at a time, version everything, and re-evaluate on every model change.

You need an eval set (again)

Common anti-patterns to fix

The kitchen-sink prompt — 15 instructions, half contradictory. Simplify and chain.

Instruction buried in the middle of long context. Move key rules to the start/end.

Negative-only instructions. Convert to positives.

Relying on the prompt for safety. Add code guardrails.

Over-fitting to one input — a prompt tuned to ace a single example often regresses on others. Always test on a set.

Worked example

Scenario. Someone "improved" the classification prompt and accuracy quietly dropped in production.

Takeaway. Improve prompts the way you improve code: an eval set gates changes, you change one thing at a time, version everything, and re-evaluate on every model change.

Prompting is an empirical loop, not a one-shot art

You need an eval set (again)

Change one variable at a time

Common anti-patterns to fix

Model changes are prompt changes

The mindset

Worked example

Sources

Improving prompts systematically

Prompting is an empirical loop, not a one-shot art

You need an eval set (again)

Change one variable at a time

Common anti-patterns to fix

Model changes are prompt changes

The mindset

Worked example

Sources