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.
I wonder if you put job classifications along a spreadsheet's leftmost column (e.g. search in file, search in directory), and data types along a spreadsheet's topmost row (e.g. JSON file, macOS-based filesystem), would you end up finding gaps in the intersection of the columns and rows make these new tools you've created less surprising? For example, to "search a file" on a "macOS-based filesystem", you would naturally gravitate towards `grep`. Or to search the contents of a JSON file, you would maybe use `grep`, or perhaps `jq` and a well crafted query. Well, as you expand out the job classifications and data types (or some other abstraction), you start to realize where we don't have tools today. And then Claude can go and create those, perhaps even proposing a faster alternative!
When you use “we” hopefully you are referring to someone on your team. Just be careful, the first step down the rabbit hole of AI psychosis is humanization of LLM.
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)
Interesting tool, it seems that dedicated skills for these tools are important. Even explicit system-prompt instructions—such as “you must use tool X for code exploration”—often fail to behave as expected.
Another tricky part is that how to evaluate customized toolsets properly and ensure they continue to work perfectly as the underlying model/harness evolves.
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.
I have the exact same anecdote; it makes me wonder if this is a common enough use case that a small language model could be trained and run locally for these kinds of “configuration bullshit problems”.
I feel like a very large percentage of my Claude usage ends up having it automate configuration shit, because historically that has been the part of software engineering I have always hated.
I bet if you look back, you were using a lot less effort in the past than what you see the LLM doing now. They are pretty bad at taking a straight line to the solution.
I’ve had good results with JetBrains AiChat in that really integrates in their IDEs - you can see it using ide tools and i generally found it spends less time thrashing about compared to Claude.
Setting up an LSP relies on 2 requirements to properly work:
(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.
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.
As a guy who started in lisp I always find LSP to be a weird uncanny valley situation. It's like 99% of a REPL, but it will always have corner cases where that 1% difference is important.
TBH I frequently have a hard time getting Claude to use LSP at all. I'm not sure if it just breaks or what. It's like 10 items down on my list of random crap to figure out eventually.
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.
Which language and agent? I used Aider on a Python project which had string references (as opposed to module tree) and cross-repo references. LSP lookups were fast and I hated it when Aider used 2M tokens a day, but grep was more complete.
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 am thinking of where the initial training data came from. For example, Claude Code likely collected a substantial number of real-world coding trajectories through its CLI. However, trajectories involving tools such as LSP, MCP, or AST-grep were probably scarce in the dataset.
This lack of representation may also indirectly limit the effectiveness of subsequently generated synthetic data.
"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"
that's also my doubt, it's much easier to train with grep while only a fraction of project can setup LSP properly.
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.
The author is not a native speaker. The research topic and methodology are manual, along with the first draft of the article, but he eventually did use AI to make the writing "better". It is either this or grammatical slips here and there, which may annoy the same group of people even more.
Do you seriously read the article and not see that it is extremely low signal-to-noise? And full of non-sequiturs and strange unnecessary clarifications? And passed off as a research project.
“Claude, write an article about why agents use grep instead of LSP”
This would have saved everyone the pain of reading this.
As another user pointed out: “Training support is a hypothesis consistent with these results, not something this study proves.” is not a sentence a human would write, nor is it a sentence that a human should ever be made to read. I apologize for reproducing it; the article is chock full of these “gems”.
100%. This article is written by AI. The problem is it makes you doubt the whole thing: Did the person behind this do any work at all? Or is this just content marketing for an AI project - something that used to require time and effort - but now can be done by anyone with a click on a button.
Too bad. Because this is sort of an interesting subject.
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)
Another tricky part is that how to evaluate customized toolsets properly and ensure they continue to work perfectly as the underlying model/harness evolves.
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.
I feel like a very large percentage of my Claude usage ends up having it automate configuration shit, because historically that has been the part of software engineering I have always hated.
I also have been using the same LSP config for approximately 7 years.
I don't get the pain.
(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
This lack of representation may also indirectly limit the effectiveness of subsequently generated synthetic data.
that's also my doubt, it's much easier to train with grep while only a fraction of project can setup LSP properly.
Just painful to read.
Hope this clarifies things.
> Avoid generic tangents.
> Please don't post shallow dismissals
> Please don't complain about tangential annoyances—e.g. article or website formats, name collisions, or back-button breakage.
See: Hacker News Guidelines
I’ll point out you also violate this guideline.
Do you seriously read the article and not see that it is extremely low signal-to-noise? And full of non-sequiturs and strange unnecessary clarifications? And passed off as a research project.
“Claude, write an article about why agents use grep instead of LSP”
This would have saved everyone the pain of reading this.
As another user pointed out: “Training support is a hypothesis consistent with these results, not something this study proves.” is not a sentence a human would write, nor is it a sentence that a human should ever be made to read. I apologize for reproducing it; the article is chock full of these “gems”.
Too bad. Because this is sort of an interesting subject.
Try to remain civil, even when you have Big Feelings.