Grounding beats prompting: give a coding agent the right context

When a coding agent gets something wrong, the reflex is to write a longer prompt. Add another rule. Paste in more of the repository. Spell out the edge case it missed. It feels like progress, and it almost never works. Past a certain point, a bigger prompt makes the agent worse, not better.

The lever that actually moves reliability is not instruction. It is context: the right slice of the codebase, in front of the agent at the moment it needs it. That is grounding, and for real work on real code, grounding beats prompting every time. This guide is about how to get the context for AI coding agents right, and why "more" is the wrong axis to optimize.

Why a bigger prompt is not more context

There is a quiet assumption behind the paste-more-code instinct: that the model's understanding scales with the number of tokens you give it. It does not. More tokens is more to read, and most of what you paste is noise relative to the change at hand.

Two things go wrong when you flood the window. First, cost. Long inputs are not free, and output tokens usually cost several times more than input, so verbose context makes every iteration more expensive without buying accuracy. Second, attention. Models do not weigh every token evenly. The research on this is direct: Liu et al., in "Lost in the Middle" (Transactions of the ACL, 2023), showed that models reliably use information at the start and end of a long context while struggling to use the same information buried in the middle. The relevant three lines you needed can be technically present and functionally invisible.

So a wall of pasted code is the worst of both worlds. It costs more and it can bury the signal. What you want is not volume. It is the smallest set of context that actually contains the answer.

What "the right context" actually means

For a specific change, the right codebase context is a short list, not a repository dump:

• The files the change touches. The modules where the work actually lands.
• The contracts it depends on. The interfaces, types, and function signatures the change calls into, so the agent writes against reality instead of guessing shapes.
• The conventions and tests for that area. Tests encode intent better than most prose. The local patterns tell the agent how code here is supposed to look.

Notice what is not on the list: the other four hundred files. A payment change does not need the email templates. A retry fix in one service does not need the entire monorepo. Grounding coding agents well is an exercise in leaving things out.

How to give a coding agent better context

Here is the practical sequence, from the least effort to the most durable.

1. Scope to the change first. Before the agent writes anything, figure out which files and modules the task involves. This is the single highest-leverage step, because everything downstream inherits from it. If you scope wrong, no amount of prompting recovers.

2. Include contracts, not whole implementations. The agent rarely needs the full body of a function it calls. It needs the signature, the types, and the expected behavior. Feeding interfaces instead of implementations keeps the context small and points the agent at the boundaries that matter.

3. Bring the tests and the local conventions. The tests for the area under change are the closest thing you have to an executable specification. Handing them to the agent gives it a definition of done it can reason about, not just a description.

4. Prefer retrieval over paste. Manually pasting context does not scale and goes stale the moment the code changes. Retrieval, selecting relevant files by symbol, by dependency, or by similarity at the time of the task, keeps the context both small and current. Retrieval-augmented generation is the general version of this idea, and it is worth understanding where it helps and where it does not before you lean on it. (See RAG for code.)

5. Keep the stable part stable, and cache it. Some context repeats across many calls: coding conventions, key interfaces, the shape of the system. If that block stays byte-for-byte stable, prompt caching charges the repeated prefix at a steep discount instead of full price on every call. Small, relevant, and stable context is not only more accurate. It is dramatically cheaper. The discipline of deciding what the agent sees on each call, and in what order, is its own skill. (See context engineering for coding agents.)

The cost angle people skip

Grounding is usually framed as an accuracy technique, and it is. But it is also the cheapest reliability upgrade available, because the two goals point the same way.

A smaller, well-chosen context means fewer input tokens per run. A stable prefix means most of those tokens are cached and billed at a fraction of the rate. And a more accurate first attempt means fewer expensive iterations to fix a wrong one. You do not usually trade cost for quality here. Better grounding lowers both at once, which is rare enough to be worth saying plainly.

The honest limitation

Grounding raises the ceiling on how reliable an agent can be. It does not remove the floor of verification.

The failure mode is simple: if the retrieval step misses the file that mattered, the agent is now grounded in the wrong slice, and it will proceed confidently in the wrong direction. Garbage context in, garbage plan out, delivered with total fluency. Better grounding makes this rarer, but it never makes it impossible, because no relevance heuristic is perfect.

That is why grounding is necessary but not sufficient. It has to sit inside a loop that checks the agent's output against reality, tests, deterministic checks, and a human at the decisions that carry consequences. Context makes the agent more likely to be right. It does not earn the right to skip confirming that it was.

This is the principle underneath how reliable AI coding agents are built, and it is the approach we took with Loopsfinity: agents work from the relevant slice of your actual codebase rather than a wall of pasted text, and a human still approves what ships. Not because grounding is weak, but because context is what makes an agent worth trusting, and verification is what confirms the trust was warranted.