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.
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 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.
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 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
"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.
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.
This seems like the LLM is vastly overcomplicating things. My entire Neovim config is a single 500 line init.lua and this is enough for LSP to work.
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 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.
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.
I don't see why someone needs an LLM as an LSP when code is structured data.
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
"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.
Just painful to read.