Prompt and context engineering
Prompt engineering is writing the instructions a model gets so that it produces accurate, relevant and usable output. Context engineering is the bigger job around it: deciding everything the model sees on each call, the system prompt, examples, retrieved documents, conversation history, tool definitions and tool results, and keeping that set small, relevant and well organised. In production, both are engineering work: prompts live in version control, change through tests, and are judged by results on an evaluation set, not by one good answer in a chat window.
From programming languages to prompts
To give instructions to a computer, we used to need its language. If you wanted to print something, you learned Python and wrote a print statement, and that statement was, in a sense, a prompt for the machine.
With LLMs, you can give instructions in English. That made it look easy, and in a chat window it is. But the same rule still applies as with code: there is a way to instruct a machine that gets good results, and a way that doesn't. "Tell me about AI" gets a vague, general answer. "In three sentences, explain the main applications of AI for small businesses" gets a focused, useful one. That difference, designing the instruction so the output is accurate, relevant and usable, is why we call it prompt engineering.
Why context engineering became the bigger job
When you chat, the prompt is mostly what you type. When you build an application, what you type is a small part of what the model sees.
On every call, the model reads a system prompt, maybe a few examples, retrieved chunks from your documents, the conversation so far, the definitions of every tool it can use, and the results of the tools it already called. In an agent, that collection changes on every step and grows quickly. The quality of the answer depends on all of it, and most production failures come from this context, missing information, irrelevant information, stale history, or too much of everything, rather than from the wording of the instructions.
So the work moved from "how do I phrase this?" to "what should the model see right now, and what should it not see?". That is context engineering, and prompt engineering is one part of it.
What this section covers
| Page | The question it answers |
|---|---|
| Production prompting | How do I write prompts that work for thousands of inputs, not one? |
| Context engineering | What should the model see on each call? |
| System prompts | What goes in the system prompt, and which instruction wins? |
| Few-shot examples | When do examples help, and how do I choose them? |
| Long context vs retrieval | Put everything in the window, or retrieve what's needed? |
| Prompt versioning | How do I manage prompts like code? |
| Prompt caching | How do I cut cost and latency on repeated context? |
| Context compression | How do I shrink history and documents without losing what matters? |
| Prompt testing | How do I know a prompt change is safe to ship? |
How to read this section
If you are starting, read production prompting, system prompts and few-shot examples first, then prompt testing, because those four change your results the most. If you are building agents or RAG systems, context engineering, long context vs retrieval, caching and compression are where your cost and reliability problems will come from.
Before this section, make sure you understand context windows and tokens, because everything here is about using a limited window of tokens well.
From the floor
When I teach prompt engineering in the cohort, I start by saying it is not that technical, because everyone in the room already writes prompts every day. Then we take a vague prompt, improve it step by step by adding context, format and constraints, and compare the outputs from ChatGPT, Claude and Grok side by side, so builders see how much one sentence of context changes the result. The next session is hands-on, because the techniques only stick once you have tested them on your own inputs.