Repository Context Is the Bottleneck Your AI Coding Stack Is Ignoring

Most enterprise AI coding tool evaluations spend their energy comparing model benchmarks and IDE plugin quality. Those are real considerations, but they are not where production deployments break down. What actually fails, repeatedly and expensively, is the layer between the agent and the codebase: how the agent finds relevant code, how it maintains that understanding across edits, and how it avoids spending most of its token budget rediscovering things it already knew three steps ago. Fix the model selection and ignore this layer, and you will still get an agent that loops, hallucinates import paths, and degrades as the codebase grows.

Companion piece to our broader work on agentic coding at scale. See The Subagent Architecture: How to Stop Your Coding Agent from Burning Its Entire Token Budget on Repo Search for a practical guide to decomposing monolithic agents and optimising retrieval across large repositories.

Why Single-Index Retrieval Breaks at Codebase Scale

Most coding agent stacks retrieve context through one primary mechanism: either a vector similarity search over embedded code chunks, or a lexical search similar to grep. Each of these works in isolation for narrow tasks. Neither works reliably when an agent needs to navigate a repository it has never fully read, understand a symbol's definition and all its callers, and then write code that respects existing patterns.

The underlying problem is that code has multiple distinct structures that no single index captures well. Lexical search finds exact tokens but misses semantically equivalent patterns. Vector search surfaces conceptually related code but struggles with precise symbol resolution. Neither gives the agent the call graph or import dependency structure it needs to understand what a change will actually affect.

The CodeNib research formalises this as a multi-view problem: lexical, dense (vector), and structural (graph) indexes each capture different evidence about the same source state, and a production context system needs all three (Yu et al., arXiv 2026). The practical implication for engineering leaders is that any agent stack built on a single retrieval path is systematically blind to at least one class of evidence that code understanding requires.

The Index Maintenance Problem Nobody Budgets For

Indexes are not a one-time build cost. Every commit changes the source state, and any index that does not reflect current state is a source of hallucination. This is where most evaluations fail to look: they measure retrieval quality at a fixed snapshot, not retrieval quality after six weeks of active development across four teams.

The CodeNib findings on incremental update performance are directly relevant here. When updated index outputs match an independent full rebuild, graph updates are 8.7 times faster and vector updates are 25.4 times faster at the median (Yu et al., arXiv 2026). That gap matters because it defines whether you can afford to keep indexes current at commit frequency, or whether you are forced to accept staleness.

Engineering leaders should ask their current vendor a direct question: what is the index update latency after a merge to main, and what is the staleness window during that period? If the answer is vague, the agent is almost certainly operating on stale context for a meaningful fraction of its requests, and the errors that produces will be difficult to attribute to index lag rather than model failure.

Static Navigation Versus Live Language Server Calls

The Latency Trade-off

Many agent frameworks resolve symbol navigation by calling a live language server at request time. This is accurate but expensive. The CodeNib data shows a median per-request latency ratio of 4.7 times between live server calls and static index lookups, measured on the subset of requests where static navigation matched normalized live-server locations (Yu et al., arXiv 2026). At low request volumes that ratio is acceptable. At the throughput of a multi-team deployment running dozens of concurrent agent sessions, it becomes a meaningful infrastructure cost and a latency bottleneck.

The Coverage Trade-off

The same data shows that static navigation matched live-server results for 63 percent of the 1,000 requests tested (Yu et al., arXiv 2026). That leaves 37 percent where static indexes would have returned incorrect or incomplete navigation results. A production system needs a policy for that gap: either fall back to live resolution selectively, or accept bounded inaccuracy on that portion of requests.

The decision is not purely technical. It depends on what kinds of tasks your agents are running. Agents doing read-heavy analysis can tolerate more static-index reliance. Agents writing and refactoring production code need higher navigation accuracy, which pushes toward more live resolution and higher per-request cost.

Context Selection and Token Budget Discipline

Even with accurate retrieval, agents fail when context selection is undisciplined. An agent that reads every potentially relevant file before acting will exhaust its context window before it reaches the files that actually matter. This is not a model limitation. It is a retrieval and ranking problem.

The CodeNib research measures this directly. Selected context policies, which rank and bound what enters the agent's context window, preserve localization quality while using 50 to 87 percent fewer trajectory tokens than paired grep-and-read approaches across five models tested (Yu et al., arXiv 2026). That range reflects the interaction between policy design and model behaviour, but even the lower bound represents a substantial reduction in token consumption per task.

For engineering leaders, this translates directly into cost and throughput. Token budget is not just a model API cost line. It determines how many parallel agent sessions you can run, how complex a task an agent can complete without truncating its own context, and how much of the context window remains available for the agent's own reasoning rather than raw file content.

What an Audit of Your Current Stack Should Cover

Before committing to a vendor or scaling a current deployment, there are four concrete questions worth answering about the context infrastructure specifically.

First, how many index types does the system maintain, and what evidence does each one capture? A stack with only vector search is missing lexical precision and structural navigation. Second, what is the index update latency after a commit, and does the system expose staleness status per view? Third, what is the navigation accuracy policy: does the system use static indexes, live resolution, or a hybrid with defined fallback conditions? Fourth, how does the system bound context before it enters the agent's window, and what is the measured token cost per task type at your codebase size?

These questions do not require a proof-of-concept to answer. A vendor with production-grade context infrastructure should be able to answer them from their architecture documentation. If the answers are not available, that is itself a signal about the maturity of the context layer.