Context Engineering vs Prompt Engineering: What Actually Changed
The hard problem moved.
It is no longer how you phrase the prompt.
It is what reliable context reaches the model on every run, scoped to the work in front of it.
What this covers
- Prompt engineering optimizes the wording of a single request. Context engineering optimizes everything in the window around it: instructions, retrieved knowledge, tool output, and history.
- For coding agents the prompt is often short and obvious. The failure is almost always missing or wrong context, not a poorly worded question.
- Good context engineering is selective, scoped, and reviewable. More tokens is not the goal; the right tokens for this task is the goal.
- Pathrule is one implementation of context engineering for teams: path-scoped memories, rules, and skills delivered at hook time before the model decides anything.
Comparison
| Question | Prompt engineering | Context engineering |
|---|---|---|
| What it tunes | The wording of one request | Everything in the window: rules, retrieved knowledge, tool output, history |
| Where it lives | In the chat message | In the system context assembled before the message |
| Who owns it | The person typing right now | The team, as a reviewable layer |
| How it fails | Ambiguous or under-specified phrasing | Missing, stale, or wrongly scoped context |
| How you improve it | Rewrite the sentence | Fix what gets retrieved and when |
Two disciplines that get confused
Prompt engineering is the craft of phrasing a request so a model answers well. Add the role, state the format, give an example, ask it to think step by step. It is real, it still matters, and for one-off questions it is often enough.
Context engineering is a different craft. It is the work of deciding what the model sees before it reads your message at all: the system instructions, the retrieved documents, the tool output, the prior turns, and the team knowledge relevant to the task. The prompt is one input among many. Context engineering owns the rest.
The two get confused because they share a surface. Both end up as tokens in a window. But you improve them in completely different places. You improve a prompt by rewriting a sentence. You improve context by changing what gets retrieved, when, and at what scope.
Why coding agents shifted the weight to context
For a chat assistant answering a general question, phrasing carries a lot of the result. For a coding agent working in a real repository, the prompt is often trivial: fix this test, add this field, follow the existing pattern. The hard part is everything the agent does not know yet.
It does not know that this folder has a schema convention the rest of the repo ignores. It does not know the deploy checklist that lives in one engineer head. It does not know the exception that caused the last incident. No amount of prompt rewording supplies that. Only context does.
So the leverage moved. The teams getting reliable results from coding agents are not the ones with the cleverest prompts. They are the ones who engineered what the agent sees on every run.
More context is not the answer either
The naive fix is to dump everything into the window: the whole wiki, every rule, the full architecture doc. This fails for the same reason a thousand-line instruction file fails. The model treats a flood of low-relevance text as background and the signal you needed drowns in the noise.
Good context engineering is selective. The goal is not maximum tokens. It is the right tokens for this specific task, and nothing else. A schema rule belongs in the window when the agent is editing the schema, and nowhere else.
This is why scope is the central idea. Context that is always on is context that is mostly wrong. Context that arrives because it matches the work is context the model can actually use.
The four inputs worth engineering
Most coding-agent context comes from four places. Instructions: the rules and conventions the team wants followed. Retrieved knowledge: facts and decisions pulled in based on the task. Tool output: the results of searches, reads, and commands the agent runs. History: the prior turns and any summary of them.
Each one is a lever. Instructions should be scoped so only the relevant ones load. Retrieval should be precise so the agent does not have to rediscover known facts by brute-force search. Tool output should be bounded so a broad grep does not flood the window. History should be preserved where it matters and summarized carefully where it does not.
Prompt engineering touches none of these directly. Context engineering is the practice of getting all four right, consistently, without a human assembling them by hand each session.
Making it a team practice, not a personal skill
The trap is letting context engineering stay a personal skill. One engineer learns exactly what to paste in to get a good result, and that knowledge never leaves their session. The next person starts from zero, and the agent looks unreliable to them.
A durable practice stores the context outside the chat, scopes it to the path where it applies, and reviews it like code. When someone learns a new convention, it becomes a memory at the right path. When an incident teaches a lesson, it becomes a rule the agent receives near the code it protects.
Pathrule is one implementation of that practice. Team memories, rules, and skills attach to paths in a workspace tree that mirrors the repo. Retrieval walks from the active path up the ancestors and the matching slice arrives at hook time, before the model reads the prompt. The engineering happens once and every session inherits it.
A test you can run this week
Take a task where the agent reliably guesses wrong. Resist the urge to rewrite the prompt. Instead, ask what the agent did not know, and write that down as one scoped piece of context attached to the path it applies to.
Run the task again in a fresh session with the same short prompt. If the result changes, the bottleneck was context, not phrasing, and you have just done context engineering in its smallest form.
Every signup gets three months of Pathrule PRO on the house. If you want help turning a recurring agent mistake into scoped context on a real repo, [email protected] is open.