Prompt Engineering: how prompting still impacts results

What it actually is

Shaping a single instruction so a model does what you want. The task, the format, the examples, the constraints.

Someone who does this well tends to do four things consistently.

They say one thing unambiguously. Most disappointing results come from a request that could reasonably be read two ways, and the model picked the other one.

They show rather than describe. One worked example that demonstrates the pattern is worth three paragraphs explaining it. It is worth choosing an awkward example rather than an easy one, because the awkward case is where the instruction gets tested.

They say what the output should look like. Length, structure, what to include and what to leave out. A request without a described output gets whatever shape the model settles on, and then someone spends ten minutes reshaping it.

And they try it on a handful of real cases before deciding it works. Judging a prompt from a single result tells you very little, because the variation between runs is often larger than the variation between two prompts.

What doing it badly looks like

Magic phrases. Flattery aimed at the model. Instructions that hedge against every possible failure until the actual request is buried on line fourteen. And the most common one: concluding from a single unimpressive result that the tool cannot do the job.

That last habit is worth naming, because it is not really a prompting failure. It is what happens when someone has no mental model of why a result was poor, so the only explanation left is that the technology is not ready.

Evaluating a prompt, not just writing one

There is a level beyond writing good instructions. Instead of judging a prompt by whether the last answer looked right, you run different versions against the same set of real cases and compare what comes back.

Fewer teams get to this point. The ones that do start treating prompting as work that can be measured and improved, rather than a knack that some people happen to have.

How the skill gets built

This is something to teach across the whole team, and it builds through practice rather than in a single session. In our own programmes, around forty minutes of deliberate practice a few times a week, over a couple of weeks, gets most people to a reasonable standard. Use real work rather than exercises, with someone showing why a result improved rather than simply handing over a better prompt.

It keeps developing after that, because models change and what works best shifts with them. That is also why it rarely makes sense as a hire. It is a core working skill, like writing clearly, that everyone benefits from getting good at.

Where prompting reaches its limit

Prompting sets the ceiling on how good a single request can be. It does not set the ceiling on your outcomes. When someone is writing clear instructions and still not getting what they need, the constraint has usually moved. The model does not have the information it needs, the work needs knowledge and tools wrapped around it, or the process it sits inside was never designed for this.

Those are the next three articles.

Part of the series that starts with The jargon is complicated. The capabilities underneath are simple. Next: Skill Engineering, getting results on real tasks.