Grep beats LSP? Why coding agents ignore your fancier tools

There’s been an interesting co-evolution that I’ve been experiencing with Claude Code. I’ll ask it to do a task, I’ll watch what it’s doing (often lots of find and grep and ripgrep) and then after the task is complete I’ll ask it if there are any tools that would’ve made the job easier. This has led to tools like fzf and others (notmuch for indexing email, for example). I’ve then taken those tools and figured out how to work them into my own workflow, both CLI and Emacs.

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.

Tangental, but my LSP config breaks every few months. I don't bother to fix it anymore, I open an LLM in ~/dotfiles and complain until it works again, usually in a few minutes.

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.

At the end of the first paragraph there is this sentence:

"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."

Just a few days ago I was pondering why an Emacs like environment that provides such powerful tools to examine and manipulate texts is not being used more prominently than say VSCode where you need to be build many features or use plugins or rely on system utilities.

What has worked well for me is to have a SKILL that instructs to use the LSP more often than not.

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.

This has not been my experience at all.

This article presents some evidence for why Grep might work better but I don’t think it does a great job of explaining why it gets chosen - is it something that was intentionally reinforced during training or was it just because LSP is harder to train on because it’s usually hidden behind some IDE interface

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

I don't see why someone needs an LLM as an LSP when code is structured data.

It is astonishing how easy it is to see the AI hand at work in the writing. Really, it is almost impossible not to see. I don’t get how these people feel it is appropriate to pass off slop like this and not even bother to edit it.

Just painful to read.