Agent Code Intelligence

Talk to us

grep -rn "recognize" . && read every hit

Industry research

What is code intelligence?

Revision: October 2026

Code intelligence is a layer between a coding agent and your code that already knows the answers. Ask it where something lives, what calls it, or what a dependency expects, and it returns the location instead of leaving the agent to read files until it finds out.

For a small project the difference is a few seconds. For a two-million-line system, a few hundred repositories, or a dependency tree nobody has fully read, it is the difference between an agent that can do the work and one that cannot.

Why it matters Compare the tools

What it is

A way to ask, not another grep.

An agent with no help rediscovers the repository on every task. It guesses at an identifier, greps for it, reads whole files to find one function, and rebuilds a picture of how the parts fit together. Then the session ends and the next one starts over.

Code intelligence puts something between the agent and the code that already holds the answer: an index to search, a language server to query, a graph to traverse, a documentation corpus to cite. The agent asks a question and gets a location back, which is a far smaller thing to carry than the files it would otherwise have read.

The question does not have to stop at code you wrote. Most of what a repository actually runs is dependencies: installed, vendored, or never on disk at all. The same question put to an index covers them: what a call expects, where it is used here, and what the library itself says about it.

one question, two ways
# without: guess the name, then read to find out
$ grep -rn "recognize" .
$ sed -n '1,400p' service/recognition.js
# ...and again next session

# with: ask, and get the location back
references("recognize")
  features/recognize.js:15
  service/recognition.js:42

Four kinds of answer

No single tool gives all four. Each family answers a different question, and a serious setup usually runs more than one.

Loading families…

Why an enterprise needs it

Your codebase is bigger than any context window.

A coding agent can only reason about what is in front of it, and what is in front of it is a context window: large, but finite, and paid for by the token. Everything an agent reads to find its bearings is spent before the work starts. On a small project that cost is lost in the noise. On the systems an enterprise actually runs, it is the whole budget.

Millions of lines, written over decades

The people who knew the whole system have moved on, and no one alive has read all of it. An agent dropped into it has the same problem a new hire does, except it forgets everything at the end of each session. Grep returns thousands of hits across every era of the code. Code intelligence returns the handful that matter for this change, ranked, before anything is read into context.

What to require: retrieval that ranks before it reads, and an index that persists between sessions.

Hundreds of repositories, one change

A shared library changes its contract. Which services call it? The honest answer in a poly-repo estate is that nobody knows for certain, because the callers live in repositories nobody here has cloned. An agent working in one checkout cannot see the others at all. Code intelligence that spans the estate answers in one query, and names the repositories a person would have had to think to look in.

What to require: one query across repositories, not one index per checkout.

Tens to hundreds of dependencies

Most of what a repository runs is code it did not write. Some of it is installed and readable. Some is a binary, a service, or a closed library with nothing on disk but a signature. An agent asked what a call expects answers from memory of a version it may not be looking at. Code intelligence indexes the dependency's own source or published documentation, and answers with the passage that says so.

What to require: dependencies searched as readily as your own source, with the citation attached.

The cost of going without

Four bills you are already paying.

None of these show up as a line item. They show up as agent runs that cost more than they should, changes that ship incomplete, and a team that stops trusting what the agent says about the code.

Tokens spent reading, not working

Every file read into the window is paid for, on every task, in every session. Most of it was read to find something, not to change it.

Rediscovery every session

An agent starts cold. Whatever it worked out about how the system fits together is gone when the session ends, and the next one pays to learn it again.

Call sites nobody found

A change that touches repositories nobody opened ships without them. The failure arrives later, in production, with the context long gone.

Guessed dependency APIs

With no source on disk, an agent answers from its training data: a version of the library it may not be looking at, with an argument that no longer exists.

Who is asking

The questions an agent cannot answer alone.

The same gap shows up for different people in different words. Each row names someone who asks the question, what they cannot get answered today, and what a tool has to do about it.

A developerNew to a two-million-line repository

Which handful of these files matter for the change I have been given?

Retrieval that ranks before anything is read into context.

A tech leadShipping a change across many repositories

Have we caught every place this is used, including repositories nobody here has opened?

One query that spans repositories, not one index per checkout.

A coding agentStarting cold, as it does every session

What did the last session work out about how this fits together?

An index that persists and refreshes on merge, rather than a grep from cold.

An engineerCalling a dependency whose source is not on disk

What does this call expect, when there is nothing to read?

An answer from published documentation, with the citation attached.

A platform or FinOps leadPaying for the tokens

What is the agent's context costing per task, and would a tool lower it?

A measured reduction against the bare agent, not a claim.

The tools themselves are well travelled in the local LLM community, where one person runs one index on one machine. An enterprise adds everything that setting never had to answer: who is allowed to query it, where it is hosted, what refreshes it when main moves, and who pays for the embeddings. That is what this research is about.

This library

What this comparison is for

Every tool is scored against the same requirement set, so they can be compared on the same questions instead of on their own marketing. Each answer carries its reasoning and its sources on that tool's own page. Derived scores are marked, and a row nobody has verified says unknown and states what would settle it.

It does not pick a winner. Fit depends on your languages, your hosting, and which requirements you refuse to trade. Scores come from published documentation unless a note says a lab run produced them.

Loading research…

Go deeper

Where to start

Loading the site map…