LSP instead of grep: a coding agent should not read a repository blind

Grep is not bad. For text search, logs, configuration, or a quick “where does this string occur?”, it is exactly the right tool. But for a coding agent working across a larger repository, it often solves the wrong problem.
An agent usually does not need matching characters. It needs to know what a symbol means, where it is defined, who uses it, and what can safely change in a refactor. That is the difference between text search and semantic navigation through the Language Server Protocol (LSP).
In AI Mastermind 34, Jirka Herník showed two branches of the same task: rename one property and identify exactly what needs to change. In that specific demonstration, the grep branch spent minutes working through files, while the LSP branch received references directly. The result was the same. The 81× number from the video is not a universal benchmark. It is a useful illustration of the mechanism: the real saving is not that LSP “replaces grep”, but that the model does not spend time and tokens reconstructing context the IDE already has.
What Jirka’s demo actually showed
The screenshot compares two full agent runs for the same instruction: “list exactly what must change when renaming JournalEntry.Amount.” This is not a microbenchmark of grep itself. Grep found candidates quickly, but the agent then had to read and evaluate files. LSP returned symbol references in one step.
| Demo metric | grep branch | LSP branch |
|---|---|---|
| Time from prompt to result | 7 min 20 sec | 5.4 sec |
| Tool calls | 54 | 1 |
| Files read | 20+ | 0 |
| Tokens processed by the model | 12,868,604 | about 2,000 |
| New non-cache tokens | 392,599 | about 250 |
| Result | correct | correct |
The time ratio is roughly 81×. It is not a performance promise for Serena, Claude Code, or LSP in general. This is one demonstration where the task was nearly ideal for a symbol-reference query. For changes across dynamic code, templates, SQL, configuration, or an external API, the gap will be smaller—and grep may remain indispensable.
How to verify the numbers in your own repository
For a fair comparison, use the same task, model, context limit, and starting branch in both runs. Record door-to-door time, tool calls, files read, cached and new tokens, the diff, and test results. Then do not turn “grep versus LSP” into an article of faith: measure the median across at least five runs for each task class.
For a company, the most useful row is new non-cache tokens. Cached tokens still have cost and latency, but newly processed context is the clearest signal of how much unnecessary repository reading the agent has actually eliminated.
What LSP actually gives an agent
The Language Server Protocol is a standard between an editor and a tool that understands a particular programming language. A language server can locate a symbol definition, references, implementations, and diagnostics.
That is the layer behind “go to definition” and controlled symbol rename in an IDE. When a coding agent receives the same layer through MCP, it no longer has to imitate an IDE with grep, globs, and incremental file reading.
The useful questions change:
- Where is this field declared?
- Which symbols reference it?
- Is an occurrence merely the same text with a different meaning?
- Which change is a rename, and which one changes an API or database contract?
This matters in TypeScript, Java, C#, Python, or PHP projects, where the same string can be in a class, DTO, validator, SQL migration, test, documentation, and frontend. Grep finds all of them. Semantic navigation can distinguish which are actual references to the programming symbol.
Why grep costs an agent more than a developer
An experienced developer reads grep results quickly. They know the architecture, jump between definitions in the editor, and spot false matches. An agent has to rebuild that mental model from text, one tool call at a time.
That costs tokens, latency, and reliability. The agent reads irrelevant fragments, spends extra steps searching and deciding, and a text-based replace can easily modify a comment, another same-named symbol, or only a partial contract.
On a small file this is negligible. In a monorepo, a long task, or parallel subagents, it becomes an operating cost and a source of mistakes. LSP is therefore more important than another prompt trick: it changes the input the model uses to decide.
Serena makes LSP practical for an agent
Serena is an open-source MCP toolkit for coding agents. On top of language servers it offers symbol search, file overview, references, definitions, and tools for editing and refactoring. Its capabilities still depend on the quality of the language server for a given language.
Serena is not a model and it does not replace tests. It exposes semantic information that the model would otherwise have to reconstruct. The agent still plans a change, edits code, and runs tests. It simply does not start blind.
That is also a useful pattern for internal AI tooling. Do not give the model the whole repository first. Give it controlled tools that answer precise structural questions: symbol, references, diagnostics, test, diff. Then decide, by project sensitivity, which tools can run automatically.
Where LSP does not help
LSP is not a universal shortcut. Grep is still better for text in Markdown, documentation, templates, and configuration; logs and unknown identifiers; regular expressions and ad-hoc investigation; and languages or builds without a working language server.
A symbol reference also cannot decide the product impact of a change. Renaming an entity may require a database migration, an API update, analytics review, client regeneration, or coordination with another team. LSP says where in code. It does not say what is right for the product.
A small rollout worth measuring
Do not give every agent full refactoring access. Run a short pilot in one repository:
- Pick recurring tasks: rename, call-site discovery, DTO changes, module split.
- Measure tool calls, files read, time to the first correct plan, and time to green tests.
- Compare search-only runs with LSP/MCP runs.
- Require diff, tests, and human review for broader changes.
- Keep read-only navigation separate from code-changing and shell tools.
The lesson is simple: a coding agent does not need to search for code meaning through text when a language server can return it as a structured fact. LSP does not remove the need for grep. It gives the agent navigation by symbols and relationships, reducing the cost and uncertainty of larger changes.
Sources
- YouTube: Jirka Herník — AI Mastermind 34
- Microsoft: Language Server Protocol
- Serena: The IDE for Your Coding Agent