Lost in the Repo: Why Bigger Context Windows Still Miss the Point

Context is comforting.

A large context window gives managers, developers, and product demos the same pleasant illusion: if the model can see enough of the repository, it should stop missing important files. Put the whole codebase into the window. Add retrieval if necessary. Let the agent read, reason, edit, and move on.

This is a fine theory, provided software were a stack of documents.

Unfortunately, software is not a stack of documents. It is a graph with grudges.

The paper The Navigation Paradox in Large-Context Agentic Coding argues that larger context windows do not eliminate repository-navigation failures. They relocate the bottleneck. The old problem was capacity: can the model access the relevant file? The new problem is salience: does the model know that the file is relevant in the first place?¹

That distinction sounds small until a coding agent refactors a base class, updates the file it can name, and misses the dependency-injection site that quietly constructs the affected object. The model did not lack intelligence. It lacked a map.

The paper’s contribution is useful because it does not merely say “graphs are good.” That would be another episode of Enterprise Architecture Discovers Lines Between Boxes. Its sharper claim is that retrieval and navigation answer different questions. Retrieval asks which files look similar to the task description. Navigation asks which files are structurally connected to the file being changed.

Those are not rival implementations of the same idea. They are different abstractions.

The failure mode begins when relevance is structural, not semantic

Most repository-level coding agents begin with a familiar sequence. They parse the task, search for matching terms, open the files that appear relevant, and edit what they find. Sometimes this is exactly right.

If the task says “change the error message ‘incorrect email or password’,” keyword search has a fair chance of finding the string. BM25, embeddings, grep, and the agent’s own file-search tools are all operating in friendly territory. The query and the target file share vocabulary. The file is visible because the language points at it.

The problem appears when the required file is connected by architecture rather than by words.

Consider the paper’s example: “Add a logger parameter to BaseRepository.__init__.” The obvious file is the repository base class. A competent agent can find it. But a complete change also requires finding where repositories are instantiated. In the FastAPI RealWorld app used by the paper, that means app/api/dependencies/database.py. That file does not need to contain “logger,” “parameter,” or “BaseRepository” in any way that makes it rank highly for the task description. Its relevance is caused by construction and wiring.

The model can search forever with the wrong lens. It will simply become faster at missing the same file.

This is the Navigation Paradox:

expanding context reduces the cost of access, but does not guarantee the discovery of architectural relevance.

The business version is even less poetic: buying a larger context window may reduce one class of failure while leaving the expensive class untouched.

Retrieval is not broken; it is answering the wrong question

A useful way to read this paper is to separate three kinds of repository tasks.

This taxonomy matters more than the raw leaderboard. It tells us when a technique should work.

For semantic tasks, retrieval is not an embarrassment. In the paper’s benchmark, BM25 achieves 100.0% Architectural Coverage Score on G1 semantic tasks, compared with 90.0% for Vanilla Claude Code and 88.9% for the graph condition. That is exactly what should happen. When the target is textually visible, keyword retrieval is cheap and effective. No need to bring a graph database to a string match. Even architecture has a dignity threshold.

For hidden-dependency tasks, the picture changes. Vanilla reaches 76.2% ACS. BM25 reaches 78.2%. Graph navigation reaches 99.4%.

The important comparison is not “graph beats BM25.” The important comparison is that BM25 barely moves relative to Vanilla on G3 hidden tasks. That is the mechanism showing through the numbers. Retrieval cannot rank what the query does not describe.

This is why “better retrieval” is not always the right answer. A more expensive embedding model may improve semantic matching, but hidden architectural dependencies are not merely semantically faint. They may be semantically absent. The connection lives in imports, inheritance, instantiation, framework wiring, and conventions that are not expressed in the user’s task.

In that setting, retrieval is not underpowered. It is misapplied.

CodeCompass turns the repository into a navigable object

The paper introduces CodeCompass, an MCP-based tool that exposes a static dependency graph to Claude Code. The graph is built from Python AST analysis and stored in Neo4j. It includes three edge types:

The graph used in the experiment contains 71 nodes and 255 edges: 201 IMPORTS, 20 INHERITS, and 34 INSTANTIATES. For a queried file, CodeCompass returns its one-hop architectural neighborhood in both inbound and outbound directions.

This makes the tool modest in a good way. It is not trying to understand the entire program the way a senior engineer does after three years of incident reviews and regrettable Slack threads. It simply answers a precise question:

Given this file, what other files are structurally connected to it?

That question is enough to surface files that lexical search misses. When querying app/db/repositories/base.py, CodeCompass returns app/api/dependencies/database.py through IMPORTS and INSTANTIATES relationships. In the paper’s clearest Veto Protocol example, the internal search path fails to surface database.py, while graph traversal returns it directly.

That is the mechanism. The tool works because it changes the search space from query similarity to structural adjacency.

The experiment measures navigation, not patch quality

The paper uses a controlled 30-task benchmark on the FastAPI RealWorld example app, a roughly 3,500-line Python application with repository patterns and dependency injection. The tasks are divided into three groups:

• G1: semantic tasks, where required files are keyword-discoverable;
• G2: structural tasks, where required files are connected by two-to-four-hop import chains;
• G3: hidden tasks, where required files have little semantic overlap and are reachable through structural traversal.

The authors compare three conditions:

The metric is Architectural Coverage Score:

This is worth pausing on. ACS is not pass@1. It does not prove that the agent wrote correct code. It measures whether the agent read or edited the files that a complete implementation would require.

That makes ACS narrower than correctness, but also cleaner for this paper’s question. The authors are not trying to prove that CodeCompass writes better patches in every situation. They are testing whether graph navigation helps the agent discover architecturally relevant files.

This is a good methodological choice, as long as we do not inflate it. A model can read every required file and still produce broken code. Anyone who has watched an agent confidently edit three files into mutual inconsistency has already received this education free of charge.

The main result is not “graphs win”; it is “graphs win where semantics disappear”

The overall results are easy to misread, so the grouped table matters.

If we only look at overall ACS, graph navigation edges out BM25, but not by a dramatic margin: 88.3% versus 87.1%. That would make the paper sound like another incremental tool comparison.

The real finding is segmented.

BM25 dominates semantic tasks. Graph navigation dominates hidden-dependency tasks. The graph condition performs worse on G2 structural tasks, which is not a side detail; it is one of the most interesting results in the paper.

The G3 result supports the core thesis. On hidden dependencies, graph navigation reaches 99.4% ACS, compared with 76.2% for Vanilla and 78.2% for BM25. The authors also report Welch’s t-tests showing the graph condition significantly outperforming both baselines on G3: Graph vs Vanilla at $t=5.23$, $p<0.001$, and Graph vs BM25 at $t=4.83$, $p<0.001$.

That is main evidence, not robustness decoration. It directly supports the claim that graph navigation helps when dependency relevance is structural rather than semantic.

The G1 result is also evidence, but in a different direction. It prevents overclaiming. Graph navigation is not a universal replacement for retrieval. When the task is semantically visible, retrieval is already strong. The right operational takeaway is not “install a graph and delete search.” It is “route different task types through different navigation strategies.”

The G2 regression is the warning label. Graph tools do not help when agents do not use them.

The adoption result is the part enterprises should read twice

The paper’s most practically useful result is not the G3 score. It is the tool-adoption behavior.

In the graph condition, the model had explicit instructions to call get_architectural_context before editing. Yet 58.0% of Condition C trials made zero MCP calls. When the graph tool was used, mean ACS reached 99.5%. When it was ignored, mean ACS dropped to 80.2%, essentially back to the Vanilla baseline.

That is the uncomfortable operational lesson: capability is not adoption.

This matters because many AI deployments treat tools as optional affordances. Add a search tool. Add a database tool. Add a graph tool. Tell the agent to use them when useful. Then act surprised when the agent improvises a cheaper path through the task and misses the thing the tool was designed to reveal.

The paper’s task-group breakdown makes this sharper:

The G2 result is almost rude in its clarity. Structural tasks were exactly where graph navigation should have been useful, yet the model never called the graph tool. The agent behaved as if ordinary file exploration was good enough. It achieved partial coverage, skipped the map, and paid the price.

This is where the article should resist a lazy conclusion. The problem is not that the model is stupid. Its behavior may be locally rational. Tool calls have overhead. Graph results may introduce extra files. If the default Glob+Read workflow appears to make progress, the agent conserves effort.

The problem is that local effort minimization is not the same as architectural completeness.

In enterprise terms, optional rigor produces optional rigor. A shocking discovery, surely.

Prompt engineering helped, but workflow enforcement is the real product lesson

The paper reports an improved prompt experiment for G3 tasks. After initial G3 trials showed lower MCP adoption, the authors moved a mandatory checklist to the end of the prompt, partly to mitigate “Lost in the Middle” effects. Adoption on G3 rose to 100%, and mean G3 ACS increased from 96.6% to 99.4%.

This is useful, but it should not be overinterpreted.

The likely purpose of this prompt variant is an implementation and adoption test, not a second thesis about prompt design. It shows that tool-use behavior is sensitive to instruction placement. It does not prove that a carefully worded prompt is sufficient for production reliability.

For business deployment, the better inference is architectural:

The most robust production pattern is probably not “please use the graph if helpful.” It is more like:

1. Identify the primary file or component touched by the task.
2. Mandate a dependency-neighborhood check before edits.
3. Require the planning step to explain which returned neighbors are in scope or out of scope.
4. Only then allow patch generation.
5. After patch generation, run a second structural impact check for changed files.

This is not model tuning. It is workflow engineering.

That distinction matters for buyers and builders. If the agent’s failure is navigational, then upgrading the base model may help less than redesigning the work loop. The ROI may come from boring infrastructure: dependency graphs, call-chain maps, ownership metadata, architectural rules, and enforced planning stages.

Boring, in enterprise software, is often another word for “the thing that survives procurement.”

What the paper directly shows, and what Cognaptus infers

The paper directly shows that, in one controlled Python repository benchmark, graph navigation substantially improves architectural file coverage on hidden-dependency tasks. It also shows that BM25 remains excellent on semantic tasks and weak on hidden ones. Finally, it shows that graph-tool adoption is inconsistent unless the workflow makes the tool salient enough for the agent to use.

Cognaptus infers three business implications.

First, repository-scale coding agents need a navigation layer, not just a retrieval layer. Search is still valuable, but it should not be asked to infer architectural dependencies that do not appear in the task vocabulary.

Second, coding-agent governance should include tool-use policy. If a change affects a base class, shared service, dependency provider, schema, interface, or configuration object, structural navigation should not be optional. The system should force the agent to inspect the blast radius before editing.

Third, architectural graphs may become part of AI readiness. Companies already document APIs, service ownership, and deployment pipelines. If coding agents are allowed to modify real systems, the machine-readable dependency graph becomes part of the control surface.

That does not mean every firm should immediately build Neo4j-backed coding-agent infrastructure. A five-person team working on a small monolith may get enough benefit from good tests, code search, and human review. But for mature codebases with layered architecture, dependency injection, shared base classes, generated clients, and cross-team ownership boundaries, the paper points to a real infrastructure gap.

The agent cannot respect architecture it cannot see.

The boundary conditions are not footnotes; they define the use case

The paper’s limitations are important because they keep the result in the right box.

First, the benchmark uses one Python FastAPI application. The codebase is realistic enough to contain architectural dependencies, but it is not evidence that the same magnitude holds across Java monoliths, TypeScript frontends, C++ systems, data pipelines, or polyglot microservice estates.

Second, ACS is about file coverage, not implementation correctness. This is not a patch-success benchmark. The result says the graph condition is much better at touching the right files in hidden-dependency tasks. It does not say the final code is necessarily correct, tested, secure, or maintainable.

Third, the graph is built from static AST analysis. That captures imports, inheritance, and instantiation, but production architecture also includes runtime configuration, dependency injection containers, database schemas, message queues, feature flags, ownership rules, and deployment boundaries. Some of those relationships are invisible to AST parsing.

Fourth, the findings are model- and workflow-sensitive. All trials use a particular agent setup. Different models may exhibit different search habits, different willingness to use tools, and different responses to prompt placement.

These limitations do not weaken the paper’s core mechanism. They specify where the result should be applied: repository-level tasks where hidden dependency relevance is structurally determined and where missing a connected file creates implementation risk.

That is a narrower claim than “graphs fix coding agents.”

It is also a more useful claim.

The practical framework: choose the navigation method by dependency type

A simple deployment framework follows from the paper.

The key is not to worship graphs. The key is to stop pretending every code-navigation problem is a search problem.

Retrieval finds likely documents. Navigation traces consequences.

A strong coding-agent platform should do both, but it should know when each one is being asked the wrong question.

Bigger windows change the economics, not the logic

Large context windows are still useful. They reduce friction. They let agents hold more code, documentation, logs, and task history at once. They make some retrieval failures less catastrophic.

But they do not make attention omniscient.

As repositories grow, the number of potentially relevant files increases faster than a task description can name them. Even if every file technically fits into context, the agent still needs a reason to attend to the right subset. Without structural guidance, “the whole repo fits” becomes less of a solution and more of a very expensive way to hide the needle inside a larger haystack.

The paper’s best contribution is therefore conceptual. It gives teams a better diagnostic question.

Not:

Can the model see enough?

But:

Does the system force the model to navigate the structure that determines relevance?

That question changes how we evaluate coding agents. It shifts attention from token budget to dependency awareness, from retrieval quality to workflow discipline, from demo success to operational reliability.

The next generation of coding-agent infrastructure may not be defined by who can stuff the largest repository into a context window. It may be defined by who can make the model look at the right architectural neighbors before it touches the code.

Less glamorous than another million tokens, yes.

Also less likely to break production because the agent forgot where the object was instantiated.

Cognaptus: Automate the Present, Incubate the Future.