Context engineering: the skill that replaced prompt engineering

A year ago I spent half of every training showing people the 'magic' prompt phrasings. 'Act as a senior engineer.' 'Think step by step.' 'Take a deep breath.' They worked — a little. Nobody cares about those tricks anymore, because they stopped making a difference. The models are good enough now that the exact words barely matter.

What matters is context. Whether the AI gets the right files, the project's conventions, the architecture, and the constraints — or not. This is called context engineering, and in 2026 it's the skill that separates the people AI actually speeds up from the ones still complaining that 'it just generates garbage.'

Why prompt wording stopped mattering

Prompt engineering was born when models were fragile. A badly worded question meant a bad answer, so it paid to polish every word. But the models moved on. Today's agent understands what you want even if you type it sloppily — as long as it has enough information to do it right.

And here's the crux. When an agent fails, it's rarely because you phrased it wrong. It's almost always because it didn't know your code. It didn't know you have a custom error handler and shouldn't write try/except. It didn't know you pin a specific library version. It didn't know a nearly identical function already lives three folders over. A cleverer prompt won't fix that — what's missing is information, not instructions.

What 'context' actually means for a coding agent

Context isn't just the text of your prompt. It's everything the agent has in its context window the moment it starts working. And it comes in several layers that are easy to overlook.

• Relevant files — the specific sources the change touches, plus the ones they depend on
• Project conventions — the instruction file (CLAUDE.md, rules), code style, naming, patterns
• Architecture — how the layers talk to each other, where the boundaries are, who owns what
• Prior decisions — why it's built this way and not another (ADRs, comments, history)
• Constraints — what must not change, which versions, which security and performance requirements

When the agent is missing one of these layers, it fills the gap with a guess. And a capable model's guess looks completely confident — which is exactly what makes it dangerous. The code passes review because it 'looks right,' and the problem only surfaces in production.

Concrete tactics that work

1. Curate files, don't flood

The most common mistake is dumping in 'everything, just in case.' Ten files when three are relevant isn't more context — it's more noise. The model has to find the signal amid the clutter, and its attention gets diluted. Give it exactly the files the task needs and let it pull the rest itself.

2. Keep a project instruction file

CLAUDE.md (or an equivalent rules file) is the cheapest context engineering there is. You write the conventions once and the agent has them in every session. Stack, commands, naming, 'always do X, never Y.' Keep it lean — a few dozen real rules, not a hundred-page manual nobody follows anyway.

# CLAUDE.md — the context the agent needs

## Stack
Django 5.2, Django Ninja, PostgreSQL

## Conventions
- Global ObjectDoesNotExist handler — no try/except boilerplate
- select_related/prefetch_related on every queryset with relations
- All API URLs end with a trailing slash (/)

## Never
- Don't touch migrations that are already deployed
- Don't add dependencies without approval

3. Use retrieval and MCP for live data

Static context isn't enough when the agent needs the current state — the database schema, a library's docs, tickets, error history. MCP servers and retrieval tools let it pull that information when it needs it, instead of you predicting it and pasting it into the prompt. Context becomes dynamic: the agent fetches what it's missing.

4. Scope the task tightly

'Redo auth' is bad context because it's a badly bounded task. 'Rewrite the login endpoint in auth/views.py to JWT, keep the existing signature, run the tests in auth/tests.py' gives the agent clear boundaries. The sharper the scope, the less room for guessing — and the fewer unwanted changes in files it was never supposed to touch.

Common ways to get it wrong

• Too much irrelevant context — flooding with noise that buries the signal
• Stale context — a session dragged over from a previous task, old files, dead approaches
• Missing constraints — the agent doesn't know what it can't change, so it changes it; doesn't know versions, so it uses the wrong API
• Assuming the model 'knows' your project — it doesn't, until you show it

Stale context is the sneakiest. By the time you're on the third task in the same session, the agent is carrying baggage from the first two — files that are no longer relevant and dead ends that actively hurt the next attempt. New task? New session. A clean context almost always beats a bloated one.

A practical workflow

Once you break context engineering into a routine, it stops being a mysterious skill and becomes a handful of steps you do almost automatically.

• 1. Bound the task — one clear change, not 'fix everything'
• 2. Pick the files it actually touches and add them to context
• 3. Confirm the conventions and constraints live in the instruction file
• 4. Have the agent describe its plan and check it has the right picture
• 5. Let it work with a feedback loop — run tests, fix failures
• 6. Clear the session before the next unrelated task

Context engineering isn't hype or another buzzword. It's simply moving your attention from how you talk to the AI to what you give it to work with. I teach this discipline at my workshops on teams' real code — because once you get it, you stop fighting the prompt and start actually steering the AI.