AI-Driven Developmentintermediate8 min

Prompting & Context Engineering

Steering a model is less about a clever one-off prompt and more about engineering everything the model sees before it answers.

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.

From prompt engineering to context engineering

"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.

How it works: the levers that shape an answer

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 combine to produce the model's output: improve any of them and the answer improves with it. Of the four, examples are the most underrated. Models are very good at continuing a pattern they can see, so two short samples of the output you want often settle a question of format or style that a paragraph of description leaves open.

Note

In our stack — with Claude Code driving Anthropic's Claude models, context engineering is mostly file work: a project instructions file plays the role of the system prompt, the spec and relevant source files supply the retrieved context, and MCP tools extend what the model can pull in. You're not hunting for magic words — you're deciding which files belong in the window for the task at hand.

Check yourself

You've written a paragraph describing the exact output format you want, but the model keeps getting it slightly wrong. What's usually the most effective next step?

More isn't better — relevance is

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.

Curating comes down to four moves. Retrieve: pull in the specific files, docs and data the task touches, usually by searching, rather than everything nearby. Leave out: drop what doesn't help, and above all what actively misleads, like a deprecated version of the file you're changing. Summarize: compress material you only need the gist of, such as a long chat history, into a short recap. Order: put bulky reference material first and the key instructions and the task last, close to the question; models tend to use the start and end of a long context more reliably than the middle.

Below, the same model gets the same task twice. One window gets everything; the other is built one move at a time. Predict which one comes back with the right total before you see the answers, then try a much bigger window.

Watch out

A bigger window isn't a better context. A larger limit lets you send more, but the model still has to find the right facts among everything else, and everything you send is processed again on every call, so cost and latency grow with it. Use the extra room for material the task genuinely needs, not as permission to stop choosing.

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.

Check yourself

An assistant keeps reintroducing a helper your team deprecated last month. Both the old and the new versions are in the files you send it. What's the best context fix?

Key takeaways

  • A model's answer is a function of everything in its context — so the real skill is curating that context, not crafting one perfect sentence.
  • The field has shifted from 'prompt engineering' (wording a single prompt well) to 'context engineering' (assembling the whole set of inputs the model sees).
  • The main levers are the system prompt (role and rules), clear instructions, relevant examples, and the right files and data pulled into the window.
  • Examples are unusually powerful: showing the model two or three worked samples often beats paragraphs describing what you want.
  • More context isn't automatically better — irrelevant material crowds the window and distracts the model, so relevance beats volume.
  • Curating comes down to four moves: retrieve what the task touches, leave out what misleads, summarize what you only need the gist of, and put the key instructions next to the task.

Keep going