HomeArticle

Is the IDE Dead? Developers Are Fleeing Editors En Masse

神译局2026-04-28 07:12
How can agent orchestration replace the editor as the center of developers' work?

God Translation Bureau is a compilation team under 36Kr, focusing on fields such as technology, business, the workplace, and life, and mainly introducing new technologies, new ideas, and new trends from abroad.

Editor's note: Programmers are no longer "writing" code but "managing" agents. When the IDE degenerates into a low - level tool, the focus of programming is shifting significantly towards the "orchestration layer". This article is a compilation.

The focus of developers' work is shifting. It's not disappearing but shifting. It is moving from continuous, line - by - line editing within a single window to supervising agents that can plan, rewrite files, run tests, and submit changes for review. The IDE as we know it may no longer be the primary tool for software development or will undergo a drastic evolution.

In many tools used daily by developers, including myself, such as Conductor, Claude Code Web, GitHub Copilot Agent, Jules, Vibe KanBan, and even cmux, the same shift is constantly emerging: the control plane is becoming the main interaction interface, while the editor is taking a back seat and becoming one of several underlying tools.

Cursor has just released Glass - a new interface specifically designed to "make collaborating with agents clear, intuitive, and controllable". Here, agent management becomes the core experience, and the traditional editor becomes a tool to be used only when you need to delve into details. Developers' reactions were immediate:

"Now Cursor feels more like an agent orchestrator than an IDE. It's easier to manage agents in parallel."

But Glass is just one data point in the big trend. Terminal UIs like cmux highlight how the interfaces we're familiar with are evolving to better manage agent workflows.

Screenshot of the cmux terminal application

From editing files to mastering workflows

Historically, IDEs have been optimized for a "tight inner loop": open file → edit → build → debug → repeat. The so - called "end" argument is that once agents can autonomously perform most of these steps, this loop is no longer the core unit of productivity.

The new loop looks like this: specify intent → delegate → observe → review diffs → merge. The difference between it and "autocompletion with a chat window" is that it has the autonomy of tool use and is equipped with an interface designed to make this autonomy controllable.

You can see this trend playing out in widely used tools. Claude Code Web (or the desktop version) and Codex allow developers to assign well - defined tasks to agents running in isolated cloud environments, and the progress is visible in the browser - no terminal and no local environment configuration required.

GitHub Copilot's agents can independently plan and implement multi - file changes, create branches, run tests, and submit PRs for review; the developer's main job becomes reviewing the results and iterating, rather than directing every step.

Conductor takes a different approach: a desktop application for running multiple Claude Code agents simultaneously in isolated workspaces and monitoring the progress of all agents in real - time. Google's Jules handles asynchronous background tasks - you assign work, it runs, and you check the results after it's done.

What these tools have in common is a mental model: the unit of work is the agent, not the file. The interfaces worth optimizing are those that help you direct, monitor, and review agents, rather than those that help you type faster.

The orchestration layer takes shape

This "replacement theory" is convincing only when you observe specific interface patterns that tend to be consistent across different tools.

Work isolation as a primitive. Agents running in parallel need to not interfere with each other. Almost all serious tools in this field have chosen git worktrees (or similar technologies) as a solution. Conductor maps each agent session to its independent, isolated workspace. Vibe Kanban (as shown in the figure above) does the same in its kanban - driven agent workflow. This pattern is almost everywhere because the problem is real: without isolation, agents running in parallel will create chaos.

Planning and task status as the main UI. Tools like Vibe Kanban have replaced "tabs and files" with "tasks and status" as the highest - level mental model. You create task cards (a landing page, a backend service, an email integration), assign each task to an agent and a model, and manage the entire work like a lightweight project kanban - except that this "team" runs autonomously. This is a project management interface implemented by agents.

Background agents and asynchronous - first design. Some of the most interesting tools in this field don't even try to keep you in sync during execution. Cursor, Copilot, and Antigravity all support background agents that can run without your presence - you define the intent, leave, and come back to review after they're done. Jules works similarly: assign tasks and come back to check the code diffs. The underlying message is that your attention is too precious to be wasted on watching progress bars. This is significantly different from the real - time, synchronous feedback loop of an IDE.

Attention management for parallel agents. When many agents are running concurrently, the real bottleneck is knowing which one needs you now. That's why tools like Conductor show real - time progress across sessions, and cmux introduces notification rings and unread markers for terminal panes. "Agent needs attention" is becoming a first - class citizen event in the developer environment - it's a task that needs to be routed and prioritized, not just noticed.

Agents embedded in the software lifecycle. GitHub's Copilot programming agent is asynchronous, protected by the control layer, and driven by GitHub Actions - it's linked to the actual way code is delivered (Issue → PR → CI → merge), not just the way code is written.

No tool claims that the IDE is obsolete - many tools still interoperate with it. But these recurring patterns (parallel workspaces, diff - first review, task status, background execution, lifecycle integration) are what the proponents of the "end of the IDE" are referring to when talking about the shift of focus.

Why developers still need an IDE

The best counter - argument to the "IDE is dead" argument is that the IDE still compresses several truly difficult problems into a high - fidelity feedback loop: precise navigation, local reasoning, interactive debugging, and the ability to understand the system through direct manipulation.

Even the most ambitious orchestration tools retain a "way out" for manual editing. For example, review diffs within a thread, comment on changes, and then open the results in the editor for manual adjustment. This acknowledges that human intervention is still part of the expected workflow.

Agent tools themselves highlight the limitations. Multi - file refactoring in large repositories remains one of the most difficult challenges for software engineering agents. In these scenarios, interactive code navigation and human judgment are still crucial - you need to hold an overall mental model of the system, which agents cannot fully reconstruct from context alone.

The failure mode that makes developers stick to IDE - level checks is "the agent almost gets it right but has a slight error". When something is 90% correct but has minor errors, the cost of finding the problem often exceeds the cost of writing it yourself. For high - risk changes, the IDE is still the best tool for in - depth, precise checks.

The new cost: review fatigue and governance overhead

If development becomes "running multiple agents in parallel", the workflow inherits problems more like those of distributed system management than text editing - observability, permissions, isolation, and governance.

The agent workflow reverses the labor pattern. You're no longer the writer but the reviewer. This sounds like progress until you're staring at 12 code diffs from 12 parallel agents at the end of the day. Review fatigue is real, which is why the most thoughtful tools in this field focus on attention routing, structured plans, and review - first checkpoints, rather than defaulting to full autonomy.

As agents gain access to more tools, repositories, and external systems, the security surface expands. When agents can browse the web, query databases, write to the file system, and trigger deployments, "what they're allowed to do" becomes as important as "what they can do".

In terms of observability and control, the agent model integrated in the IDE has begun to drive explicit tool logging and approval checkpoints. Once agents perform asynchronous operations and touch the CI pipeline, governance issues are no longer optional.

Who will survive: the IDE, the control plane, or both?

A clear interpretation of the current situation is that the claim "the IDE is dead" is correct in direction but wrong as a literal prediction.

The strongest version of this claim is that the IDE is no longer the main workspace but degenerates into one of several subordinate tools - for targeted checks, debugging, and final editing; while planning, orchestration, review, and agent management are shifted to dashboards, task trackers, observable terminals, and cloud control planes.

The concept of the "big IDE" is also well - supported. The new "IDE" is a system that provides multi - agent orchestration, isolated workspaces, permissions and audit logs, diff - first review, reliable tool connections, and attention routing. The file editor still exists, but it's no longer the entry point.

The IDE is not dying; it's being "decentralized". The focus of work is shifting outward - to the orchestration interface, where humans go back to define intent, delegate to parallel agent running environments, and spend more time on supervision, review, and governance rather than typing on the keyboard.

The IDE is still crucial for correctness, understanding, and difficult problems that agents still struggle with. But it's no longer the only place to do programming - and for more and more people, it's no longer their first choice.

Translator: boxi.