For a year, the craft everyone talked about was prompt engineering: the right phrasing, the right examples, the magic system message. It mattered, and it still does a little. But if you have watched a capable coding agent produce confident, well-written code that is wrong for your codebase, you have already met the thing that actually decides reliability. It is not how you asked. It is what the model could see when it answered.
That is the shift worth internalizing. The bottleneck for a coding agent on a real codebase is rarely the model's raw ability. It is the quality of the context it was given for the specific task in front of it. Getting that right is a discipline of its own, and context engineering for AI agents is the name that has stuck.
What context engineering actually means
Prompt engineering optimizes the instruction. Context engineering optimizes everything else the model reads before it acts: the relevant slices of the codebase, the conventions your team follows, the constraints that must hold, the prior decisions that explain why the code looks the way it does. The prompt is one line in a much larger brief, and the brief is where reliability is won or lost.
The reason this matters more for code than for chat is that code has a right answer that depends on facts the model does not carry. A model knows what a REST controller looks like in general. It does not know that in your system, controllers never touch the database directly, that auth is handled by a middleware three layers up, or that the helper it is about to reinvent already exists two directories over. None of that is a reasoning failure. It is an information failure, and you fix information failures by engineering the information.
The four things worth putting in the window
Not all context is equal, and the useful mental model is to think in categories rather than "give it more."
Instructions. What the task is, what done looks like, and the guardrails. This is the smallest slice and the one people over-invest in.
Relevant code. The actual modules, interfaces, and call sites the change will touch. This is the slice that moves accuracy the most, and the hardest to get right, because "relevant" is a judgment, not a folder.
Conventions. How your team writes things. Naming, error handling, testing patterns, the libraries you have standardized on. An agent that does not see your conventions will invent its own, and they will be plausible and wrong.
Constraints. The things that must not break: public contracts, migration ordering, performance budgets, security rules. Constraints are cheap to state and expensive to omit.
When a coding agent goes off the rails, you can usually trace it to a missing category. It reinvented a utility because it never saw the existing one. It broke a caller because it never saw the caller. Naming this out loud turns a vague "the AI is unreliable" into a specific, fixable gap.
Context window management is a budgeting problem
Here is the counterintuitive part. The instinct, once you accept that context matters, is to give the model everything. Dump the whole repository in and let it sort things out. That instinct is wrong, and it is wrong for reasons that get worse as your codebase grows.
Every token you add is a token the model has to weigh. Fill the window with marginally relevant files and you have not helped the model find the signal, you have buried it. Long context also has a real recency and position bias: material in the middle of a very large context gets less attention than material at the edges. So context window management is not "how do I fit more," it is "how do I fit the right things and nothing else."
There is a cost dimension too. Bigger context is more expensive per call, and a coding task is many calls. Padding every one of them with a whole repository is a bill you pay for a result that is often worse than a tighter, curated context would have produced. Prompt context design is partly an accuracy problem and partly an economics problem, and the two point in the same direction: less, but exactly right.
Curate, do not dump
The work, then, is selection. For a given task, what is the minimal set of code, conventions, and constraints that a competent engineer would need to do it well? That is the target. Everything past it is noise with a price tag.
Two failure modes are worth watching for. The first is stale context: feeding the agent documentation or code snapshots that no longer match reality. An agent grounded in a map that has drifted from the territory will be confidently, precisely wrong, which is worse than uncertain. Keeping the inputs current is not a nice-to-have. It is the difference between grounding and misleading, which is why documentation that keeps up with the code is part of the same problem.
The second is conflicting context: two sources that disagree, with no signal about which wins. The model will pick one, silently, and you will not know which until something breaks. Good context engineering resolves conflicts before they reach the model, or at least flags them, rather than shipping the ambiguity downstream.
This is the same argument that sits underneath grounding beats prompting, viewed from the supply side. Grounding is what you get when the context is right. Context engineering is the work that makes it right, and getting your codebase agent-ready is a large part of making that work tractable in the first place.
The honest limitation
Context engineering raises the floor on reliability. It does not remove the ceiling. A perfectly curated context still goes to a model that can misread it, and a genuinely ambiguous task is still ambiguous no matter how well you brief it. Curation also has a cost of its own: deciding what is relevant is real work, and doing it badly (too little context) fails just as surely as doing it lazily (too much). There is no setting where the model simply figures everything out, and anyone selling you that is selling you the demo, not the Tuesday.
What you get instead is leverage. Most of the unreliability people attribute to the model is actually attributable to what the model was shown, and that is the part you control. Treating context as something to engineer, not something to dump, is the highest-leverage move available to a team that wants agents to be dependable rather than impressive.
This is a principle we lean on hard in building agents that are reliable on a real codebase. Loopsfinity gives each unit of work the specific slice of context it needs rather than the whole repository, because the goal was never to feed the model more. It was to feed it the right things, and let a human stay accountable for the parts that context alone cannot decide. The details of how we do that are ours. The principle is yours to use, whatever you build with.