For a long time, choosing an IDE meant choosing much more than the window where you wrote code. You were also choosing the language support, navigation, refactoring, debugging and project understanding that came with it.

That relationship is beginning to change.

AI-assisted and agentic development already means that not every line of code is written manually in an editor. Developers may ask an agent to implement part of a feature, switch back to the code to investigate a problem, review the resulting changes, run tests and debug unexpected behaviour. In that kind of workflow, the question is no longer simply which editor is best. It is also about what understands the software underneath it.

The release of Java and Kotlin by IntelliJ IDEA 1.0 for VS Code and Cursor is an interesting sign of that shift. JetBrains is taking a focused set of the Java and Kotlin intelligence developed for IntelliJ IDEA and making it available outside IntelliJ IDEA itself.

The more interesting story is what that separation could mean for how developers choose and combine their tools.

Code intelligence and the editor are starting to separate

Java and Kotlin by IntelliJ IDEA uses the Language Server Protocol, or LSP, to bring Java and Kotlin support to VS Code-based environments. The first stable release includes capabilities such as code analysis, completion, navigation, refactoring, build-tool support, testing and debugging.

Those features are familiar. What is less familiar is where they are running.

The underlying Java and Kotlin language technology comes from IntelliJ IDEA, but developers can now use a focused set of that technology while working in Cursor or VS Code. In other words, the editing surface and the source of language intelligence no longer have to be the same product.

That points towards a more modular development environment. An editor can be one choice. An AI agent can be another. The language and project intelligence behind them can be another again.

AI makes code understanding more important, not less

Much of the discussion around coding agents focuses on generation: how well can an agent create a function, fix an error or implement a feature?

But generating code is only one part of software development.

A change also has to make sense inside an existing application. Developers need to understand where symbols are used, how types relate, what a refactoring might affect, whether an inspection has identified a real problem and why something fails at runtime. Mature codebases carry years of structure, dependencies and assumptions that cannot be reduced to the few files immediately visible in an editor.

This becomes particularly important when a developer did not construct every change manually.

When we write code ourselves, some understanding is built up simply through the act of writing it. With agent-generated changes, developers may arrive at the review stage without having followed every intermediate decision. The need for navigation, analysis, inspections, testing and debugging does not disappear. In some workflows, it may become even more important.

That shifts attention from the ability to produce code towards the ability to understand and verify it.

The distinction matters. An AI model can reason about the code and context it has been given, while language tooling can provide structured information about the project itself. Bringing those two forms of assistance closer together could give agents another way to inspect what they are changing rather than relying only on text passed into their context.

JetBrains says direct LSP access by agents is planned for a future release. It is also experimenting with LSP- and debugger-backed intelligence for terminal-based agents such as Claude Code and Codex. Those capabilities should therefore be viewed as direction rather than something generally available in the 1.0 release today.

The development stack is becoming more modular

Developers have rarely agreed on a single preferred way to work, and AI is multiplying the available combinations.

One developer may prefer Cursor and another VS Code. A team may use several AI assistants depending on the task. Developers may also use agents in the terminal as well as in the editor.

A more modular tooling stack makes it possible to separate some of those choices. Java and Kotlin by IntelliJ IDEA is a useful example: a developer can choose a VS Code-based environment while still using Java and Kotlin language technology originating from IntelliJ IDEA.

The same IntelliJ IDEA Ultimate subscription covers those Java and Kotlin capabilities across IntelliJ IDEA itself and supported VS Code-based environments.

That does not mean every tool becomes interchangeable. IntelliJ IDEA remains a much broader development environment than the focused feature set exposed through the extension. But it does mean that choosing an editor does not necessarily have to determine every layer underneath it.

For engineering teams, that creates a more useful question than simply whether everyone should use the same tool: which parts of the development environment actually need to be consistent?

The answer may be the build process, testing, inspections, debugging, quality gates or the way AI-generated changes are reviewed. The editor itself may not always need to be part of that list.

The IDE is becoming more than the place where code is typed

None of this suggests that the IDE is disappearing. In fact, the opposite may be happening.

As some of the act of writing code moves to agents, the value of an IDE increasingly includes everything around that act: understanding the project, navigating it, detecting problems, refactoring safely, running tests and debugging behaviour.

By making some of IntelliJ IDEA’s Java and Kotlin intelligence available outside the IntelliJ IDEA application, JetBrains is showing that those capabilities do not necessarily have to remain tied to a single interface.

That is a more interesting development than simply adding Java and Kotlin support to another editor.

The development environment is becoming a collection of interoperating tools, with humans and agents moving between them. In that environment, the editor a developer chooses will still matter. But the intelligence that helps everyone understand what they are changing may matter even more.