Live data from Hacker News

Claude Code gets native LSP support

github.com

191–200 of 352 posts

Re: Claude Code gets native LSP support

#195

I really can't understand why JetBrains hasn't integrated its refactoring tools into the AI system. Really missed the boat on making their platform transformational for AI coding. Imagine how much smaller the context would be for a tool that renames a function than editing hundreds of files. This LSP support is a good start but without the mutation functions it is still pretty lackluster. Plus LSPs aren't as good as…

Jetbrains seems a bit lost these days. Look at that very recent screw up [0]. I thought about moving after 10+ years when they abandoned the commit modal, and jacked up the plan prices, but I barely understand how to commit things in Vscode anyway. Let's see in 2026. [0] https://blog.jetbrains.com/datagrip/2025/12/18/query-console...

I have been leaning towards Zed.

Re: Claude Code gets native LSP support

#196
post #104

Earlier quoted context omitted.

> This is why we're seeing the bulk of gains from things like MCP and, now, "agents". This is objectively not true. The models have improved a ton (with data from "tools" and "agentic loops", but it's still the models that become more capable). Check out [1] a 100 LoC "LLM in a loop with just terminal access", it is now above last year's heavily harnessed SotA. > Gemini 3 Pro reaches 74% on SWE-bench verified with mi…

I don't understand. You're highlighting a project that implements an "agent" as a counterargument to my claim that the bulk of improvements are from "agents"? Sure, the models themselves have improved, but not by the same margins from a couple of years ago. E.g. the jump from GPT-3 to GPT-4 was far greater than the jump from GPT-4 to GPT-5. Currently we're seeing moderate improvements between each release, with "agen…

They're pointing out that the "agent" is just 100 lines of code with a single tool. That means the model itself has improved, since such a bare bones agent is little more than invoking the model in a loop.

Re: Claude Code gets native LSP support

#197

I really can't understand why JetBrains hasn't integrated its refactoring tools into the AI system. Really missed the boat on making their platform transformational for AI coding. Imagine how much smaller the context would be for a tool that renames a function than editing hundreds of files. This LSP support is a good start but without the mutation functions it is still pretty lackluster. Plus LSPs aren't as good as…

I am trying my damn hardest to drop jetbrains, the only thing they have a stronglehold over is their amazing rust analyzer in rustrover. And yah I agree that they are dropping the ball on providing actual intellisense to AI tools, like why not? It's probably less than 10 lines of code.

Re: Claude Code gets native LSP support

#198
post #126
post #85

Earlier quoted context omitted.

I completely agree. Likewise I'm amazed Microsoft hasn't done it themselves for Roslyn and Copilot. Roslyn analyzers are so incredibly powerful, and it's being ignored. An explainer for others: Not only can analyzers act as basic linters, but transformations are built right in to them. Every time claude does search-and-replace to add a parameter I want to cry a little, this has been a solved science. Agents + Roslyn…

In a similar vein, I really struggle to understand why copilot is so crap when writing SQL and I'm connected to the database. The database has so much context (schema names, column names, constraints etc.) yet copilot regularly hallucinates the most basic stuff like table and column names, which standard auto complete has managed fine for the last 20+ years.

No one is interested to solve hard problems. The broad industry got lucky with LLMs and everyone is now blindly burning capital at this. If you think they can't be that stupid remember the covid super hiring frenzy.

Re: Claude Code gets native LSP support

#200

Earlier quoted context omitted.

They are trying now to create an agent-first IDE. I think they are too big to move on this. https://blog.jetbrains.com/fleet/2025/12/the-future-of-fleet...

>Over time, we learned that having two general-purpose IDE families created confusion and diluted our focus. And not the dozens of others you have? Do you not consider them also separate families? Yeah, they completely didn’t see any of this coming.

All the other IDEs they have are variants of IDEA.

Fleet is a completely different codebase.

So they’re correct, there’s only two families of IDEs.

Post reply on HN