What is context engineering in AI coding?
Context engineering is the practice of selecting, filtering, and structuring the information an AI model receives for a given task. It is not the same as prompt engineering. And it is not solved by using larger context windows.
Why context matters more than model capability
A highly capable model working with poor context will produce poor results. It will miss project-specific patterns, repeat mistakes that were already addressed in previous sessions, and spend tokens on reasoning that could have been avoided with the right information upfront.
Context engineering addresses this by treating context as a decision rather than a default. Instead of dumping everything available into the prompt, context engineering asks: what does the model need to know to do this specific task, and what can be left out?
More context is not always better. Long prompts with irrelevant context dilute the signal, increase cost, and sometimes lead models toward correct-looking but wrong outputs because they are attending to the wrong parts of the input.
The four decisions of context engineering
Context engineering for AI coding involves four types of decisions:
- Select: What information is relevant to this task? File structure, recent changes, working agreements, task history, dependency context. Not all of this is relevant to every task.
- Filter: What should be excluded? Stale context, unrelated modules, resolved issues, information the model already has from the session state.
- Structure: How should the context be presented? Order matters. Priority matters. What appears early in the context has more influence than what appears late.
- Validate: Is the context current? Context based on an old version of a file, a resolved issue, or a superseded decision can cause more harm than no context at all.
Stale context: the silent problem
Stale context is information that was accurate at the time it was created but no longer reflects the current state of the project. Architectural decisions that were revisited. APIs that changed. Working agreements that evolved. File structures that were reorganized.
Stale context is harmful because it is still plausible-looking. A model that receives stale context does not know it is stale. It reasons from it as if it were current. The output may look coherent while being based on incorrect assumptions.
This is one reason why context engineering is not a one-time setup task. It requires maintenance. Context needs to be validated and updated as the project evolves.
Context windows are not a substitute for context engineering
One response to context management challenges is to use larger context windows: just include everything and let the model sort it out. This approach has limits.
First, larger windows cost more. Including 200,000 tokens of context when 5,000 tokens would have been sufficient is expensive. Second, models do not process all context equally well. Evidence suggests that information at the very beginning and very end of a long context window receives more attention than information in the middle, a pattern sometimes called the "lost in the middle" problem. Third, a larger window does not fix stale context. It just buries it deeper.
Context engineering produces better results with smaller, more precise context packages than large windows with everything included.
Reusable context and session continuity
One of the highest-value opportunities in context engineering is making context reusable across sessions. If the project setup, working agreements, and task history are re-explained from scratch at the start of every session, the cost and quality of those sessions is capped at "start from zero."
Reusable context packages, validated and updated as the project changes, allow subsequent sessions to start closer to the actual task. The model begins with the right orientation instead of spending the first portion of the session reconstructing it.
This requires that reusable context be treated as an artifact: created deliberately, validated against the current state of the project, and updated when the project changes. It is not something that happens automatically.
How Avorelo helps
Avorelo acts as a context compiler for AI coding sessions. It selects task-relevant context, filters stale or irrelevant information, and structures the context package for each run. Context is matched against the current task, not just carried forward from the previous session.
It also maintains reusable context packages that persist across sessions. These packages are validated against the current project state and updated when relevant changes occur. The result is that sessions start with accurate, compact context instead of a repeated full explanation.