Context Engineering for Coding Agents
Search interest in "context engineering" has roughly doubled over the past year (Google Trends), and the questions driving it are definitional: what it is, how it differs from prompt engineering. The definition that stuck comes from Anthropic's engineering team, in Effective context engineering for AI agents: "the set of strategies for curating and maintaining the optimal set of tokens (information) during LLM inference." Prompt engineering asked how to phrase the instruction. Context engineering asks what deserves to be in the window at all. For coding agents the second question is the harder one, because the repository is the data source that always exceeds the window.
The window is a budget
Two findings anchor the discipline. Models degrade as context grows: Anthropic calls it context rot, and states it plainly: "as the number of tokens in the context window increases, the model's ability to accurately recall information from that context decreases." The degradation has an architectural cause. Attention computes pairwise relationships across tokens, so each added token stretches the model's attention budget thinner across everything already there.
The practical stance that follows: treat tokens as spend. The goal, in the post's words, is "the smallest possible set of high-signal tokens that maximize the likelihood of some desired outcome". A token spent on a file the model needed nothing from is worse than wasted, because it also dilutes attention over the tokens that mattered.
The budget is shared, which makes it tighter than it looks. System prompt, tool definitions, conversation history, and every tool result the session has produced draw from the same pool the task needs. For scale: a mid-sized production codebase runs to millions of tokens of source, so a 200,000-token window holds a low single-digit percentage of it, minus everything above. Whatever survives the cut is the agent's entire view of your system.
How coding agents spend it today
Watch a session transcript and the spend pattern repeats: whole-file reads to answer a one-line question, search output with forty matches pasted in full, directory listings three levels deep, and the residue of abandoned attempts nobody cleared. The agent pages the repository through its window hoping the relevant part sticks. On a small project this works, which is why the habit survives. On a large one it produces the failure mode we walked through in why AI coding agents fail on large codebases: the model did not change, the signal density of its context did.
Sub-questions are where the budget actually drains. "Who calls this function" answered by text search costs one grep plus opening every match to decide whether it is a live call site, a string coincidence, or a same-named method on an unrelated class. Every check pulls another file into the window. The question had a three-line answer; the route to it can cost tens of thousands of tokens, and those tokens stay in context for the rest of the session.
Just-in-time context
The direction Anthropic describes is a shift away from pre-computing everything relevant up front, toward "just in time" strategies: the agent keeps lightweight identifiers and retrieves data at runtime through tools. They note the approach mirrors human cognition, and any working engineer will recognize it. Nobody reads a repository before starting a task. You keep an index in your head (paths, names, a sense of what owns what) and look things up the moment a question becomes concrete.
For code, the lookup layer does not need to be improvised, because the recurring questions have a known shape. Who calls this. What does it depend on. What sits downstream if it changes. Which tests stand over it. Each is a traversal over a graph of symbols and edges, and a parsed code graph returns each answer as a short list of identifiers with file paths and line bounds. This is retrieval by relationship, and it behaves differently from retrieval by similarity; the comparison has its own post in code embeddings vs the code graph.
The economics compound over a session. An agent that answers its first sub-question cheaply arrives at the second with a cleaner window, so the second answer lands sharper too. A session that opens with three whole-file reads pays interest on them in every turn that follows, because those tokens keep occupying attention long after their moment passed. The longer the task, the more the retrieval layer matters.
What a high-signal answer looks like
We measured the shape on cal.com at commit 8418db7 for an earlier post. The question was whether an eight-line translation-merge helper was safe to edit. The graph answered with 2 direct callers and 30 downstream symbols across 30 files, named, including several user-facing booking pages. The whole answer fits in a few hundred tokens, and it changed the plan. Reaching the same confidence by reading means opening every file a text search surfaced and tracing call paths by hand, with each opened file drawing down budget and thinning attention over the few lines that mattered.
A loop that holds the budget
The version of this we run in practice, with the graph served over MCP:
- Orient with a computed module map, so the agent learns the shape of the system without pasting directory trees.
- Resolve the task to symbols with one targeted lookup: a name, a route, a literal string.
- Before any edit, pull callers and blast radius for those symbols. This step replaces the grep-and-open spiral.
- Read source last, and only the spans the graph located.
- Close by listing the tests that cover what changed.
Steps 1 through 3 return compact, structured answers, so the window stays mostly free until step 4, the first moment real source enters it. That ordering is the entire trick: identifiers travel through the session, and source appears once, briefly, where the map points. The loop also degrades gracefully: when a step returns something surprising (more callers than expected, a test that should not exist), the agent spends a read early, on purpose. Curation does not mean starving the model. It means every file that enters the window is there because something located it first. Claude Code and the other MCP clients wire into this directly; setup for each lives in our integrations guides.
Known limits
Curation cannot rescue a wrong plan; a perfectly trimmed window still executes the task it was given. Some questions are semantic ("where is retry handled, conceptually") and want meaning-level search before graph traversal takes over. And the graph must track the code: an index that trails the branch you are editing curates the wrong tokens with full confidence, so the graph has to be branch-aware and follow every push.
Symvanta is the just-in-time layer in this loop: it parses your repositories into a live graph and serves callers, dependencies, blast radius, and test coverage to your agent over MCP, per branch, in answers sized for the window. Watching your own codebase come back as caller lists takes about fifteen minutes. Book a 15-minute demo