Why JetBrains Is Right to Treat AI as an IDE Problem

JetBrains argues that AI coding quality depends on the IDE, not just the model.

JetBrains is right to treat AI as an IDE problem, not a model problem. The company’s current AI posts keep circling the same conclusion: when code generation moves from toy demos into real software work, the environment around the model matters as much as the model itself. That shows up in their own experiments with AlphaEvolve on IDE indexing, their push for IDE-native search tools, and their insistence that review, ownership, and understanding still happen inside the editor where the code actually lives.

AI fails in software when it lacks context

The strongest evidence is JetBrains’ own AlphaEvolve work on indexing, one of the hardest parts of an IDE to optimize. Their point is blunt: indexing is not a side feature, it is the structure that lets the rest of the toolchain understand the codebase quickly and accurately. If an AI system has to infer the codebase from scratch every time, it is already at a disadvantage. A model that can write plausible code is still blind without the surrounding signals that an IDE supplies.

This is why the blog’s framing around “IDE-native search tools” matters. JetBrains says the same coding tasks ran faster and cheaper when agents had prebundled tooling across models and languages. That is not a small implementation detail. It is proof that the model’s raw capability is not the bottleneck; the bottleneck is whether the tool can find the right symbols, files, dependencies, and local conventions fast enough to make the model useful.

Productivity gains come from the workflow, not the prompt

JetBrains’ Koog 1.0 announcement pushes the same thesis from another angle. A stable agent framework for Kotlin and Java is not just about giving developers another way to call an LLM. It is about making agent behavior predictable enough for production backends, with a 1-year API stability guarantee and better interoperability. That is a workflow story, not a prompt story. Teams do not ship on the basis of clever prompts; they ship on the basis of systems that can be maintained, observed, and integrated over time.

The ReSharper 2026.2 preview and the hackathon coverage reinforce that point. JetBrains keeps describing AI features in the same breath as IDE features, performance, and developer experience because that is where the value lands. A developer does not need a smarter chat box. They need a tool that can suggest code, inspect the project, surface the right files, and keep the human in control when the change reaches review. That is why the IDE remains the real unit of productivity.

The review bottleneck is where AI adoption succeeds or fails

JetBrains’ strongest argument against model-first thinking is its warning about review. In “Stop Sending IDE-Catchable AI Code Errors to Review,” the company says AI coding tools are increasing PR volume and changing the defect profile, while the reviewers stay the same people. That is the hidden tax of model-centric adoption: you do not remove work, you move it downstream. If the IDE can catch the mistake before the PR, the team saves time twice, once in review and once in cleanup.

The same logic appears in the post about the IDE as an AI quality variable. JetBrains argues that developers’ AI tools are only as good as what they know going in, and the IDE can give them a head start by shaping that knowledge. That is the right framing. The bottleneck is not just generation, it is correction. When the IDE helps the agent understand the codebase before it writes, and helps the human validate the change before it merges, the whole pipeline gets better.

The counter-argument

The best case for the opposing view is simple: models are improving so quickly that the surrounding tooling will matter less over time. If foundation models can reason across larger contexts, use tools autonomously, and write cleaner code with fewer mistakes, then the IDE becomes a nice-to-have layer rather than the center of gravity. From that perspective, JetBrains is overinvesting in the wrapper around the intelligence.

That argument has real force in narrow demos and greenfield work. A strong model can produce impressive output even in a weak environment, and teams under pressure will always be tempted to buy the biggest model and call it strategy. But that logic breaks in real software organizations, where the codebase is large, the review process is strict, and the cost of a wrong change is high. JetBrains is not claiming models do nothing. It is saying the model’s gains are capped unless the IDE turns those gains into context, safety, and maintainability. That is not a wrapper. That is the product.

What to do with this

If you are an engineer, stop treating AI coding tools as interchangeable chat interfaces and start evaluating them inside your real IDE, on your real codebase, with your real review process. If you are a PM or founder, measure AI success by fewer review cycles, fewer IDE-catchable defects, and faster time to a correct change, not by raw suggestion count or demo polish. The winning stack is the one that helps developers understand, change, and own code faster without pushing more cleanup onto the team.