For years, choosing a development environment also meant choosing much of the intelligence that came with it.

Code navigation, completion, inspections and refactoring lived inside the IDE. If you moved to another editor, you often changed not just the interface, but also how deeply your tooling understood the code.

The Language Server Protocol changed some of that by creating a standard way for editors to communicate with language-aware tooling.

Now JetBrains is taking an interesting step in that direction.

IntelliJ IDEA’s Java and Kotlin intelligence is available in preview through an LSP-based extension for VS Code and VS Code-based editors such as Cursor.

At first glance, that sounds like a story about editor choice.

Look a little further, though, and it points towards something bigger – language intelligence is becoming useful beyond the IDE itself, particularly as AI agents take on more development work.

First, what exactly is LSP?

Traditionally, an editor or IDE needed its own implementation of language-specific features.

The Language Server Protocol separates some of that language intelligence from the interface developers use to write code.

An editor can ask a language server questions such as where a symbol is defined, which references point to it or what completion options are available. The language server understands the code and sends the answer back in a standardised format.

That means language support can potentially be implemented once and consumed by different LSP-compatible tools.

And those consumers no longer have to be just editors.

IntelliJ intelligence is becoming portable

JetBrains’ new Java & Kotlin by IntelliJ IDEA extension brings a focused set of IntelliJ IDEA’s Java and Kotlin capabilities to VS Code and its forks.

During the preview, it supports Java, Kotlin and mixed-language projects, alongside smart completion, navigation, code analysis, refactoring and editor assistance. Debugging is supported through DAP, while Maven, Gradle and Bazel projects are supported as well.

The significance isn’t simply that someone can now write Java in VS Code with technology from JetBrains.

It is where the intelligence is coming from.

JetBrains has long positioned IntelliJ IDEA around deep code understanding rather than treating the IDE as simply an editor with language-specific plugins. Its current partner materials similarly emphasise code understanding, reliable refactoring, integrated debugging and support for complex Java and Kotlin development.

Some of that intelligence can now serve developers outside the IntelliJ IDEA interface.

Image 1. Java & Kotlin by IntelliJ IDEA brings a focused set of IntelliJ IDEA language capabilities to VS Code-based development environments.

Does that make the IDE less important?

It might seem like an unusual move for an IDE vendor.

If developers can access IntelliJ language intelligence from another editor, why use IntelliJ IDEA itself?

The distinction is between language intelligence and the complete development environment around it.

LSP can make capabilities such as navigation, analysis and completion portable. That does not mean every part of an IDE becomes interchangeable.

JetBrains’ own campaign positioning makes that distinction particularly clear. IntelliJ IDEA is positioned as an environment for professional Java and Kotlin development that combines code understanding with debugging, refactoring, framework support and AI assistance. For developers, JetBrains emphasises coding, navigation, debugging, refactoring and fewer interruptions. For organisations, it focuses on maintainability, software quality, onboarding and delivery.

In other words, making some IntelliJ intelligence available through LSP does not reproduce IntelliJ IDEA somewhere else.

It makes that intelligence available to more consumers.

And one particular type of consumer makes this announcement considerably more interesting.

AI agents need to understand code too

An AI coding agent can explore a repository by reading files, searching for strings and reasoning about what it finds.

But consider the kinds of questions that arise when changing a real codebase:

Where is this method declared?

What references it?

What type does this expression resolve to?

Where is an interface implemented?

What else could be affected by renaming this symbol?

An IDE already has structured knowledge that can help answer questions like these.

Give an AI agent access to language intelligence and it potentially has another way to understand the codebase – one based on structured program information rather than repeatedly discovering everything through source files and model reasoning.

JetBrains explicitly identifies this as part of its direction for the technology. The company says it has been experimenting internally and with selected external customers using the same LSP functionality in terminal-based agentic workflows, including Claude Code and Codex.

JetBrains says the initial results are promising and points specifically towards faster, more deterministic agent behaviour and potentially reduced token consumption. However, the company has not yet published those experimental results, so there are no figures we can use to quantify the improvement today.

That distinction matters.

The potential is interesting. The evidence is still to come.

Less exploration, more useful context

If those experiments bear out, the implications go beyond a faster coding assistant.

AI agents consume resources while exploring a codebase. Every file they need to inspect and every additional step needed to establish relationships between parts of a project adds context and potentially more model interactions.

Language tooling already maintains a structured understanding of many of those relationships.

Giving agents access to that information could change the division of labour.

The model does not necessarily need to infer something that development tooling already knows.

That becomes particularly interesting in the kind of environments JetBrains highlights in its IntelliJ IDEA positioning – large codebases, complex frameworks and production Java and Kotlin projects.

As projects become more complex, understanding the code may become just as important to an agent as generating it.

AI changes the role of development tooling – it doesn’t remove it

There is a broader point here.

AI is becoming increasingly capable of producing code. That does not eliminate the need for navigation, analysis, validation, debugging and refactoring.

Arguably, it makes those capabilities more important.

JetBrains makes a similar point in its current IntelliJ IDEA campaign – AI may generate code quickly, but production development still requires teams to understand, validate, debug and maintain what has been created.

The difference is that developers may no longer be the only ones using the tools that provide that understanding.

An IDE traditionally helped a developer understand a codebase.

An LSP server can provide some of that understanding to multiple editors.

Now the same type of intelligence could increasingly help AI agents understand the code they are being asked to change.

That is a much more interesting evolution than simply adding another editor extension.

What can developers try today?

The Java & Kotlin by IntelliJ IDEA extension is currently in preview and is available through the Visual Studio Marketplace and Open VSX Registry.

During the preview, the extension is free to use. JetBrains says each build renews the evaluation period, which is limited to 30 days. After the preview period, the extension will require an IntelliJ IDEA Ultimate subscription.

There is also an important distinction for Kotlin developers.

JetBrains continues to develop the separate Kotlin LSP for pure Kotlin projects. That project is Apache 2.0 licensed and can be used for free. It is not the same offering as the new Java & Kotlin by IntelliJ IDEA extension.

The interesting part may still be ahead

VS Code and Cursor are the first visible destinations for IntelliJ IDEA’s LSP-based language intelligence.

They may not be the most consequential ones.

JetBrains has already said that fully agentic, terminal-based workflows are next on its roadmap and that it intends to share results from its early experiments, including its findings around token consumption.

That is what we will be watching.

Because the bigger change may not be that IntelliJ IDEA intelligence can now appear in another editor.

It may be that the intelligence once built primarily to help developers understand code is becoming infrastructure that both developers and AI agents can use.

And as agentic development matures, that distinction could matter a great deal.