For about as long as AI coding agents have existed, the JetBrains crowd has watched from the sidelines. The interesting tools shipped as VS Code forks or VS Code extensions, and IntelliJ users got a plugin that felt a step behind — useful autocomplete, a chat panel, but nothing that touched the part of the IDE that actually makes IntelliJ worth its weight: the index. JetBrains IDEs are not text editors with plugins bolted on. They are semantic models of your code, and that model is the whole point. An agent that ignores it is leaving the best tool on the table.
Junie is JetBrains' answer. It is a native AI coding agent built into the IntelliJ family — IntelliJ IDEA, PyCharm, WebStorm, GoLand, and the rest — and the pitch is that it does not treat your project as a folder of text files. It reads the same index the IDE uses for navigation and refactoring, runs your existing run configurations to check its own work, and executes multi-step tasks while you approve each meaningful move. I spent two weeks running it as my primary agent inside IntelliJ IDEA on a large Kotlin service, with a few side trips into PyCharm, to find out whether the deep integration is a marketing line or a genuine advantage. The short version: on the right codebase, it is genuinely different. On the wrong one, you are paying for IDE weight you do not need.
What "native" actually buys you
The word native gets thrown around loosely, so it is worth being concrete about what Junie reuses. When you give it a task, it is not grepping your repository and guessing. It queries the IntelliJ index — the same data structure that powers Find Usages, Go to Definition, and the rename refactor that has never once broken my build in fifteen years of using this IDE. That means when Junie decides to change a method signature, it can see every caller the way the IDE sees them, not the way a regex would.
In practice this showed up most clearly on cross-module changes. I asked it to thread a new parameter through a service that had perhaps forty call sites spread across several Gradle modules. A grep-based agent tends to get the obvious ones and miss the call buried in a test helper or behind an overload. Junie found them because the index found them. It also leaned on the IDE's refactoring engine rather than hand-editing text — when it renamed something, it used the actual rename machinery, which is structurally aware of scope and shadowing. The result was the kind of change I would have made myself, not a pile of near-misses I had to clean up.
The second piece is run configurations. Junie can execute the run and test configurations you already have set up, which means it can write a change, run the relevant test target, read the failure, and iterate — inside the IDE, against the toolchain you actually use. On a JVM project where "does it compile" and "does it pass" are non-trivial questions involving Gradle, annotation processors, and a slow cold start, having the agent drive your real configurations instead of guessing at a shell command is a meaningful reliability gain.
JVM codebases lean hard on things that are invisible to text-level tools: interface implementations resolved at runtime, dependency injection wiring, generated code from annotation processors, and method overloads that differ only by parameter type. An agent reading raw text cannot reliably reason about any of these. An agent reading the IntelliJ index can, because the index has already resolved them. This is the single biggest reason Junie outperforms generic agents on large Java and Kotlin projects specifically — and why the gap narrows on a small Python script where there is little structure to resolve.
Junie versus the old AI Assistant plugin
If you have used JetBrains IDEs recently, you have already met the AI Assistant — the chat-and-completion plugin that JetBrains shipped first. It is easy to conflate the two, and JetBrains has not always made the distinction crisp, but they are different things doing different jobs.
AI Assistant is the conversational and inline layer: code completion, a chat panel for questions, explain-this-code, generate-a-commit-message, the small assists you invoke dozens of times a day. Junie is the agent: you hand it a task in plain language, and it plans, edits multiple files, runs tests, and reports back. AI Assistant answers; Junie does. In my workflow they ended up complementary rather than competing — I kept AI Assistant's completion on for the typing-speed gains and reached for Junie when I had a discrete task I wanted executed end to end rather than a question I wanted answered.
The practical implication is subscription overlap, which I will come back to, and a slight learning curve in knowing which tool to reach for. Early on I tried to use Junie for things that were really just questions, which is overkill — spinning up an agent run to ask "what does this function do" wastes both time and quota. Once the division of labor clicked, the two felt like a coherent pair rather than two products competing for the same panel.
Living with multi-step execution and the approval flow
Junie runs as an agent with a human in the loop. You describe the goal, it proposes a plan, and as it works it pauses at the points that matter — before applying edits, before running commands — so you can approve, adjust, or stop. This is the right default for an agent that has hands on your codebase, and it is calmer than the fully autonomous "let it rip and review the diff later" model that some tools push.
Over two weeks the approval flow mostly stayed out of my way without feeling reckless. For small, well-scoped tasks I could approve in a rhythm and let it move. For larger ones I appreciated being able to catch a wrong turn at step two instead of unwinding a fifteen-file diff at the end. The flip side is that Junie is not a fire-and-forget tool — it wants your attention at the checkpoints, which is great for trust and less great if you wanted to kick off a long task and walk away. That is a deliberate design stance, not a bug, and I think it is the correct one for an agent wired this deeply into your project.
Where it struggled was the same place every agent struggles: ambiguous, sprawling tasks with no clear success signal. When I could point it at a failing test or a concrete acceptance check, it iterated toward green reliably because it could run the test itself. When the task was "improve the error handling in this module," it produced reasonable but unfocused work that needed direction. The lesson is not specific to Junie — give an agent a verifiable target — but Junie's ability to actually run that target is what makes the well-scoped case work so well.
Junie runs on the JetBrains AI subscription, which is quota-based rather than unlimited. The agent's multi-step runs — planning, editing, repeatedly running tests and reading output — consume more of that quota than a quick chat does, and on a heavy day of agent-driven work I noticed the budget drawing down faster than I expected. The exact limits and tiers shift over time and vary by plan, so check the current JetBrains AI pricing before committing, especially if you intend to run Junie as your main agent all day. Budget for more than the entry tier if agentic work is your core use.
Where it lags, and the IDE-weight tax
It would be dishonest to write this up as an unqualified win. Two things consistently reminded me I was paying a cost.
The first is IDE heaviness. IntelliJ is a powerful environment, and that power comes with weight — memory footprint, indexing time on a fresh checkout, a heavier startup than a lean editor. If you already run IntelliJ all day, Junie adds essentially no overhead because the IDE is the cost you have already paid; the agent is just using infrastructure that is sitting there anyway. But if you were drawn to AI agents through the lighter, faster world of editor-based tools, dropping into a full JetBrains IDE to get Junie will feel like a step backward in responsiveness. On my M-series MacBook the IDE itself was fine, but I am someone who lives in it. Coming from a feather-light setup, the contrast is real.
The second is raw agent polish against the newest dedicated tools. The category leaders have spent every cycle for a couple of years sanding down the agent loop — speed of response, fluidity of multi-file edits, the feel of the thing. Junie is good and improving quickly, but on pure agent ergonomics and latency it is not yet ahead of the best dedicated agents. What it trades that for is context quality. I will take a slightly less slick agent that understands my codebase over a faster one that guesses, on a large project — but on a small one, where there is little for the index to understand, that trade inverts and the speed gap is what you feel.
How Junie stacks up against Cursor and Copilot
The honest framing is not "is Junie the best agent" but "for whom is Junie the best agent." For developers committed to the IntelliJ family who do not want to leave their IDE, the comparison set is small and Junie wins it almost by default — because the alternative is bolting a less-integrated tool onto, or alongside, an IDE that was never built to host it.
Cursor is the tool most people mean when they say "the agent is just better." It is fast, the multi-file editing is fluid, and its repository understanding is genuinely strong. But Cursor is its own editor — adopting it means leaving IntelliJ, and for a developer whose productivity is built on JetBrains' navigation, refactoring, and debugging, that is not a small ask. You would be trading a deep, structural understanding of your code for a slicker agent loop. For some that trade is worth it. For a Kotlin team with a decade of muscle memory in IntelliJ, it usually is not.
Copilot is the pragmatic middle. It runs as a plugin inside JetBrains IDEs, so you do not have to leave, and its language coverage is broad. But running as a plugin is exactly the limitation — it does not get the same first-class access to the IntelliJ index that Junie, as a native JetBrains product, is built around. You get an agent in your IDE without the agent fully understanding your IDE's model of the code. That is a reasonable place to land if you are already deep in the GitHub ecosystem, but it concedes the specific advantage that makes Junie interesting.
Who should use Junie
Junie is an easy recommendation for one group and a harder one for everyone else. If you work in IntelliJ IDEA, PyCharm, GoLand, or another JetBrains IDE every day, on a substantial Java or Kotlin codebase, and you have no intention of leaving that environment, Junie is the agent that respects how you already work. The deeper your project's structure — modules, DI wiring, generated code, broad refactors — the more its index access pays off, and the more it pulls ahead of agents that read your code as text.
The case weakens as you move away from that profile. If your work is mostly small scripts or greenfield projects where there is little existing structure to understand, Junie's headline advantage barely engages and you are carrying IDE weight for a benefit you are not using. If you are not already a JetBrains user, adopting a full IntelliJ IDE just to get Junie is a large commitment, and a dedicated agent in a lighter editor will likely feel better day to day. And if raw agent speed and the most polished loop are what you optimize for above all else, the newest dedicated tools still edge it.
My own read after two weeks is that Junie finally makes "I refuse to leave IntelliJ" a position you no longer have to apologize for. It is not the flashiest agent on the market, but on a large JVM codebase it was the most trustworthy one I have used, precisely because it is standing on the same foundation that made me trust the IDE in the first place.
FAQ
Originally published at pickuma.com. Subscribe to the RSS or follow @pickuma.bsky.social for new reviews.
Top comments (0)