How AI Coding Agents Find Code: Inside the Context-Rich Harness

Ask a room of developers why one AI coding agent feels sharp and another feels lost in the same repository, and most will guess "the better one uses a bigger model." A thesis gaining traction in July 2026 argues the opposite: the model is increasingly a fixed commodity, and the differentiator is the harness — the retrieval and context machinery wrapped around the model. The slogan making the rounds is blunt: "freeze the model, train the harness." This piece explains how AI coding agents find code inside a context-rich harness, and why that plumbing, not raw model size, is what makes an agent competent in a real codebase.

The thesis is showing up from several directions at once. Ars Technica made "the case for a context-rich AI coding harness" and argued we need to move beyond grep. JetBrains introduced Context, framing the problem as "repository intelligence for coding agents." And in a fireside chat with the Claude Code team, the practitioners building one of the most-used coding agents kept returning to context handling as the core craft — with the tool shipping rapid iterative releases to match. Synthesized, they describe the same shift: the interesting engineering has moved out of the model and into how you feed it.

What is a coding-agent "harness," and why does it matter more than the model?

A harness is everything between your request and the model's response: how the agent searches the repository, decides which files and symbols are relevant, ranks them, and packs the winners into a limited context window before the model ever generates a token. The model supplies reasoning; the harness supplies situational awareness.

Why does this dominate quality? Because a frontier model that can't see the relevant function will confidently write code against an API that doesn't exist, while a smaller model that is handed the right three files and their call sites will often produce a correct, idiomatic change. Context windows are large but not infinite, and — just as important — they are not free: stuffing everything in degrades attention and raises cost and latency. The scarce resource isn't tokens of model capability; it's getting the right tokens into the window. That is the harness's entire job, and it's why "freeze the model, train the harness" resonates.

Why isn't grep enough?

Grep (and its faster cousins) is fast, exact, and honest — which is also its ceiling. Lexical search finds the literal string you asked for. But in real repositories the code you need rarely announces itself by name:

• You search createUser, but the bug lives in the UserFactory that calls it, or in the middleware that wraps it three layers up.
• The symbol is imported under an alias, generated by a macro, or split across a base class and an override.
• You want "where is auth enforced," which is a concept, not a token — no single grep pattern captures it.

Grep also returns matches, not relevance. A search for a common helper can return 200 hits with no signal about which three matter. A harness that dumps all 200 into context is worse than one that returns nothing, because it crowds out the real answer. "Beyond grep" doesn't mean abandoning lexical search — it's fast and precise and stays in the toolbox — it means grep is one signal among several, not the whole strategy.

How does a context-rich harness actually find code?

Modern harnesses layer several retrieval strategies and then rank across them. Think of it as four cooperating stages.

1. Lexical search (the fast, exact layer)

Symbol and string search still does the heavy lifting for "find the exact identifier." It's cheap, deterministic, and great as a first pass and as a verifier for other layers' guesses.

2. Structural / repository intelligence (the AST layer)

This is what "repository intelligence" points at: parse the code into an abstract syntax tree and build a graph of real relationships — definitions, references, call graphs, imports, class hierarchies, ownership. Now "find code" becomes "follow the edges": jump from a function to its callers, from an override to its base, from a route to its handler. Structural understanding is what lets an agent expand from one seed file to the actually-connected neighborhood instead of a bag of name matches.

3. Semantic retrieval — and why naive embeddings fall short

Embeddings let you search by meaning ("where do we validate JWTs") rather than by token. Useful — but naive, off-the-shelf embedding search underperforms on code for concrete reasons:

• Chunking destroys structure. Splitting files into fixed-size windows can cut a function in half or strand a signature from its body, so the vector represents a fragment, not a unit of meaning.
• Prose embeddings misread code. Models tuned on natural language don't natively encode that two functions are call-connected or that a variable is the same symbol across files.
• Nearest-neighbor isn't relevance. Cosine similarity surfaces things that look related; it doesn't know which are load-bearing for this task.

That's why strong harnesses treat embeddings as one recall source to be re-ranked and cross-checked — often against the structural graph and lexical hits — rather than as the final answer.

4. Ranking and assembling the context

The last stage is the one users never see and feel the most: fuse the candidates from every layer, rank them by task relevance, and pack the budget. A good harness prefers a few high-signal units — the target function, its direct callers, the type it returns, the test that exercises it — over a large low-signal pile. It respects the context budget as a scarce resource and leaves room for the model to reason instead of just read.

What does "freeze the model, train the harness" mean in practice?

It's a statement about where the marginal engineering win lives. If you hold the model constant and invest in retrieval, chunking, structural indexing, and ranking, agent quality on real tasks keeps climbing — often more than a model upgrade would deliver, and at lower cost and latency. Practically, "training the harness" means:

• Iterating on retrieval and ranking, not prompts alone.
• Indexing the repo structurally, not just as text.
• Measuring the harness on whether the right context reached the window, not just on final answers.
• Treating context assembly as a product surface you tune, version, and regression-test — which is exactly what the rapid release cadence around leading coding agents reflects.

What this means if you're building or choosing a coding agent

If you're building one, spend your next unit of effort on the harness: better repository intelligence and ranking will usually beat swapping models. If you're choosing one, evaluate it on your codebase, not a demo repo — ask how it finds cross-file relationships, how it behaves in a large monorepo, and whether it surfaces the right few files or drowns you in matches. The model's benchmark score tells you less than how well it locates the code that matters.

This mirrors a pattern we've seen elsewhere in agent performance: the ceiling is usually execution, not raw intelligence — the same finding from our analysis in We tested 45,000 AI Agents — the bottleneck isn't intelligence, it's execution. A context-rich harness is the coding-agent version of solving the execution problem: give a capable model the right context, and it does capable work. Starve it, and no amount of model size saves the output.

The next time an agent nails a change across five files it was never pointed at, that's not a smarter model — it's a harness that found the code. That's the part worth getting right.