A short new post on agent tooling makes a familiar but uncomfortable point for anyone building coding assistants: the most capable tool is not always the one the model will actually use.
The essay, “Grep beats LSP? Why coding agents ignore your fancier tools,” compares plain-text search with LSP-backed semantic navigation across code-finding and editing tasks. Its central claim is not that grep is technically superior in every sense. Rather, it argues that a tool’s usefulness to an agent depends on more than raw capability. The model has to choose it correctly, call it cleanly, and understand the result without getting lost in tool chatter.
That framing matters because agent builders often assume better metadata, richer structure or deeper semantics should automatically improve performance. The post says the reality is messier. Search tools that are obvious, predictable and cheap to invoke can win because they fit how models behave under time pressure. A command like grep gives an immediate, narrow answer. A semantic query can provide more context, but it may also introduce indirection, ambiguous ranking and overhead that slows the whole workflow.
The author says the result is that coding agents may ignore elegant interfaces in favor of blunt ones. In practice, that means developers optimizing for automation need to treat tool design as a usability problem for machines, not just a capability problem for humans. If a model must parse large responses, reconcile multiple abstractions or infer too much about repository structure, it may waste effort even when the underlying tool is better on paper.
That insight should resonate with teams building code assistants, repo bots and internal developer tooling. Many systems are designed around the assumption that more structure is always better. But if the consumer is an LLM, structure only helps when it is easy to discover and easy to exploit. A search primitive that always returns a small, stable result set may outperform a sophisticated navigator that requires additional prompting, extra parsing or careful result ranking.
The post also hints at a deeper lesson about agent evaluation. Benchmarks that reward fancy tools can overstate their usefulness if the agent cannot reliably pick those tools in real work. In other words, the true metric is not only whether a tool can solve a task. It is whether a model can consistently select it, use it and act on the output without drift. That is a separate layer of product design.
For practitioners, the takeaway is practical rather than ideological. Grep is not better because it is old. It is better in some workflows because it is direct, legible and hard to misuse. Semantic search and LSP-powered navigation still matter, especially for broad code understanding and refactoring. But an agent stack that ignores the ergonomics of invocation may spend a lot of engineering effort on tools that look smart and still lose to the simplest option in everyday use.
That makes the post less a celebration of old-school Unix and more a reminder that agent tooling has to be judged by how it behaves inside the loop. The best tool is the one the model reaches for correctly, repeatedly and with the least friction. Sometimes that is grep.
