What Is Prompt Engineering? (And Why the Name Is Misleading)

Prompt engineering is the skill of describing a task clearly enough that a system with no access to your context, your colleagues, or your intentions can still produce something useful. That's the whole thing. There's no secret vocabulary, no list of phrases that unlock hidden capability, and no reason a non-technical professional can't get good at it in a few weeks of deliberate practice.

The name is the problem. "Engineering" suggests something technical — that there's a syntax to learn, the way you'd learn SQL or regular expressions. There isn't. Every prompt is written in ordinary language. What varies is how precisely that language describes the job.

What it actually is: briefing, not coding

The closest analogue isn't programming. It's briefing a competent contractor who has never worked with you before, can't ask clarifying questions, and will start immediately on whatever you've said.

If you tell that contractor "make the kitchen better", you'll get something. It might even be good. But it will reflect their assumptions about what "better" means, not yours, and you'll spend the next hour explaining what you actually wanted. If you tell them "replace the worktop with something that survives a lot of chopping, keep the existing cabinets, budget under two thousand", you get a much narrower set of outcomes — and most of them are acceptable.

That's the entire mechanic. Vague input produces output shaped by the model's defaults. Specific input produces output shaped by your requirements. The skill is knowing which specifics matter for the job in front of you, and there are only a handful of categories.

The four things a good prompt usually contains

The task, stated as a verb. Not "customer feedback" but "summarise these twelve support tickets into the three most common complaints". Nouns describe a topic; verbs describe a job. Most weak prompts are topics.

Enough context to remove the guesswork. Who's the audience, what's the situation, what's already been tried, what constraints apply. This is where most prompts fail, and it fails invisibly — the model doesn't tell you it was missing information. It fills the gap with something plausible and carries on. That's the failure mode worth internalising: you don't get an error, you get a confident answer to a question you didn't ask.

A shape for the output. Length, format, structure. "Three bullet points, each under twenty words" is a different instruction from "write about this". If you don't specify the shape, you get the model's house style, which tends toward the long and the balanced — useful for an essay, useless for a Slack message.

A standard for what good looks like. This one gets skipped most often and pays off most. "Aimed at someone who hasn't been in the meetings" tells the model more than three paragraphs of description would.

Notice what's not on that list: politeness, incantations, threats, role-play framings for their own sake, or any particular phrasing. Those either don't matter or matter far less than the four above.

Where personas fit

Telling a model to "act as a financial analyst" isn't magic — it's shorthand. It compresses a lot of context (vocabulary, what to prioritise, what to treat as obvious) into three words. That's genuinely useful when the role is a real one with recognisable conventions.

It's useless when the role is decorative. "Act as a world-class expert" adds nothing, because "world-class expert" describes no particular vocabulary or priority order. The test is simple: if you can't say what the persona would do differently, it isn't doing any work.

Ravi — the summary that was technically correct

Ravi runs operations for a 200-person logistics firm. He'd been using AI to summarise weekly incident reports for his leadership team, and the summaries were consistently fine — accurate, well-organised, and completely unusable.

The problem was that he'd been asking for "a summary of this week's incidents". He got exactly that: an even-handed account of everything that happened, in the order it happened. What his leadership team needed was the two incidents that would recur next week if nobody did anything, and who owned them.

He rewrote the prompt to say that. Same input, same model, output he could forward without editing. The change wasn't a technique. It was noticing that "summarise" hadn't described the actual job.

Elena — the context she didn't know she was holding

Elena is a communications lead at a mid-sized charity. She asked AI to draft a fundraising email and got back something competent and utterly generic — the kind of appeal that could have come from any organisation.

What she hadn't included: that the campaign was for a specific project donors had already funded once, that the tone of their previous successful appeal was dry and slightly self-deprecating, and that the audience was 400 people who mostly know the founder personally.

None of that felt like information at the time. It was just the situation — the stuff she carries around and doesn't think to say. That's the hard part of context: the things most worth including are the things too obvious to mention.

The one thing

Prompt engineering isn't a technical discipline with a syntax to memorise. It's the discipline of noticing what you know that the model doesn't, and saying it out loud.

The people who get good at this fastest aren't the ones who collect prompt templates. They're the ones who, when the output disappoints, ask "what did I leave out?" instead of "what phrase should I have used?"