Source code as primary context for coding agents

Coding agents should inspect source code directly and use deterministic search for retrieval rather than relying on generated documentation, according to a blog post published August 24, 2026. The post argues that AI-generated knowledge bases act as caches that become stale as code changes, and that CPUs are better suited for indexing and retrieval tasks while GPUs should be reserved for model reasoning. The author recommends using grep and exact search over semantic search for code retrieval.

Back to blog /blog/ August 24, 2026 · 5 min read Source code as primary context for coding agents Coding agents should inspect source code directly, use deterministic search for retrieval, and reserve model reasoning for understanding and decisions. There is a mismatch in how people talk about autonomous coding agents and how they talk about context. We increasingly expect coding agents to work independently for hours, make non-trivial changes and operate across large software projects. At the same time, much of the context discussion still revolves around documentation, web search and increasingly elaborate AI-generated knowledge bases. For humans, detailed documentation is valuable because reading and understanding unfamiliar code is cognitively expensive. I do not think the same model transfers particularly well to agents. Generated documentation is a cache A common approach is effectively: code → GPU-generated description of the code → coding agent That creates a derived representation of information that already exists in the source. Some information is inevitably lost in the transformation, generating it costs GPU time, and the result has to stay synchronized with the implementation. In other words, you have built a cache. The old joke about the hard problems in computer science being naming things and cache invalidation applies unusually well here. If you generate deep documentation or a knowledge base from source code, cache invalidation becomes part of the architecture almost by construction. Every meaningful code change potentially invalidates some portion of that generated representation. You can regenerate aggressively, track dependencies between generated chunks and source files, invalidate selectively and build increasingly sophisticated update pipelines, but at that point you are spending engineering effort and GPU time maintaining a cache for a consumer that is perfectly capable of reading the source itself. That is also a poor division of labor between GPUs and CPUs. GPUs are useful when you actually need model reasoning. Searching for symbols, finding references, traversing files, resolving imports, grepping for literals and retrieving exact source locations are not primarily reasoning problems. They are indexing and retrieval problems, and CPUs are extremely good at them. If you can move a large part of context acquisition into deterministic search and navigation, you reserve the expensive model calls for the parts where they add value: understanding the retrieved code, forming hypotheses, deciding what to inspect next and making changes. The tradeoff gets worse as agents write a larger share of the code. The faster the implementation changes, the shorter the useful lifetime of any generated description of it. Creating and maintaining deep prose representations of implementation details is hard to justify when the agent can inspect the current implementation directly. There is also an important difference between retrieving documentation and retrieving code. Semantic search is a very good fit for English prose. Documentation can describe the same concept in many different ways, and neither the human nor the agent necessarily knows the exact terminology used in the document. Matching on meaning is useful in that environment. Code is a much more constrained dialect. Identifiers, types, imports, function calls, literals and file structure provide strong lexical and structural signals. Once the agent has established roughly what it is looking for, grep and other exact forms of search are often simply better than semantic search. If the question is where a method is called, which implementation handles a type, where a configuration value is read, how an interface is implemented or how a dependency is instantiated, I want the agent to search and navigate the actual code. I do not want it reasoning from something that happens to be semantically similar to an implementation that existed when the documentation knowledge base was generated. Semantic search still has a place in code when the problem is genuinely fuzzy, particularly during early exploration when the agent does not yet know the relevant terminology or subsystem. But a large part of software engineering is not fuzzy retrieval. Once the relevant concept has been identified, the task becomes finding the exact implementation, following references, inspecting usages and verifying assumptions against concrete source. Documentation is useful at the right level None of this means documentation is useless. Documentation is useful when it contains information that cannot simply be recovered from the implementation. High-level architecture, design intent, invariants, conventions, architectural decisions, operational constraints and pointers to important parts of the system are all useful. They tell the agent why something exists, what constraints shaped the design, what assumptions should hold and where to begin looking. That is very different from generating prose that attempts to reproduce the implementation. Even good documentation should not be the final authority when correctness matters. If documentation says that an API behaves in a particular way, the agent still needs to inspect the implementation, types, tests and actual call sites before depending on that assumption. Documentation tells it how the system is intended to work. The source tells it what the software currently does. This distinction becomes more important as agents become more autonomous. If we are going to let an agent modify software without continuous human supervision, it needs to verify its assumptions against primary evidence rather than reason primarily from derived descriptions of that evidence. I do not think the answer to better coding-agent context is to generate increasingly detailed prose about code for agents to consume. Give them the high-level information that the source cannot provide, move search and navigation onto cheap deterministic infrastructure where possible, and spend GPU time on the parts that actually require reasoning.