Blog / · 6 min read
Prompt engineering is dead. Context engineering took its place.
Why "magic prompts" have been useless since Sonnet 4.5, and what replaced them: context hierarchy, CLAUDE.md files, and memory architecture.
A year ago, Twitter threads about “10 prompts that will change your life” were racking up tens of thousands of likes. Today, they’ve become obsolete — not because prompts stopped working, but because they’re no longer enough on their own.
The skill that actually matters in 2026 is context engineering. Knowing what to put in an LLM’s context, when, in what order, and at what granularity. That’s what makes the difference between an agent that needs 4 iterations to solve a problem and one that nails it on the first try.
What killed prompt engineering
Three shifts made the old tricks obsolete:
1. Models became robust to phrasing
Sonnet 4.5 (released late 2025) started being able to handle imperfect instructions without falling apart. You can tell it “do this thing” instead of “You are an expert X, your task is Y, follow these steps…” and it does the same thing. The big litanies of personas, “let’s think step by step,” “do not hallucinate” — that’s all folklore now. Current models can reason without being begged for it.
2. Context windows exploded
1M tokens on Opus, 200K standard on Sonnet. What used to be a hard constraint (how do I fit this into 8K tokens?) became an abundance to manage (how do I avoid drowning the model in 500K tokens?). The problem changed shape entirely.
3. Tools took over
Claude Code, MCP servers, skills, hooks. Everything that used to be a prompt battle is now a question of tool architecture. The prompt has become a thin layer sitting on top of a rich context system.
What context engineering actually is
Context engineering means designing an agent’s informational environment before you even ask it a question. It covers 4 dimensions:
Dimension 1 — Context hierarchy
A modern agent has several layers of context that combine on every turn:
1. System instructions (never change)
2. Project memory: CLAUDE.md (stable across the project)
3. User memory: global preferences (stable across the user)
4. Session memory: conversation history (volatile)
5. Working set: files/tools loaded for the task (tactical)
Knowing what goes where is a skill in itself. If you put your coding conventions in a prompt sent with every message, you’re paying 5,000 tokens on every turn. If you put them in CLAUDE.md, they’re cached, the agent sees them every time, and thanks to prompt caching you pay nothing after the first turn.
Dimension 2 — Information density
Good context isn’t the biggest one. It’s the one with the highest density of information relevant to the task.
Concrete example. You ask an agent to refactor a function. What context do you give it?
- Bad: the entire codebase “just in case” (1M tokens, the agent gets lost).
- Also bad: just the function (the agent can’t see the callers, the refactor breaks everything).
- Good: the function + the 3-5 files that call it + the project’s
CLAUDE.md+ the associated test.
Making this selection requires understanding your codebase better than the agent can on its own. That’s your job, not its.
Dimension 3 — Order
The order in which information appears in the context has a measurable effect on the agent’s behavior. Known reminder: LLMs have a recency bias (they weigh recent information more) and a primacy bias (what comes first also holds up well).
In practice: critical instructions should be either at the very start of the system prompt, or at the end of the user message. Whatever’s in the middle gets forgotten first.
Dimension 4 — Managing transitions
When an agent runs for a long time (10, 20, 50 turns), the context balloons. Two techniques in 2026:
- Compaction: the agent itself periodically summarizes the last 20 turns into a 500-token digest. Anthropic automated this in Claude Code.
- Targeted retrieval: instead of keeping the entire history, you retrieve only the relevant chunks via embeddings. Cheaper, but you risk losing a detail.
Concrete example: a code review agent
Before (prompt engineering):
You are an expert senior developer with 20 years of experience.
Your task is to review this pull request.
Follow these steps:
1. Read the diff carefully
2. Identify bugs
3. Suggest improvements
4. ...
[200 lines of instructions]
Now (context engineering):
system: Review this PR.
[Claude Code automatically loads:]
- Project's CLAUDE.md → conventions, architecture, tech stack
- .cursorrules / code conventions
- The last 5 merged PRs with their reviews → style examples
- The full diff of the PR
- The touched files in their entirety (not just the diff)
- The associated tests
+ a /review skill that triggers a predictable sequence:
1. Read CONTRIBUTING.md
2. Check that tests pass
3. List questionable points
4. Propose concrete changes
The prompt itself is 4 lines. The rest is well-architected context. And the results are qualitatively better because the agent has all the necessary information at the right time.
What to learn if you want to level up
If you want to grow on these topics in 2026, here’s what matters:
-
Master CLAUDE.md and equivalents. A good project CLAUDE.md accounts for 60% of the gain from a well-configured agent. You write it once, you reuse it everywhere.
-
Understand prompt caching. It’s the key to keeping large context economical. If you don’t use it, you’ll either blow up your bill or limit your contexts.
-
Learn to build skills / custom commands. A well-made skill is a fixed procedure that encodes your domain knowledge. You build it once, it gets used 1,000 times after that.
-
Architect your agents’ memory. Short-term, long-term, per-project, per-user. That’s the new state management.
-
Practice context debugging. When an agent messes up, 80% of the time it’s not a model problem, it’s a context problem. Knowing how to inspect what it “saw” at the moment of the decision is a critical skill.
What’s left of prompt engineering
Prompt engineering hasn’t completely disappeared. It survives in two cases:
1. When you’re hitting the API directly with a less capable (or older) model, with no infrastructure around it. There, exact phrasing still matters.
2. For sharp creative tasks (high-level copywriting, conceptual exploration). You can get very different outputs depending on how you frame the prompt, even with the big models.
For everything else — dev, agents, automation — it’s archaeology.
The takeaway
Stop collecting prompts like Pokémon cards. Start building context environments for your agents. Write CLAUDE.md files. Build skills. Master caching. Architect memory.
The developer who’ll make the difference over the next 2 years isn’t the one who knows the “best prompt.” It’s the one who knows how to configure a context in which any question produces a useful answer on the first try.
Keep reading