--- title: "Do Developers Still Need an IDE When Agents Write Code?" url: "https://goremy.ai/blog/articles/future-of-ides-coding-agents-jetbrains" author: Luis Chavez-Mattos editor: Luis Chavez-Mattos editor_title: Director, Product published: "2026-11-06T05:40:07.023Z" updated: "2026-11-09T18:55:59.877Z" topic: AI Coding Tools description: Coding agents like Claude Code and Codex write the code, but IDEs still matter for diffs, navigation, verification and docs. Review is the new bottleneck. --- # Do Developers Still Need an IDE When Agents Write Code? > Coding agents like Claude Code and Codex write the code, but IDEs still matter for diffs, navigation, verification and docs. Review is the new bottleneck. Edited by Luis Chavez-Mattos, Director, Product · Published 2026-11-06 · Updated 2026-11-09 ## Do developers still need an IDE if coding agents write most of the code? Yes, but for a different job. When agents like Claude Code and Codex produce most of the code, the IDE stops being the place where you type and becomes the place where you read, check and decide what ships. Typing is cheap now. Verification is not. The IDE's value shifts to four uses: reviewing diffs, navigating code, verifying behavior, and maintaining documentation. ## TL;DR - The IDE's main job is moving from **writing code to reviewing it**, and handwriting code in an IDE will be occasional. - Agent changes often touch 10 to 15 files, which a terminal **cannot show you clearly**. - JetBrains talked to engineering teams and found implementation got fast while **code review and planning became the bottleneck**. One team measured PR time going up, not down, after rolling out agents. - Four concrete uses hold up: **diffs, navigation, verification and documentation**. - IDE features such as semantic search can also help the agent, giving it **better context and fewer wasted tokens**. - Having another agent review the work helps, but a person who understands the system still needs to **sign off on production**. ## Why would an IDE still matter if agents do the typing? Hand a task to Claude Code or Codex and the result is rarely a one-file edit. Changes commonly spread across 10 to 15 files. A terminal scroll or an agent chat panel gives you a wall of text, not a picture of what changed and how the pieces fit. That matters most when you own the result. Vibe coding is fine for quick ideas and throwaway experiments. Code headed to production is different. If you call yourself a developer, you need to know what the code does and whether it is right, and you cannot hand that judgment entirely to the model. Multiple agents make it worse. One developer building a model-testing suite described touching the same codebase with several agents, including Claude Code and Codex. Each had its own idea of how things should work. The suite supports many backends (Gemini APIs, OpenRouter, local vLLM and SGLang, Llama.cpp, Nvidia Dynamo), so modular structure mattered far more than any single function. Keeping that structure intact means knowing how the codebase is laid out, and an IDE is good at showing that. ## Where has the bottleneck moved? An agent can produce a change in minutes. Reviewing it can take much longer than writing it did. That gap lands on whoever is responsible for merging. Large organizations already work this way. The pattern described: anyone can now write code and open a pull request, but a software engineer still has to go through it and sign off, and that engineer is accountable, not the person who vibe coded the idea. JetBrains published a post based on conversations with engineering teams and reported the same shape. Implementation became quick. The bottleneck moved to code review and planning. One team measured it and saw PR time rise as agents rolled out. That is arguably the right response to a trust problem. A team whose review time dropped to zero would be the more worrying sign. Agent-on-agent review catches real problems, and it is worth using. It does not replace a person who knows what the system is supposed to do. Someone has to confirm the change reaches a good result in an acceptable way: not breaking rules or laws, not running up large compute or database bills. Models may close that gap eventually. For now, humans sign off. ## What do you actually use an IDE for with coding agents? The argument breaks down into four uses. | Use | What you do | Why a terminal falls short | |---|---|---| | Diffs | See which files changed, what is in them, and whether docs match | A wall of text hides structure | | Navigation | Jump to callers, find usages, see interface implementations | Judging safety needs the call graph | | Verification | Run tests and inspections, step through with a debugger | You need to see which tests pass or fail | | Documentation | Review what the agent wrote about intent and constraints | Docs shape future agent context | ### Diffs Before anything an agent writes gets merged, you want a sense of the file structure, the contents, and whether the documentation describes what the code does. A proper diff view makes that fast. ### Navigation When an agent changes a function, you want to see where it is called and what implements the interface. IDEs have offered this for years, and it is exactly what you need to judge whether a change is safe. If a change makes many database calls, you can check that it does so efficiently. For low-stakes code, you can skip the deep look. ### Verification Run tests and inspections. When something looks off, step through it with a debugger. Reading test output in the IDE lets you see what passes and fails. It also lets you check that tests do what they claim, rather than something like a hardcoded `return true`. ### Documentation Agents should write documentation as they work, and you should review it. Does it explain why a component exists and what constraints apply? Did the agent change things you did not ask for? Good docs feed back into better context and better output, especially when you use several agents together, such as Claude Code, Codex, Open Code or a custom harness. One tip passed along from someone at Anthropic: ask agents to generate HTML documentation and diagrams of the system layout. If those reference real file names, you can open the files directly in the IDE. ## Are IDEs turning into agent runners? Partly. The IDE is merging with the agent workspace. GitHub Copilot was an early example, with an agent panel next to the code panels. Other tools tried similar ideas, including cmux for running several agents at once, plus Herd and T3 Code. JetBrains Air also lets you run and orchestrate multiple agents from inside the IDE, not just one. The common goal is moving quickly from high-level chunks down to low-level code. You assign work at the top, then drop into a specific file when something needs a closer look. ## Can the IDE help the agent too? It can. An agent limited to grepping files often works half blind and burns context window figuring out the project. An agent that can use IDE features such as semantic search across the codebase gets better context, so it should be more accurate. It should also use fewer tokens. Token cost is worth watching. Current high-priced subscription plans ($100, $200, possibly $500) allow heavy usage. If that changes and developers pay per API call, efficiency gains from better context would matter much more. ## How did IDEs get here? For most of their history, IDEs were where you wrote code. Snippets, refactoring tools and autocomplete all made typing faster. Early AI autocomplete extended that by finishing whole functions and matching variable names. Agents went further. Typing code is no longer the main activity, and often it is the worse option. An IDE built only around typing would be in trouble. One built around reading, navigating, understanding and checking code is not. ## Frequently Asked Questions ### Will I ever hand-write code in an IDE again? Occasionally, for small edits. The expectation is that most IDE time goes to inspecting code and understanding how it was produced, not typing it. ### Why did PR time go up when teams adopted agents? According to JetBrains' conversations with engineering teams, implementation became fast while code review and planning became the bottleneck. One team measured PR time rising as they rolled out agents. More generated code means more to check, and trust in agent output at large organizations is still limited. ### Can another AI agent do the code review instead? It can catch real issues and is worth using. It does not remove the need for a person who understands what the system should do and can judge cost, legality and correctness. For production, human sign-off remains the safer position. ### Is the terminal enough for quick projects? For prototypes, ideas on your phone, or throwaway work, often yes. The case for an IDE grows with the stakes. Code you plan to put into production, touching many files, deserves a proper diff, navigation, tests and a debugger.