Prompting & Context Engineering

Early on, working with a language model felt like a riddle game: if only you found the magic phrasing, the model would give you what you wanted. People traded "prompt hacks" like cheat codes. That instinct isn't wrong, but it's small. A model doesn't respond to one sentence in isolation — it responds to everything it can see at the moment it answers.

That realization reframes the whole task. The goal isn't to write one brilliant prompt; it's to engineer the context — to deliberately assemble the role, the instructions, the examples, and the data the model reasons over. The wording still matters, but it's one input among several.

"Prompt engineering" describes the craft of phrasing a single request well: being specific, stating the format you want, avoiding ambiguity. That's still genuinely useful. But it treats the prompt as if it were the only thing the model sees, when in fact the prompt arrives surrounded by other material — standing instructions, prior conversation, attached files, tool definitions — all of it competing for space in the context window.

Context engineering zooms out to manage that whole bundle. Instead of asking "what's the perfect sentence?" it asks "what does the model need in front of it to get this right?" — and then puts exactly that there, and leaves the rest out. The shift in language reflects a shift in where the leverage actually is.

There are four practical levers, and a good result usually comes from pulling several at once. The system prompt sets the role and the rules — who the model is acting as and the constraints it should always honor. Clear instructions state the task for this turn: what to do, in what format, with which limits, leaving no room for the model to guess your intent. Examples show rather than tell — a couple of worked samples teach the pattern you want far more reliably than a paragraph describing it. And retrieved context brings the right files and data into the window so the model reasons over actual facts instead of its general impressions.

Think of these as the inputs that flow into the model and combine to produce its output — improve any of them and the answer improves with it. The diagram below shows that flow: system prompt, instructions, examples, and retrieved context converging on the model, which then produces a noticeably better result.

It's tempting to treat the context window as a place to dump everything that might help and let the model sort it out. In practice that backfires. The window is a fixed budget, and irrelevant material doesn't just waste space — it actively distracts, pulling the model's attention toward details that don't matter and burying the few that do. A focused half-page of exactly the right context routinely beats ten pages of vaguely related text.

So the discipline of context engineering is as much about subtraction as addition: include the system prompt, the precise instructions, a couple of pointed examples, and the specific files the task touches — and deliberately leave out the rest. The aim is the smallest set of inputs that makes the right answer obvious. Curate the context that well, and the "magic prompt" you were hunting for turns out to have been the context all along.