What is context engineering — and why it beats the prompt

For a couple of years everyone learned to "write prompts." How to phrase a line more elegantly so the model gets it.

Then a sneaky thing came out. Often it's not the phrasing. It's about what the model sees as a whole the moment it writes an answer. That's context engineering — a level above the prompt.

A prompt is one line. Context is the whole picture

Picture asking a colleague a question.

The prompt is the question itself. How you phrased it.

The context is everything the colleague knows at that moment. Who you are, what you're working on, what happened yesterday, which files are on their desk. Same question, different background — and the answer is completely different.

So here it is. Context engineering is caring about that background, not about the phrase itself. You decide what to put on the model's "desk" before it answers.

What lands in the context

Every time the model answers, it sees more than your last line. Into its "field of view" — the context window — fits a whole set:

• the instruction — who it is and how to behave ("you're a coding assistant, keep it short");
• your question — that line;
• examples — what a good answer looks like;
• pulled-in data — chunks of your files, docs, database;
• memory — what came earlier in the conversation.

Context engineering is the craft of assembling that set so the needed things are in and the junk is out. Because the window isn't elastic: all of it takes up tokens, and you pay for those.

Why the model "goes dumb": often it's not the prompt

Classic. You write the perfect line, and the answer is off. So you rewrite the prompt for the tenth time.

But the problem is constantly something else:

• the model never saw the file it needed — it just wasn't put in the context;
• the window is a mess — you dumped everything in, and the model latched onto the wrong bit;
• memory overflowed — the start of the chat fell out, and it forgot what this was about.

None of those are fixed by a prettier wording. They're fixed by working with context: what to show, what to drop, what to pull in at the right moment.

What a beginner should do with this

You don't need to build complex systems. Just change one habit.

When an answer is bad, don't rush to rewrite the line. First ask yourself: does the model even see what it needs to answer?

• Need your code? Paste that exact chunk, not "somewhere in the project."
• Long chat and it's getting confused? Start over and give just the essence.
• Need fresh facts? Put them right in the message — the model won't pull them from thin air.

That's context engineering at an everyday level. Not magic — you just watch what's on the model's "desk." Good phrasing (how to write a prompt) still matters. But it's one brick inside the context, not the whole answer to "why isn't this working."

Is prompt engineering dead?

No — it's just part of something bigger. The prompt lives inside the context. If you can phrase well, great, but if the model can't see the data it needs, no phrasing will save it. Think not "how do I ask," but "what does the model need to know to answer."

Is context engineering the same as RAG?

No, RAG is one technique inside it. RAG pulls the relevant chunks from your documents and drops them into the context. Context engineering is wider: it's memory, examples, the instruction, the token budget — the whole assembly, not just "fetch a document."