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

Jetbrainz needs to give up on Junie and their in house ai and focus on integrating with the established tools. If they don’t, VS code will consume them.

When you become complacent and your ego isn’t checked, you think you have the hottest thing. Hubris is hard. They had a pretty big moat that they let vscode eat away at. I don’t think they saw any of this coming and are struggling to make sense of it.

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 would be productive like little else. Imagine an agent as an orchestrator but manipulation through commands to an API that maintains guard rails and compilability.

Claude is already capable of writing roslyn analyzers, and roslyn has an API for implementing code transformations ( so called "quick fixes" ), so they already are out there in library form.

It's hard to describe them to anyone who hasn't used a similarly powerful system, but essentially it enables transforms that go way beyond simple find/replace. You get accurate transformations that can be quite complex and deep reworks to the code itself.

A simple example would be transforming a foreach loop into a for loop, or transforming and optimizing linq statements.

And yet we find these tools unused with agentic find/replace doing the heavy lifting instead.

Whichever AI company solves LSP and compiler based deep refactoring will see their utility shoot through the roof for working with large codebases.

I think they are completely screwing up the AI integration.

After years of JetBrains PyCharm pro I'm seriously considering switch to cursor. Before supermaven being acquired, pycharm+supermaven was feeling like having superpowers ... i really wish they will manage to somehow catch up, otherwise the path is written: crisis, being acquired by some big corp, enshitification.

there is a jetbrains MCP server that gives Claude Code access to this sort of thing, but I think its still fairly jank and bloats context.

They wanted to, but they’re still waiting for the IDE itself to simply load.

People keep saying how amazing IntelliJ is at refactoring, but then you realize the talk about "rename thing" and "extract function".

This is 5% of what refactoring is, the rest is big scale re-architecting code where these tools are useless.

The agents can do this big scale architecturing if you describe exactly what you want.

IntelliJ has no moat here, because they can do well 5% of what refactoring is.

Are you having a positive experience with Codex compared to Claude Code? Codex in my brief experience was... not good w/ 5.1

Interesting to see that you work at OpenAI but had to build a skill like this yourself.

Surprised that you don't have internal tools or skills that could do this already!

Shows how much more work there is still to be done in this space.

Yeah, I posted here because I was completely blindsided when my claude asked if I wanted to install a go lsp. I didnt even know that was a thing. A little googling led to this changelog from 3 days ago, but I was surprised I hadnt seen any previous mentions of this online (from either creators, anthropic, or HN posts).

I am disabling it for now since my flow is fine at the moment, I'll let others validate the usefulness first.

I am on the latest version of Claude Code and nothing comes up when I follow this and search for "mcp". Looks like this feature is quite undercooked at the moment. I'm hoping for a more straightforward way to enable this and ensure the LSP is being used by Claude in the future.

If you want to add custom lsps, they need to be wrapped in a Claude code plugin which is where the little bit of actual documentation can be found https://code.claude.com/docs/en/plugins-reference

Thanks! I saw typescript-lsp in the plugins list, but I wasn't sure if that was related.

Have you figured out what triggers it?

I must be doing something wrong, because I can't get OpenCode to actually do anything useful, and not for lack of trying. Claude code gets me great results instantly, opencode (if I can't make it talk to a model, which isn't easy for Gemini) gets me… something, but it's nowhere near as useful as claude code. I don't know why there is so much difference, because theoretically there shouldn't be. Is it the prompt that Anthropic has been polishing in Claude code for so long?

I do like OpenCode, but I get small bugs here and there like flickering, freezing and sometimes just crash all together.

But their configuration setup is the easiest and best out of all the other CLI tools

You can move quite fast when you don't have to spend half a week persuading 7 stakeholders that something is worth doing, then spend a week arguing about sprint capacity and roadmap disruptions.

tbf, OpenCode's development cycle seems pretty fast. If someone announced AGI in the morning, I'd bet they have it integrated by EOD.

I also use OpenCode extensively, but bounce around to test out the other ones.

i'm not sure i agree with the assessment that claude code has been moving slowly... but it is cool that opencode has had this for a while. will def check it out

IDEs have LSP support because they have a plugin that connects to an LSP server. The plugin is a very small piece of code compared to the language server. Creating a new client is not reinventing the wheel. In fact the entire philosophy of LSP is: one server to many different clients.

CLIs can also have a small piece of code that connects to an LSP server. I don’t see why IDEs should be the sole beneficiary of LSP just because they were the first clients imagined by the LSP creators.

I just saw a video of non-technical person describing how they use claude code to automate various workflows. They actually tried vscode and then the desktop gui.

Yet they preferred the CLI because it felt "more natural"

With agents, and Claude Code, we are *orchestrating* ... this is an unresolved UI/UX in industry. The same reasons `kubectl` didn't evolve to GUI probably apply here.

It's less about the codebase, more about the ability to conduct anything on the computer - you are closest to that in the terminal. https://backnotprop.com/blog/its-on-your-computer/

Well my editor is in the terminal, so is my chatbot. I dont really want to change to an IDE to use a desktop app and a chatbot that both have half-baked UIs trying to complement each other.

What IDE agent gets access to LSP?

I use Zed and unless there is some MCP server that provides the same thing as the LSP server, the Zed agent won't have access, even though it's in an IDE that supposedly has this information

For many of us, the plus of the CLI form factor is it doesn't tie us to a particular IDE.

You could use a CLI frontend for LSP, e.g. https://github.com/valentjn/lsp-cli

But why would that be better than LLMs using the LSP with a dedicated tool rather than a shell command tool?

it's likely been on their mind for _a while_

those wanting lsp support in the loop have been using things such as: https://github.com/oraios/serena

Did it make no difference when you mentioned in your AGENT.md which LSP servers are installed?

Yes, you can do this with hooks: https://code.claude.com/docs/en/hooks

Depends on your installation method. I have CC installed on macOS with `bun install` and it self-updates. But you could have different results with, oh, npm or yarn or homebrew or nix or probably asdfvm or maybe there’s a native .pkg I don’t know about or…you get the idea.

I have the same issue since for ever (and update by hand because of it). I always assumed it is because it gets confused by me using Volta for node/npm version management and Volta‘s shim masking where Claude Code is globally installed.

Yeah, I uninstalled and reinstalled with homebrew, and it’s working well now.

Always have a lot of sessions running locally and don’t recall this

Uninstall it and install it via home brew fixed it for me.

A big use case will be to tell the LLM what the type of an expression is.

It's a shame that my company tied itself to claude-code way too fast. It was like a single week last summer of, "oh what's everyone's favorite? claude? okay, let's go!"

OpenCode has been truely innovating in this space and is actually open source, and would naturally fit into custom corporate LLM proxies. Yet, now we've built so many unrulely wrappers and tools around claude-code's proprietary binary just to sandbox it, and use it with our proxy, that now I fear it's too late to walk back.

Not sure how OpenCode can break through this barrier, but I'm an internal advocate for it. For hobby projects, it's definitely my goto tool.

OpenCode is so underrated.

One of my favorite features is that you can run it as a server, and then it has a API and SDKs to manage sessions etc.

Great to build a centrally managed agent for your team.

I believe it’s to do with supporting shift+enter (to do multiline prompts).

https://github.com/anthropics/claude-code/issues/1259#issuec...

Every once in a while it runs 'sudo rm -rf /'.

I came here just to say that. The commit history on that changelog blew me away.

There's pyright-lsp. Isn't this a Python LSP ? or is it lacking important features ?

It's the protocol that VSC made to speak to programs that do code analysis and is the basis of goto definition, autocomplete, refactorings etc.

It's used by most smaller editors so they can backpack off of the efforts languages make to be usable in VSC. (Vim, Emacs, Zed, etc)

As part of a bigger refactor, you want to rename some variables. With an LSP hook, the LLM can make the change (more) reliably.

The LLM wants to see the definition of a function. More reliable than grepping.

The same reason you want an LSP in your editor: so you get inline docs and error messages, autocomplete, jump to definition, refactoring actions etc.

Your test suite and linter don't code. They don't help your agent look up definitions of variables, etc.