Grep beats LSP? Why coding agents ignore your fancier tools

We’ve also collaborated on some Python tooling that takes a rather slow data format that I often have to process and analyze, indexed the whole corpus, and for analysis I can do (or Claude Code can) a single-pass conversion to Parquet which is then queryable with DuckDB. That tool has dramatically improved my turnaround time on one-off analysis tasks and as a Python CLI tool using Typer, the interface is also nicely discoverable for LLM harnesses to work with.

https://github.com/theduke/smartedit

With the skill installed GPT 5.6 usually automatically uses it, and it reduces code exploration time and token usage significantly, for example by just printing the types and functions in a file without bodies, and only expanding when needed.

(note: it also has editing functionality, which doesn't work so well, since the models are heavily tilted towards common editing tools in post training)

What's interesting is observing how much work this takes. (it gives me much more empathy toward my past self; how was a clumsy human supposed to know and reason about these things!?, especially when I hadn't touched the configs since a few months prior and had forgotten them almost entirely).

Most often there's 10-20 very small programs all working together to give the desired experience. The amount of minutes and tokens required to solve these seemingly simple problems like "My LSP isn't working" is sometimes much more than expected.

(a) The LSP's tools being competently built & consistent, and

(b) the LLM using it having been properly trained to use LSPs in general.

Using a native tool like grep has the same 2 assumptions, but

(a) is satisfied due to ossification of grep's core features (a good thing), and

(b) is extra-satisfied because the LLM can be trained to properly use grep specifically, and not "20th variation of grep wrapped behind an LSP, but just different enough to throw curveballs".

On top of that, grep is almost always present in default Linux environments, so its presence is assumed & can be relied upon when needed.

"Training support is a hypothesis consistent with these results, not something this study proves."

I understand it, but I find the wording very unnatural. To improve readability I would have written it in the active form:

"We cannot prove training explains this result, but this fits the data best."

LSP works best when using dependencies that are already compiled locally, but if all source is available, yeah... I still don't have a solid answer on which one is best.

But again, for already compiled dependencies (think Java bytecode), without LSP configs, the agent is likely going to attempt to extract binaries from JAR files, use grep and javap, and potentially attempt to decompile the .class files.

There’s no reason why you couldn’t write a search tool that e.g combines LSP and grep. Or ast-grep, for that matter. It feels like one of those things we haven’t spent much time investigating because grep is good enough

Just painful to read.