RAG vs Full Context for Coding Agents

Two ways to supply repository evidence

Retrieval-augmented generation, usually called RAG, finds relevant material when a task needs it. A full-context strategy tries to place a much larger body of repository text into one model request. Both can help coding agents. Retrieval can be cheaper and fresher for a narrow bug, while broad context can help when several modules interact. Neither method removes the need to decide what evidence matters.

The comparison often becomes exaggerated. A retrieval system can miss a hidden dependency, and a large prompt can bury it under unrelated files. Good coding tools combine a structural map, targeted reads and the ability to expand context as the investigation changes. Evaluate the resulting patch and tests rather than treating one architecture as a universal winner.

A bug example makes the distinction clear

Suppose a checkout request fails only for one payment method. A retrieval-first agent can search the error, read the route, validation contract and related test, then follow the call to the provider adapter. This sends a relatively small evidence set to the model. A broad-context agent may load every payment file and test at once. That could reveal a relationship the search missed, but it may also introduce older fixtures and similarly named code that distracts from the failing path.

The best next step depends on the evidence. If the targeted test points to one branch, retrieval is efficient. If the failure depends on a cross-cutting schema change, broaden the view. A capable agent should be able to move between these modes rather than committing to one before it knows the problem.

Retrieval failure modes

Keyword search can miss aliases, generated names or dynamically registered handlers. Embedding search can return semantically similar code that is not on the runtime path. An index may lag behind the current branch. A code lens may infer static callers without proving execution order. These are reasons to treat retrieved results as leads and open current source files. Tests and runtime wiring provide stronger confirmation than a search ranking alone.

When the agent cannot find a dependency, ask it what it searched and why. Add the missing symbol, route or test as a clue. Do not solve every retrieval failure by pasting the entire repository into the next prompt. Improve the evidence path in a way that can be repeated.

Broad-context failure modes

A wide window can fit more files, but it can also hold contradictions: current source beside generated copies, deprecated APIs and stale documentation. The model may rely on the wrong version. Long prompts cost more, run slower and can be hard for a human to audit. If the system truncates material to stay within limits, it is still performing selection, sometimes invisibly. A full dump also risks including sensitive files unrelated to the task.

Organize broad context when it is warranted. Give a map of packages, the public interface, key callers and tests, with clear file paths and revisions. Ask the agent to identify uncertainty rather than making a sweeping patch from the first reading. Even a large window benefits from deliberate structure.

Hybrid strategies are usually practical

Start with a compact repository map and the most relevant failing evidence. Retrieve precise files as hypotheses form. Broaden context for a design change or when targeted search cannot explain an observed result. After editing, use tests and typechecks as fresh context. Re-read the current files before a second patch if another process could have modified them. This balances relevance and completeness.

Licuse's on-demand inspection tools support selective reads, while its local episode history can offer earlier task clues. Those historical clues still need current-code verification. Other agents use their own search and indexing. The user should be able to see enough file references and check results to judge whether the evidence was sound.

How to evaluate the approaches

Use a repository issue with both a clear failing test and a hidden dependency. Run it with two tools or configurations. Record which files they read, whether they found the hidden dependency, how many tokens or tool calls they used, and the quality of the final tested patch. Deliberately include a misleading similarly named function to see whether the agent validates its search result. A method that is fast on an easy task may fail on this more realistic case.

Compare cost per correct change, not just prompt length. Retrieval that repeatedly misses the right file can be expensive. A broad prompt that succeeds once may be worthwhile for a rare complex migration. The engineering goal is a transparent path from evidence to verified code.

A data-boundary difference

Retrieval can also limit which source code enters a remote request. If the agent needs only one module, a targeted read avoids transmitting unrelated confidential files. That does not make retrieval automatically private: the selected excerpt still reaches the model, and search indexes or external tools may have their own data paths. A broad-context approach may send more code than a task requires. Teams should compare the exact processing route, retention terms and exclusion controls, not just token cost. For sensitive repositories, make the context selection visible and require review when an agent expands beyond the expected files. Record the reason for that expansion, because a broad read can be legitimate for an architectural task but unnecessary for a one-line bug. This makes privacy and engineering decisions easier to audit later.