The context problem in a large repository is deciding what the agent needs next. A longer prompt can contain more code while making the relevant dependency harder to find, more expensive to carry, and easier to overlook.
Find a path through the code
Start from the behavior or symbol named by the task. Look up its definition, callers, tests, and nearby interfaces. Then read the source slices needed to decide on an edit. This forms a bounded path from the request to the files that govern it. If the first path fails, expand deliberately: neighboring symbols, related tests, configuration, then broader search. A repository map is a way to choose reads; it does not replace reading the actual implementation before changing it.
RepoGraph reports improvements from a repository-level code graph when attached to the systems it evaluated on SWE-bench and CrossCodeEval. That supports structural navigation as a promising method, while leaving open how much it helps another model, language, or task mix. Repoformer reaches a complementary conclusion for repository-level code completion: retrieval can be selectively invoked because retrieved material is not always useful. Neither paper licenses the blanket rule that every task needs a graph or that more retrieved files always help.
Turn retrieved context into evidence
A useful context packet answers a small set of questions: Which symbol owns the behavior? Who calls it? What contract do its tests express? Which file must change, and which files must stay compatible? Include concise locations and short source excerpts for those answers. Avoid attaching full directories simply because they match a keyword. After an edit, check the actual diff and run the relevant verification so the agent sees whether its hypothesis held.
Index health matters. A stale or incomplete map can quietly point to obsolete definitions. Check that indexing completed for the current checkout, then confirm decisive findings against source before patching. When a map is unavailable, ordinary search and file reads provide a transparent fallback. This is an engineering workflow, not a claim that one retrieval tool has universal superiority.
Measure context by work completed
The “Lost in the Middle” study found position-sensitive performance on long-context question answering and key-value retrieval. It did not test today’s coding agents, so treat it as a reason to check context placement rather than a law about code. In a coding evaluation, compare routes on the same tasks and record retrieved bytes or tokens, time spent locating evidence, and verified completion. A smaller context packet is valuable only if it preserves the facts needed to finish.
There is also a data boundary. A local code index can keep navigation and search on the machine; an agent’s chosen model provider has a separate data policy. Teams should decide what source may be sent to that provider and keep the two decisions explicit. Good context engineering combines precise retrieval, current source checks, and a clear boundary for where the selected evidence goes.
Sources
- Ouyang et al., RepoGraph — graph-assisted repository navigation in evaluated systems.
- Wu et al., Repoformer — selective retrieval for repository code completion.
- Liu et al., Lost in the Middle — long-context position sensitivity on non-coding tasks.
- Codegraff, Why codedb feels instant for agents — an implementation example of local structural indexing.