Prompt engineering, separated from the folklore

“Prompt engineering” covers everything from a sensible sentence in a chat box to a versioned system prompt running a production service, which is why arguments about whether it’s a real skill go nowhere. This page pulls the two apart, and explains why wording changes results at all. It sits alongside the prompt gallery as the theory to its examples.

Why wording matters in the first place

A model continues text according to patterns it learned, and your prompt is the text being continued. Everything in it steers what a likely continuation looks like: the vocabulary you use, the format you show, the role you describe, the examples you include. A prompt isn’t a command to a program; it’s the opening of a document the model finishes. Write the opening of a better document and you get a better ending.

That framing explains most of the tricks without any mystery. Examples work because continuing a pattern is the model’s native move. Naming an audience works because text written for a named audience reads differently, and the model has seen millions of instances of both.

The techniques that hold up

A handful of named techniques have survived contact with actual use. Few-shot prompting: show worked examples instead of describing what you want. Chain of thought: ask for reasoning before the answer on tasks with real steps, though current reasoning-focused models do much of this unprompted, so the technique is aging into a default. Role prompting: “act as a sceptical reviewer” works as compressed context about what to produce, not because the model becomes anyone. Decomposition: break big jobs into stages. Structured output: specify the format, and validate it anyway.

All of them appear as copyable cards in the prompt gallery, most under its advanced tier.

The folklore

Plenty of what circulates doesn’t survive testing. Magic phrases that supposedly switch on hidden ability. Tipping the model imaginary money. Marketplaces selling paragraph-long incantations, most of which are a brief with adjectives. Results on whether politeness improves answers are mixed enough that the honest summary is: it doesn’t matter much, be polite if you like.

The deeper problem with incantations is coupling. A prompt tuned to one model’s quirks quietly degrades when the provider ships an update, and providers ship monthly. Prompts built on plain context and examples travel across model versions far better than prompts built on tricks.

Where it becomes a real discipline

If you’re chatting, the basics plus the gallery cover you, and “prompt engineer” is just a grand name for writing clearly about what you want.

Building products on the APIs is different. There, prompts are code in every way that matters: versioned, tested against evaluation sets, reviewed when the model changes. The discipline has also widened into what practitioners now call context engineering, meaning the design of everything the model sees, not just the instructions: retrieved documents, tool results, conversation memory, all competing for a finite context window. The wording of the instruction is a shrinking share of that problem.

If you remember one mechanism, make it this: the model finishes the document you start. Context and examples change what document that is. Magic words don’t.