Are IDEs Dead? Why AI Agents Make Them Matter More.
In a Nutshell
IDEs are essential when AI agents generate code because they provide the codebase context, runtime understanding, and deterministic tooling that agents lack. Developers must still review agent changes for correctness, tracing call paths, running tests, and debugging to ensure production safety. JetBrains positions its IDEs as the stable, code-aware foundation where any agent can work, rather than building around a single agent or model.
These notes were generated by AI and may contain inaccuracies.
An agent writes the code now. The question that arises is whether an IDE is still needed if an agent handles the coding. If an IDE is just where you type code, then typing going away would eliminate the need for the fancy typing app. However, that's not what an IDE is, and it never was. Something learned fast in software development is that the start of the conversation is not the end. Say an agent changes how a payment retry works.
The test pass, the code looks perfectly reasonable. The question becomes whether to ship it right away, merge, and close the laptop. What matters isn't in the diff. It's whether a customer can get charged twice. That knot in your stomach before hitting merge indicates that confidence in work has to come from somewhere other than looking the diff really hard. It comes from knowing who calls the code, what changes downstream, and what happens in runtime.
The code has to be right. Most developers already feel this. In Stack Overflow's 2025 survey, the most common frustration with AI tools was the output that was "almost right, but not quite." Almost right in a payment system is not acceptable. At JetBrains, the question was flipped. Instead of asking whether anyone still needs an IDE, the question became what happens when humans aren't the only ones working on the code anymore.
For years, the IDE was a place where you wrote code and understood it. Now, the IDE is the tool that holds the full context and the intelligence surrounding an entire codebase. That knowledge isn't just meant for one person. Agents inside the IDE get to use it too. The goal is for agents to work somewhere where the impact of their work can be seen. That's what Air inside JetBrains' IDE is for.
Take that retry change mentioned earlier. The process involves following what the agent is doing, opening the diff, and reviewing it with everything used on a human's pull request. This includes jumping from the change method to the code that calls it, running the relevant tests, stepping through the retry path in the debugger, and seeing whether that double charge can actually happen. Then, it's the developer's call. A comment can be left on the code, and it will be sent to the agent as a prompt to work on, or the developer can take the wheel for that last 10% themselves.
Whenever the need arises to know who calls a function, find usages is the tool to reach for. The IDE understands the project's types, dependencies, and structure, so a precise, code-aware answer comes in a couple of clicks with no setup. A terminal agent can have similar capabilities, for example by connecting it to a language server, though depending on the agent, that may take extra configuration. Without that, it often ends up doing archaeology on text, graphing, cross-referencing matches, all while spending tokens to rediscover what the IDE already knows.
In the IDE, that project understanding is simply built into the environment already being worked in. A codebase is so much more than text that an agent can read. There's what the program actually does at runtime, the binaries it compiles into, the database it talks to, the test results, the profiler output.
Where is an agent supposed to get all of that? Guess harder? The IDE already has it. All of it. And knowledge is literally what an IDE is. And everything it gives, agents are now starting to get it too. There are a number of agent skills now in JetBrains' IDEs that allow agents to take advantage of the deterministic tooling that establishes hard facts about a codebase. And more of those are on the way.
There has been a deliberate choice to say "my agents" in plural throughout this discussion. That's on purpose, because there is another way to answer what the IDE becomes in the age of AI. And that's to build it around the agent. That's the direction many other companies in the space are taking right now. Sometimes the model underneath can be swapped, but the agent itself, the workflow, and the pace of updates are fixed. Pick the tool and the whole harness is picked. That approach is considered backwards.
Agents and models are good at different things, and they leapfrog each other every few months. What doesn't flip every few months is a codebase. And everything an IDE knows about it. That's the stable center of work. And any agent should be able to be invited to work on top of it.
With JetBrains' IDEs, the agent already being used can be brought in, along with a subscription already paid for, whether personally or through a company. Agents can be mixed by task. Switching is possible when something better ships. That's what ACP, the Agent Client Protocol, makes possible. The IDE stays the stable, code-aware layer underneath, whatever is chosen to run on top.
The question remains whether an IDE is still needed when not writing all the code by hand. The IDE was never just a simple notepad. It helps understand software, change it, and verify the results. That used to serve one developer on a keyboard, now it serves the developer and the agent. The code got easier to write, understanding it and making it hold up in production didn't. And that's what JetBrains' IDEs are for.
Keep JetBrains in your library
Save the videos and channels worth coming back to, and find them again in one place.
