IntelliJ IDEA Goes LSP: Java and Kotlin Intelligence Comes to VS Code, Cursor, and Agentic Flows
12 points by cgrinds
12 points by cgrinds
It’s no secret that agentic development is changing how developers build software. As agents take on more and more of the implementation work, developers spend less and less time manually editing code.
For this manual work, they might only need a basic, narrow set of features that IDEs provide, like navigating to declarations, finding references, some simple code completion, or renaming.
These features are generally covered by the Language Server Protocol (LSP), which allows programming language support to be implemented once and then reused by any LSP-capable IDE or editor.
Huh?
Afaik you can instruct many "LLM harness", like Claude Code, to use the LSP for diagnostics. Somehow serving as a standarized output for "where's and what the issue is" I guess
My "huh?" comment was because this felt like them trying to justify why they're doing LSP (which kinda sounds like they're admitting defeat after trying to force kotlin into a no LSP Jetbrains only land for so long) while also trying to whitewash it with some bs about LLMs, at least that is how I read it. They could've just announced that they're releasing LSPs for Java and Kotlin and call it a day, they didn't need to do the already played out AI bootlicking + providing excuses for why they're pivoting to LSPs for these 2 languages.
This (needing only basic code navigation, debugging) is the exact feedback I'm getting from the developers I support at work about how they barely touch any advanced IDE features anymore. They also express how they want more LSP support (Java is a miss right now) so that "simpler" IDEs (ehem VSCode) can perform these tasks without needing full-blown IntelliJ.
For someone who has shunned full-blown IDEs for a long time, what advanced features are we talking about here?
I'm not an avid IDE user either, but back when I used IntelliJ, code auto-completion was excellent and the inline diagnostics were more comprehensive and helpful than what the compiler provided. Other people swear by the refactoring features or interactive debugging.
They're already letting you run Claude and others inside the IDE, so this goes the other direction, taking the IDE to where you're interacting with your agents. It's a little bittersweet for me, but I'm glad JetBrains is making moves to protect its business, it would be a shame to lose their amazing tools altogether.
They've offered MCP into the IDE for a while, but you have to make yourself a PreToolUse hook to stop the floating points from ignoring the "use the MCP of the editor" directive and doing grep, sed, and random shit instead
I'm confused by something. Perhaphs because I naively use LSPs, but don't do much in the way of LSP development. If JetBrains is LSP-ifying some of its offerings, why is it VSCode (and forks) that can use it? Why can't Zed use it? I thought the_whole_point of the LSP architecture was to detangle language specific actions from text editing IDEs?
Inquiring minds are curious. I could have asked an LLM this question probably. But I come here to interact with real people. :D
As long as you can start the language server and communicate with it, it doesn't matter which editors they officially support or ship extensions for.
The question is whether this is actually possible in practice considering this extension seems to be closed source, so we don't know how exactly it's communicating with the language server.
I wouldn't be surprised if they added some safeguards (on top of the standard LSP) to prevent people from extracting the underlying IntelliJ engine for standalone use, since that's such a vital part of their products.
Feel free to prove me wrong though, would be neat if this worked in any LSP-compatible editor :)