What is Prompt engineering?

What a prompt is actually doing

A language model has no memory of your project, no knowledge that you were in a meeting about this yesterday, and no way to ask you what you meant. Everything it knows about the task arrives in the context window. The prompt is therefore not a description of a request; it is the whole specification, and anything you leave out is a decision you have delegated to the model's prior.

That framing explains most prompting practice. The task goes in. The output format goes in, because the model will otherwise choose a format and you will be parsing prose. The constraints go in, including the negative ones, since a model will happily produce the thing you told it not to produce if the prohibition is not explicit. The examples go in, because examples are a much denser encoding of a specification than instructions: four good examples say more about tone, length and edge-case behaviour than a paragraph of adjectives.

It also explains the boundary between prompting and its neighbours. A requirement can be satisfied in three places, and the choice is architectural rather than stylistic. In the prompt, which is where behaviour, format and reasoning instructions belong, and which takes effect immediately and is reversible. In the weights, through fine-tuning, which is where a consistent style or a domain format belongs when you have thousands of examples and the patience to validate it. In the retrieved context, which is where facts belong, because a model cannot recall what it was never trained on and a prompt cannot make a private document appear.

The most common design error is putting a fact in the prompt and a rule in the weights, or a rule in the retrieved documents, and then wondering why behaviour is inconsistent.

The techniques that have durable names

A handful of techniques have held up across model generations, and each does one specific job.

Few-shot examples. Put two to five solved examples in the prompt instead of describing the task. This is the single highest-value technique when the output has a shape you care about, because it demonstrates the shape rather than stipulating it. It costs tokens on every call, which is the trade.

Step-by-step reasoning. Asking the model to work through the problem before giving the answer gives it more computation on that question and changes the answer, particularly on arithmetic, logic and multi-step planning. The cost is output tokens and, for a program, latency you have to absorb.

Self-consistency. Sample several reasoning attempts and take the answer that appears most often. It buys accuracy on problems where the answer is checkable by frequency, at a multiple of the cost.

Explicit branching. Extend the previous idea by exploring several candidate approaches on the page and choosing among them, rather than committing to the first line of thought. It is more expensive again and it pays off on search-shaped problems.

Output specification. Naming the exact format, giving a schema, wrapping the answer in delimiters, and saying what to do when the input does not fit the pattern. This is the least glamorous technique and the one that most often turns a prototype into something that can be parsed.

Instruction and data separation. Delimiting untrusted content and telling the model to treat what is inside the delimiters as material rather than as commands is the structural defence against the case where your own retrieved document contains an instruction.

NirDiamant/Prompt_Engineering is the place to see these in one sequence, and our analysis of it describes 22 hands-on notebook tutorials running from basic prompt templates through chain-of-thought, self-consistency and tree-of-thought. It is a study resource for engineers learning the subject rather than a library to import, and that framing is right: none of these techniques is a dependency, it is knowledge.

When prompting is the right instrument

Prompting is cheap to change and cheap to get wrong, which makes it the right first move and the wrong last resort.

It fits behavioural requirements. The output should be a certain shape, at a certain length, with a certain refusal behaviour, in a certain voice. None of that is in the weights and all of it is reachable from the prompt.

It fits when the answer is needed today. A prompt edit is a deployment; a fine-tune is a project.

It fits prototypes. You do not yet know what the task looks like, and the fastest way to find out is to try it in a loop with a human reading the output.

It fits when you have no data. Few-shot examples can be written by hand in an afternoon, which is the only data requirement in the whole range of options.

It does not fit factual knowledge. A prompt cannot contain a specification you do not have and cannot make a private document retrievable.

It does not fit guarantees. A prompt expresses a tendency. If you need a property that always holds, that is a decoder constraint, a schema check with a retry, or training.

It does not fit once the prompt is a program. A prompt that contains loops, conditionals and state is a program written in a language that no one type-checks, and the moment it reaches that size the logic belongs in your code with the model called at the leaves. This is the most useful dividing line on the page: if you can express the rule in code, do not express it in English and hope.

And it does not fit without an evaluation. Tuning a prompt by reading outputs feels like progress and can be a random walk, because you are changing one thing and judging it on a case you happened to look at.

The pitfalls

Six, and the last two are the ones teams discover after they have shipped.

Incantations. A prompt accumulates instructions that nobody has removed, because nobody tested removing them. Politeness, threats, offers of reward, elaborate personae: some of this does nothing measurable, and the discipline is to keep only what an evaluation shows is load-bearing.

The prompt is an unversioned dependency. Behaviour is a function of the prompt and the model, so an upgrade on the provider's side changes your results with no change on yours. Treat the prompt as code, keep it in review, and re-run your evaluation on every model version you adopt.

Nothing transfers between models. A prompt tuned for one model is a starting point for another, not a finished one, because the two do not share an instruction-following behaviour or a formatting instinct.

Long contexts hide instructions. When the prompt is thousands of tokens, the parts in the middle are the ones most likely to be under-weighted, so the constraint you care about most is often the one that needs to be nearest the end or repeated.

Prompt injection. Anything you retrieve or accept from a user is in the same channel as your instructions. The structural defences are separation, delimiters, and not giving the model tools whose authority exceeds what the content deserves.

Nobody signs off on it. A prompt is a behavioural contract for a feature, and it is usually edited in a hurry by whoever is nearest the bug, with no test and no record of why the wording is the way it is.

How the projects divide

Three groups, and reading a prompt is a different activity from engineering one.

Teaching material. dair-ai/Prompt-Engineering-Guide is the broad one, and our analysis describes it as a MIT-licensed MDX repository collecting techniques, papers, notebooks and worked examples for prompting large language models, aimed at researchers and developers who want a structured reference across methods rather than one provider's documentation. anthropics/prompt-eng-interactive-tutorial is the guided course: our analysis describes a free nine-chapter notebook course that runs against one specific model, moving from basic prompt structure through multi-step construction for real industry use cases, and offered in both a Jupyter and a spreadsheet format.

Tooling. promptslab/Promptify is the one here that runs in a pipeline. Our analysis describes it as a Python library wrapping LiteLLM to run named entity recognition, classification and question answering against more than a hundred providers, returning type-safe objects instead of raw strings, with a README that compares it to scikit-learn for this kind of work. Prompt versioning is the other half of that idea and is where teams get the most value early, because it turns a prompt edit into a diff.

Prompt corpora. The rest of this list is material rather than software, and it is worth being clear about what it is for. x1xhlol/system-prompts-and-models-of-ai-tools is, per our analysis, a GPL-3.0 collection of leaked and published system prompts from a couple of dozen AI coding tools, and it describes it as a reference corpus rather than something you install. asgeirtj/system_prompts_leaks collects captured prompts from several model providers and coding agents as plain Markdown. elder-plinius/CL4R1T4S is an archive of extracted system prompts, and our analysis is explicit that its value depends on how far you trust each contributor's extraction. Piebald-AI/claude-code-system-prompt is the most precise of them, mirroring the system prompt, tool descriptions and sub-agent prompts that ship inside one specific product, with a changelog across hundreds of versions, which makes it the one to read if you want to see what changes between releases. LouisShark/chatgpt_system_prompt and 0xeb/TheBigPromptLibrary are similar archives.

What they are good for is calibration: reading the instructions a system actually sends tells you how much instruction-following work vendors consider necessary, which is a useful prior when you are writing your own.

In practice

Prompt engineering is specification writing for a system that has no other way to learn what you want, so the techniques that matter are the ones that demonstrate rather than describe: worked examples, an explicit output format, and reasoning steps where the problem needs them. Put facts in retrieval, rules in your code, and behaviour in the prompt. Version the prompt and evaluate it, because that is the difference between engineering it and guessing at it. Read dair-ai/Prompt-Engineering-Guide for the map, NirDiamant/Prompt_Engineering for the worked examples, and one of the system prompt collections when you want to calibrate how much instruction text is normal.