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.
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.
No it is real. Fewer people are using full IDEs so they made a smart move. Take the piece out that is easy to use in other workflows, including coding agents, and charge money for it.
Personally Im having great success with an LSP in my coding agent. Great alternative for grep and sed.
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.
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.
Very cool. I hope this comes to other languages as well. I'd be happy to pay a subscription for JetBrains-level LSP quality for use in VSCode or other editors.
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
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 :)
The entire point of an LSP implementation is for it to be universal. If they just wanted VS Code plugins, they would just make a VS Code plugin. They have already made several. It wouldn't make any sense to pick the LSP protocol in particular if you were just going to deliberately break it with whatever 'safeguards' means. Neither would it make any sense to restrict it to VS Code even if it was proprietary. Losing IDEA licensors to VS Code isn't somehow better than losing licensors to Vim.
I would presume that's only true if all of the insight can be snuggled into JSON-RPC payloads. I'm thankful I don't know all the vocabulary and shapes in LSP in order to gauge the risk but I am aware of the "lowest common denominator" problem
RaphGL | 4 days ago
Huh?
Miaourt | 4 days ago
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
RaphGL | 4 days ago
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.
TheGreatGazebo | 4 days ago
AI bootlicking is a requirement in this day and age
st3fan | 4 days ago
No it is real. Fewer people are using full IDEs so they made a smart move. Take the piece out that is easy to use in other workflows, including coding agents, and charge money for it.
Personally Im having great success with an LSP in my coding agent. Great alternative for grep and sed.
jmmv | 4 days ago
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.
stip | 4 days ago
For someone who has shunned full-blown IDEs for a long time, what advanced features are we talking about here?
jmmv | 4 days ago
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.
Halkcyon | 4 days ago
Wow, this is a big change. I might actually be able to functionally use Kotlin now!
georgelesica | 4 days ago
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.
mattgreenrocks | 4 days ago
Very cool. I hope this comes to other languages as well. I'd be happy to pay a subscription for JetBrains-level LSP quality for use in VSCode or other editors.
mdaniel | 4 days ago
They've offered MCP into the IDE for a while, but you have to make yourself a
PreToolUsehook to stop the floating points from ignoring the "use the MCP of the editor" directive and doing grep, sed, and random shit insteadtravisgriggs | 4 days ago
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
RaphGL | 4 days ago
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.
darius-it | 4 days ago
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 :)
pie_flavor | 4 days ago
The engine has always been open-source. So is the langserver.
The entire point of an LSP implementation is for it to be universal. If they just wanted VS Code plugins, they would just make a VS Code plugin. They have already made several. It wouldn't make any sense to pick the LSP protocol in particular if you were just going to deliberately break it with whatever 'safeguards' means. Neither would it make any sense to restrict it to VS Code even if it was proprietary. Losing IDEA licensors to VS Code isn't somehow better than losing licensors to Vim.
st3fan | 4 days ago
Open standards always win?
mdaniel | 3 days ago
I would presume that's only true if all of the insight can be snuggled into JSON-RPC payloads. I'm thankful I don't know all the vocabulary and shapes in LSP in order to gauge the risk but I am aware of the "lowest common denominator" problem