What a Prompt Engineering Course Should Teach but Skips

The course that teaches tricks but not truth

Search for a prompt engineering course and you will find a reliable pattern: a tour of techniques. Chain of thought, few-shot exemplars, role prompting, system messages, delimiters, output formatting. These are useful things to know, and I do not dismiss them. But almost none of these courses spend real time on the question that actually determines whether any of it was worth doing: how do you know your new prompt is better than your old one, and not just better on the five examples you happened to glance at?

This matters because prompting feels like writing, and writing feels like something you can judge by eye. You read two outputs, one looks more polished, you conclude the prompt that produced it is superior. That instinct is exactly how people get fooled. A single comparison on a handful of cases tells you almost nothing about how a prompt behaves across the full range of inputs it will actually see in production, because language model outputs are noisy, inputs vary enormously, and your five examples were never a representative sample to begin with.

A course that skips evaluation is teaching you to cook without ever teaching you to taste properly. You can learn every seasoning technique in the book, but if you cannot reliably tell when a dish has improved, the techniques are decoration. The uncomfortable truth is that most of what separates a competent prompt engineer from someone who just tries things is the discipline of measurement, not the cleverness of the prompt itself.

Variance is the thing nobody mentions

Here is a concrete scenario. Suppose you are testing two prompts for a classification task, extracting sentiment from customer reviews, and you run each prompt on 20 reviews. Prompt A gets 17 correct, 85 percent. Prompt B gets 15 correct, 75 percent. It looks like a clear win for Prompt A. But with only 20 samples, the uncertainty around each of those numbers is large. A rough binomial confidence interval on 17 out of 20 spans roughly 62 percent to 97 percent. The interval for 15 out of 20 spans roughly 51 percent to 91 percent. Those intervals overlap substantially. The ten point gap you saw could easily be noise rather than a genuine difference in prompt quality.

Now scale that same ten point gap up to 300 samples instead of 20. At 300 samples, 85 percent versus 75 percent produces confidence intervals that barely touch, and you can say with real confidence that Prompt A is doing something meaningfully different and better. The lesson is not that small samples are useless, it is that the sample size changes what conclusions you are entitled to draw from the same observed gap. A course that never shows this arithmetic leaves students unable to tell the difference between a real improvement and a lucky draw.

There is a second, subtler source of variance that courses rarely mention: the model itself. Even at low temperature, many models produce different outputs for the same prompt run twice, because of how sampling and batching work on the serving side. If you only run each prompt once per test case, you cannot separate prompt variance from model variance. The fix is simple and cheap: run each test case multiple times per prompt, average the results, and look at the spread, not just the mean. Skipping this step means your entire evaluation might be comparing noise to noise and calling it insight.

Leakage, held-out sets, and the trap of eyeballing your own test cases

The deepest problem, though, is leakage, and it shows up in prompt engineering in a form that is easy to miss because it does not look like the leakage you learn about in a standard machine learning course. There is no training split here, no risk of memorised labels. The leakage happens in your own head. You write a prompt, you test it on ten examples you wrote yourself, it fails on three, you tweak the prompt until it passes all ten, and you declare victory. What you have actually done is overfit a prompt to ten specific cases through manual iteration, using the exact same cases both to diagnose the problem and to judge the fix.

This is structurally identical to tuning a model on your test set. The honest version requires two separate sets of examples: a development set you are allowed to look at and iterate against, and a held-out set you touch only once, at the end, to report how the final prompt actually performs. If your held-out score is much worse than your development score, that gap is telling you something true and useful, namely that you were fitting to the quirks of your development examples rather than solving the underlying task. A course that never introduces this split teaches students to iterate blindly and report numbers that will not survive contact with new data.

There is also a more mundane but equally damaging form of leakage worth naming explicitly: building your test examples by lightly editing cases that appear in the model's training data or in widely available benchmark sets. If your evaluation examples resemble things the model has effectively seen before, you are not measuring how well your prompt generalises, you are measuring how well the model recognises a familiar pattern. Good evaluation sets are deliberately drawn from fresh, representative, somewhat awkward real-world inputs, including the edge cases that make the task genuinely hard, because those are the cases where prompt design actually earns its keep.

What to actually teach, and what to actually do

None of this requires exotic tooling. A rigorous prompt evaluation workflow needs four plain ingredients: a reasonably sized test set drawn from realistic inputs, a clear and consistent scoring rule decided before you look at outputs, multiple runs per prompt to account for sampling variance, and a held-out slice you only check once the prompt is finalised. Compare that against a simple, strong baseline prompt before adding any cleverness, because a surprising number of elaborate prompting tricks fail to beat a plain, well-specified instruction once you measure properly.

If you are learning prompt engineering on your own, build this habit early: before you tweak a prompt, write down what evidence would convince you it actually improved. Decide the sample size, decide the metric, decide the held-out set, and only then start iterating. It is less exciting than discovering a clever phrasing trick, but it is the difference between a skill you can trust under pressure and a collection of anecdotes that happened to work once.