Prompt Engineering is Dead. Long Live Context Engineering.

For a couple of years, Prompt Engineering was sold as the new must-have skill.

Courses, certifications, job titles, threads full of "magic phrases" that supposedly unlocked better answers from any model.

Write it like this, not like that. Add "think step by step". Give it a role. Promise it a tip if it does a good job.

I bought into some of that too, at least at the beginning.

But if you've spent real time running Coding Agents against a real codebase, not a toy example, you already know where this is going.

The prompt was perfect. The result wasn't.

Some time ago I asked a Coding Agent to implement a fairly simple feature.

I didn't improvise the prompt. I described the feature in detail, the expected behavior, even a couple of edge cases I wanted covered.

By every "Prompt Engineering" standard, it was a good prompt.

And yet, the agent added a new abstraction where an existing helper already solved the problem two files away. It ignored a project convention I've followed for years. It invented a dependency I never asked for.

Nothing in the prompt was wrong. What was missing wasn't in the prompt at all — it was everything around it that I never gave the agent. None of it lived in a CLAUDE.md, in a Skill, or anywhere else the agent could actually reach. It only lived in my head.

Prompt Engineering optimized the wrong layer

Prompt Engineering assumes the bottleneck is how you ask.

Phrasing, examples, role-play, formatting tricks, "step by step" instructions. All of that can genuinely improve a single, isolated answer.

But a real software project is not a single, isolated answer. It's architecture, conventions, history, trade-offs, constraints that live in people's heads, and decisions nobody wrote down because "everyone on the team already knows".

An agent that only receives a well-written prompt is missing all of that. And no amount of clever wording fixes missing information.

The real lever is context, not wording

What actually changes the quality of an agent's output is whether it knows:

• What you're trying to build, beyond the immediate ticket.
• What constraints already exist in the codebase.
• What architecture it's expected to respect.
• What conventions the project follows.
• What tools it's allowed to use.
• What boundaries it must not cross.
• What validations it should run before calling something done.

None of that fits in a single prompt. It has to live somewhere the agent can consistently reach it — and today that "somewhere" has actual names. A CLAUDE.md or AGENTS.md file for conventions, architecture, and boundaries. Skills for procedures you want followed the same way every time, instead of re-explained on every session. MCP servers for the external tools and data the agent is allowed to touch. Hooks for validations that run automatically, so correctness doesn't depend on the agent remembering to check.

That's the shift from Prompt Engineering to Context Engineering: from "how do I phrase this request" to "what does the agent need to know, and where should that knowledge live, so it can make good decisions without me".

More context is not automatically better context

Here's the part that surprises people once they start taking this seriously: dumping more documents, more tools, and more instructions at an agent does not reliably improve the result.

A wall of outdated rules in AGENTS.md is worse than no file at all. Ten MCP servers wired up because they might be useful someday are worse than three the agent actually knows when to reach for. Two Skills that overlap and quietly contradict each other are worse than one clear one. Context that contradicts itself is worse than no context, because now the agent has to guess which part to trust.

Context Engineering isn't about maximizing the amount of information. It's about curating it — keeping it accurate, relevant, and easy for the agent to act on.

Designing the decision space, not just the request

This is the part I think changes the role of a senior engineer the most.

Prompt Engineering treats the agent like a vending machine: put in the right coin, get the right snack.

Context Engineering treats it more like onboarding a new hire. You wouldn't hand a new engineer a one-line ticket and walk away. You'd give them the codebase, the style guide, a couple of examples of PRs that were accepted and why, and a clear list of what not to touch.

That's exactly what I do now with the projects where I use Coding Agents seriously: project instructions in a CLAUDE.md, Skills for the patterns I want repeated exactly, explicit tool permissions so the agent can't reach past its allowed MCPs, and a short list of checks — tests, lint, a review step — it has to run before it can call something finished.

The prompt is still there. It's just no longer the main event.

The second job running in parallel: maintaining the agent, not just prompting it

Once context lives in files, Skills, and tool configs instead of your head, a new kind of work shows up — one Prompt Engineering never had to account for, because it assumed everything happened inside a single chat turn.

A session with a Coding Agent isn't just: write the prompt, wait for the result, validate it, move to the next task. Underneath that, every iteration quietly forces you to also ask:

• Is the agent correctly defined for this kind of task, or am I improvising context on the fly again?
• Should I update its instructions — the CLAUDE.md, the AGENTS.md?
• Does this task need a new Skill, or is an existing one missing a case I just hit?
• Is the agent even reaching for the right Skill or MCP, or picking the wrong tool because two of them look similar?
• Did it just cross a boundary I thought I'd already set — and if so, where should that boundary actually live?

None of that is prompting. It's maintaining the system the agent operates in, session after session.

And this is where it gets expensive: when the output is wrong, there are always two ways out.

The fast one is to re-explain it in the chat — rephrase, add the missing detail, correct it inline, and move on. It works, for that session.

The good one is to fix it where it will actually stick: update the CLAUDE.md rule, edit the Skill, adjust an MCP's tool description, add the missing example. It costs more right now, but it pays off in every session that follows.

I've caught myself taking the fast path more than once — explaining the same architectural constraint for the third time in a week, instead of spending five minutes making it impossible to miss again.

The time you save writing code, you spend defining the agent

This is the trade-off nobody mentions when they talk about "10x productivity with AI".

Coding Agents do save time on typing, boilerplate, and first drafts. But if you're doing this seriously, that time doesn't disappear — it moves. It moves into writing and maintaining Skills, curating what goes into AGENTS.md, deciding which MCP servers actually deserve a permanent connection, and reviewing whether the agent picked the right tool for the job.

Context Engineering isn't a one-time setup you do before the "real work" starts. It's ongoing configuration work that competes for the same hours the agent was supposed to free up.

The engineers who get real value out of this aren't the ones who prompt well in the moment. They're the ones who treat every bad output as a signal about the system, not just about that one request — and who are willing to reinvest part of their saved time into fixing it there.

Conclusion

Prompt Engineering isn't wrong. It's just incomplete, and increasingly irrelevant on its own.

The skill that actually separates useful output from expensive noise is designing — and continuously maintaining — the context an agent operates in: the CLAUDE.md it reads, the Skills it can reach for, the MCPs it's allowed to call, and the checks it has to pass. That maintenance is real work, and it's where the hours AI was supposed to save you actually go.

In the next article of this series I'll go one level deeper, into Harness Engineering: the systems, tools, and checks you build around an agent so that context stops being a one-off prompt and becomes the environment it always works in.

Until then, the question worth asking isn't:

What's the best prompt for this?

It's:

What does this agent need to know — and where should that knowledge actually live — to make the same call I would?

If you're building similar workflows around Coding Agents, I'd genuinely like to compare notes — feel free to reach out.