IntelliJ IDEA 2026.2 EAP tests AI without dropping control

JetBrains opened the IntelliJ IDEA 2026.2 EAP with deeper agent hooks, better debugging visibility, dependency completion, migration tooling, and early pla

2026-05-27 GIGATAP Team #security
#IntelliJ IDEA#JetBrains#Developer Tools

Source: JetBrains Blog — https://blog.jetbrains.com/idea/2026/05/intellij-idea-2026-2-eap/

IntelliJ IDEA 2026.2 EAP is open#

JetBrains has opened the Early Access Program for IntelliJ IDEA 2026.2. The first EAP builds are available through the JetBrains Toolbox App, from the IntelliJ IDEA website, and as a Snap for Ubuntu. As usual, the EAP builds are free until the final release ships.

The useful signal is not just that a new EAP cycle started. JetBrains is describing the release around a specific balance: AI-assisted development is getting deeper IDE access, while classic manual workflows are not being pushed aside.

That matters because IDE vendors are no longer adding AI as a side panel. They are wiring agents into editing, terminals, debugging, build files, and runtime inspection. IntelliJ IDEA 2026.2 appears to follow that direction, but with a strong emphasis on keeping the developer in the review loop.

AI moves closer to the code and debugger#

JetBrains says it is working on several AI-focused changes for this cycle: improved next edit suggestions, AI-powered full method generation, and more IDE knowledge exposed through MCP.

The method-generation flow is the clearest example. When a developer calls a method that does not exist yet, IntelliJ IDEA’s AI will be able to offer both the signature stub and a full implementation body. JetBrains frames this as an extension of an existing flow, not a separate “generate an app” mode.

That distinction matters. The IDE is being used as the control surface. The AI proposes code in the place where the missing method is already visible, and the developer still has to understand what lands in the project.

MCP support is also expanding. JetBrains says MCP will expose more debugging capabilities to agents, including the ability to set breakpoints and the newly introduced logpoints. If this lands as described, agents will not only edit code. They will be able to participate in runtime investigation inside the IDE’s debugging model.

Logpoints are a practical target for that. JetBrains describes them as a cleaner version of the old “println debugger”: add runtime expressions during a debugging session without suspending execution, recompiling, or leaving temporary print statements behind. The AI angle is that the IDE can help place logpoints with expressions relevant to the investigation.

The risk is not hard to see. More agent access means more places where wrong assumptions can become workflow friction. The upside is equally clear: if the IDE keeps the debugging context visible and reviewable, agent assistance can reduce mechanical work without hiding the execution path.

The terminal is being shaped for coding agents#

JetBrains also points to the CLI agent shift. Coding agents are no longer limited to chat panels or IDE plugins; many now run in terminals. IntelliJ IDEA’s built-in terminal is being adjusted for that reality.

The planned changes include drag-and-drop file paths, image pasting when talking to a CLI coding agent, and access to the project’s JDK without manual PATH setup.

These are not dramatic features on their own. They are workflow glue. But workflow glue is where agent tools often fail. If the terminal cannot easily reference project files, accept visual context, or use the same Java environment as the IDE, the developer ends up maintaining two parallel workspaces: one for the IDE and one for the agent.

JetBrains is trying to make the terminal feel like part of the project model, not a detached shell. For Java and Kotlin teams, the project JDK detail may be the most useful part. It removes a class of avoidable setup errors where the agent or CLI command runs under a different Java environment than the project expects.

Classic workflows still get real work#

The 2026.2 EAP is not only an AI release. JetBrains is also working on dependency completion, database migration tooling, framework visibility, and language/platform support.

Build script dependency completion is being revamped. In dependency sections, the IDE is expected to offer completion only where it is relevant: artifact coordinates, scopes, and versions. JetBrains says this will use both local cache data and server-side knowledge.

That is a small but important quality-of-life change. Bad completion in build files is worse than no completion, because it creates noise in one of the most sensitive parts of a project. Dependency coordinates, scopes, and versions affect build reproducibility, transitive risk, and deployment behavior. Completion needs to be narrow and correct.

Flyway and Liquibase are also being pulled closer into the normal IDE workflow. JetBrains says developers will be able to run migrations from the same context menu and data source view used elsewhere in the IDE, with dedicated run configurations for each tool.

This is useful because database migration work often sits awkwardly between application code, staging fixes, and operational state. Keeping migrations inside the IDE’s existing context can reduce switching cost, especially when spinning up a module or repairing a broken staging state.

More visibility into what the app is doing#

JetBrains is also emphasizing runtime understanding. That is the right counterweight to AI-generated or AI-assisted code.

The editor is expected to show security indicators next to endpoints, including which roles unlock them. For Spring and similar backend projects, this could reduce the gap between reading a controller method and understanding whether it is actually protected.

This is not a replacement for security review. It is a visibility layer. Its value depends on how accurately IntelliJ IDEA can map framework configuration, annotations, and runtime rules into a readable signal. But even a partial view can help catch obvious mistakes earlier, especially in large codebases where endpoint authorization is spread across annotations, config, and conventions.

JetBrains is also working on a Hibernate-focused feature that shows the SQL or HQL Hibernate is about to issue. The planned workflow includes jumping from a query to the Kotlin or Java line that triggered it, and running the query in the application’s own configuration.

That is the kind of feature that solves a real debugging question: where did this query come from? ORM behavior is often hard to inspect because the source code expresses object access while the database sees generated queries. A direct bridge between query and source line can make performance and correctness work less dependent on guesswork.

Platform support and Kotlin/Spring work continue#

JetBrains says IntelliJ IDEA 2026.2 will include early support for Java 27, Kotlin 2.4.x updates, and Gradle 10. The source post does not provide detailed compatibility notes, so this should be treated as release-cycle direction rather than a complete support matrix.

Kotlin in Spring projects is another focus. After Kotlin and JPA improvements in 2026.1, JetBrains says it is continuing work on Kotlin-aware diagnostics, data class interop, and smoother migration from existing Java/Spring codebases to Kotlin.

That is a credible place to spend engineering time. Kotlin adoption in Spring projects often breaks down less on syntax and more on framework edge cases: nullability, proxies, data classes, persistence behavior, and diagnostics that still think in Java-first assumptions.

JetBrains also says it is continuing general performance and quality work: freezes, bugs, and resource consumption. No specific metrics are given in the source post, so there is nothing to verify yet beyond the stated intent.

What to check before using the EAP#

EAP builds are useful for teams that want early visibility into workflow changes. They are not the same thing as a stable release.

A practical checklist:

  • Try the EAP on a non-critical project first.
  • Check AI-assisted generation against your normal review standards.
  • Test terminal behavior if your team uses CLI coding agents.
  • Validate dependency completion in real Gradle or Maven build files before trusting it.
  • Review endpoint security indicators against known protected and unprotected routes.
  • If using Hibernate, test whether query-to-code navigation works on the patterns your project actually uses.
  • Report bugs through JetBrains’ issue tracker or feedback channels while the EAP is still shaping the release.

The important theme is control. IntelliJ IDEA 2026.2 is moving agents deeper into the IDE, but the stronger parts of the announcement are the ones that make code easier to inspect: logpoints, endpoint indicators, dependency-aware completion, migration run configurations, and query tracing.

If those features land cleanly, the release could make AI assistance less like a detached code generator and more like another layer inside the developer’s existing tools. That is the version worth testing.