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