Key points
- Prompt engineering is shaping the instruction you give an AI so the result comes closer to what you actually want.
- The core skill is putting every condition in your head into words. Whatever isn't written gets filled in on its own.
- Attaching a few examples of the shape you want often works faster than a long explanation.
- Hard problems often get more accurate when you make room for the AI to work through them step by step. Models that reason on their own already do this.
- It doesn't land in one try. Reading the result and revising a few times is normal.
The analogy
Drop off a pair of shoes at a repair shop and just say fix them up, and the shop decides everything on its own. Leave the heel height, the insole, and the color unspecified, and you get whatever the shop usually does.
If there's something specific in mind, it has to go on the ticket. Write down lower the heel by a little, replace the insole, leave the outer leather alone, and there's less back-and-forth when you pick the shoes up. Bring in a similar pair to show what you mean and that goes faster than explaining it in words.
It doesn't finish in one trip either. Getting the shoes back and asking for the heel a touch lower still is normal. A request refined over a few rounds can be written down and reused as-is next time. The instruction handed to an AI is that same order ticket.
In detail
Put what's in your head into words
The same request can turn out very differently depending on how it's phrased. Just ask for a piece of writing, and the length and tone both get guessed at. Whatever isn't written gets filled in with whatever's most common.
If there's something specific in mind, spelling out each condition helps. What's it about, what format should it come back in, who's going to read it, roughly how long — laying these out cuts down on wasted rounds. Write meeting notes as a five-line list, written so a first-time reader gets it, with no jargon, and that's the kind of specificity that pays off.
What to leave out can be written down too. But rather than piling on a list of don'ts, describing the shape that's actually wanted tends to work better. For picture generation, some services even have a separate field set aside just for what shouldn't appear.
Showing an example speeds things up
Attaching a few finished examples is often faster than explaining the format at length. Show the exact shape of the answer you want and it picks up on tone and line breaks that would be hard to describe in words.
Three or four examples are usually enough. But if the examples don't match each other in format, that causes more confusion than it solves. Keep the format in the same mold, but pick examples that differ in content, or it will copy some irrelevant shared quirk. Writing them at the same level of polish as the answer actually wanted matters too.
Make room for it to think
For problems that involve calculation or juggling several conditions, asking for just the answer tends to go wrong. Ask it to work through the reasoning step by step before giving the answer, and accuracy often climbs. Writing out the middle steps lets it refer back to its own earlier reasoning along the way.
If the middle steps look messy, it's fine to ask for the reasoning first and a clean summary at the end. Many services these days reason things through on their own before answering, and on those there's no need to ask, and dictating each step can even get in the way. On models that don't reason on their own, it still makes a big difference.
It doesn't land in one try
Getting the wanted result on the first try is rare. Pointing out exactly what's off and asking for a fix goes much faster. For a small fix, asking to carry on from the earlier exchange is fine, but once the fixes have piled up and the conversation has grown long, it's often better to rewrite the instruction with all the changed conditions and start a fresh conversation.
If the instruction has gotten long, look for something to cut. Instructions that pull in different directions mean neither one gets followed properly. Rather than adding more sentences, putting the core point up front and trimming the clutter tends to help more.
A good instruction gets reused
Once an instruction works well, save it and reuse it. Leave the parts that change blank and lock everything else in place, and the result comes back at the same quality every time. Services built for a team often bake an instruction like this in ahead of time and take only the user's question from there.
Worth keeping in mind: whatever gets pasted into an instruction can end up leaving the system, so it's safer not to include someone else's personal information or a company's confidential material. And no matter how carefully an instruction is worded, it doesn't verify facts on its own — whatever facts show up in the result still need a separate check.
More precisely
Prompt engineering doesn't touch the model itself — it changes only the input to get the output you want. A text-generating model picks what comes next based on everything placed in front of it as a condition, so what gets placed there, and in what order, shifts the odds behind the result. Image-generating models likewise take the whole instruction as their condition. Attaching examples to set a format, asking for the reasoning to be spelled out, and locking a role and a set of rules in place ahead of time all rest on that same principle.
The analogy breaks down in one place. Bring the same order to a repair shop twice and nearly the same result comes back, but feeding in the same instruction twice still produces a slightly different result each time, because some amount of chance gets mixed into what comes next. So shaping an instruction isn't locking a result down to one fixed outcome — it's raising the odds that the wanted kind of result comes back.
One more thing: there's no guarantee that an instruction that works well on one service carries over to another as-is. Different training means different behavior, so it's worth testing again after moving over.
Try it yourself
Common misconceptions
It's easy to think prompt engineering is about finding some magic phrase, but actually it's the ordinary work of spelling out every condition in full and revising based on the result.
It's easy to think writing more always gives a better answer, but actually piling on conflicting instructions can bury the actual point.
It's easy to think a well-written instruction erases mistakes, but actually plausible-sounding fabrication can still slip in, so facts still need a separate check.
One-line summary
Prompt engineering is spelling out every condition in full and revising the instruction based on the result, to raise the odds that the wanted answer comes back.
Spotted an error or have a better analogy? Suggest an edit · Last updated 2026-10-17