The IDE was always a waiting room.
I run five agents at once now. I have for about two months. The number is not the interesting thing. The interesting thing is what changed, on a Wednesday in September, when I crossed from running one to running five, because the work I was doing did not change. The work I was doing was operating. And the form factor I was using to operate stopped being a code editor and started being a kind of dispatcher's bench, with five terminals, three browser tabs, and a notebook where I was writing down which agent had which job and when each was likely to come back asking for input.
That dispatcher's bench is the operator's role, run at a different cadence, with the surface I happen to have in 2025, which is a tiling window manager and a row of identically-decorated terminal panes. The IDE is still on the screen. I open it less every week. The IDE is the place where I read what an agent did, sometimes, when I want to verify by hand. The IDE is no longer the place where work happens.
The IDE was always a waiting room. The rest of this is what that means.
The form factor lag
There is a pattern in software where a form factor outlives the work it was designed for, by years, because nobody has named the thing it has become. The keyboard outlived typewriting by decades before anyone called it a control surface. The browser outlived document-reading by a decade before anyone called it an application platform. The form factor stays. The work moves. The name catches up later, usually after the next form factor has already shipped and made the previous one's true purpose retrospectively obvious.
The IDE is in that interval right now. The IDE was designed for a single human reading and writing code at the speed a single human can read and write code. Every affordance in it (the file tree, the syntax highlighting, the find-and-replace, the inline diagnostics, the integrated terminal) assumes a single operator with attention budget for one buffer at a time. That assumption was correct for thirty years. It stopped being correct in 2025, somewhere between Claude Code shipping in February and the casual normalization, by midsummer, of operators running two or three agentic CLI sessions in parallel.
The operators who crossed from one to two early discovered the same thing I discovered in September. The bottleneck stopped being how fast you can read code. The bottleneck became how fast you can route work. And the IDE has no affordances for routing work, because routing work was never the IDE's job. The IDE's job was to be the room you sat in while you did the work yourself.
When the work moves out of the room, the room is a waiting room. That is what the IDE has been since at least Q1 2025 for the operators on the leading edge of the cadence shift, and it is what it will be for everyone else inside the next twelve months, whether or not they have noticed yet.
What breaks first
The thing that surprised me most, crossing from one agent to three over the course of August and September, was how few of the failures were about the agents themselves. The agents got better between every release I touched. The capability surface widened by something like one meaningful step every three weeks across the summer. The failure modes were all on my side of the dispatcher's bench.
The first thing that broke was attention. I had been operating, for fifteen years, on the assumption that an operator's attention is best spent in a single deep buffer, with everything else suppressed. That habit is correct for the work an operator used to do. It is wrong for the work an operator now does. The first three days of running three agents in parallel I made every wrong attentional choice the habit predicted. I went deep on whichever pane had the most interesting output. I let two of the three sit idle, blocked on questions I could have answered in fifteen seconds, while I lost a half-hour to rewriting a function the third agent was already two minutes from finishing on its own. The deep-focus habit, applied to a fleet, produces an idle fleet.
The second thing that broke was the assumption that work I had handed off was work I no longer had to think about. Handed-off work generates new questions every few minutes, and those questions accumulate behind whichever pane is currently out of view. The operator's job at three agents has nothing in common with the operator's job at one. It is to keep five conversations alive at the cadence each conversation needs, which is closer to running a small team than to running a single buffer, and which my fifteen years of habit had not prepared me to do. The accumulation is not visible until you have missed two clarification requests, and the cost of having missed them is that two of three agents are now an hour behind where they should be. On a working day in late October 2025 I dispatch somewhere between thirty and fifty tasks across the fleet, and the implementation work on the substantive ones is done by an agent before I open the IDE at all, which I do, when I do, only to verify what already shipped.
The third thing that broke was the merge. Two agents working on the same repo, on different branches, with explicit instructions about which files each may touch, will still produce work that has to be reconciled by hand more often than not. The agents do not, by default, know what their siblings have already shipped. The reconciliation is operator-tier work that did not exist when there was one of me typing into one buffer, and that the second-most-time- consuming thing I now do, after dispatch itself, is the merge.
The fourth thing was the most interesting. Around mid-September I started catching myself doing work the agents could have done, not because I had decided the agent could not handle it, but because I had not stopped to ask. The default action, after fifteen years, is to do the thing yourself. The default action, in 2025, has to be to dispatch. The retraining is real, and slower than I expected.
What an operator actually does at five agents
The mechanics of operating at five agents are not exotic, which is part of why they are so under-discussed. Most of the work is dispatch.
I keep one terminal pane for the agent that is doing long-running research, something I have given a multi-step task to and that I expect to come back in twenty minutes or two hours with a result. I keep two panes for agents doing parallel work on the same repo, on different branches, with explicit instructions about which files each may touch. I keep one pane for an agent that is in the middle of an interactive task, refactoring a module or debugging a flaky test or writing a runbook, where I expect to be back-and-forth with it every few minutes. The fifth pane is the scratchpad: a fresh agent I spin up to ask a one-off question or to draft a short artifact while the others work.
The operator-tier work, across those five panes, is approximately four things. First, deciding what each agent should do next, which is mostly a question of which jobs are unblocked and which jobs depend on a result that is still in flight. Second, watching for the agent that needs unblocking: a permission, a credential, a clarification, a tool call that is failing for a reason the agent cannot diagnose. Third, reconciling outputs when two agents have produced overlapping work, which happens more often than the literature would suggest because agents do not, by default, know what their siblings have already shipped. Fourth, periodically pulling the whole context up a level and checking that the five threads, considered as a portfolio, are still pointed at the work that actually matters this afternoon.
None of those four things is what an IDE is shaped for. All four of them are what an air-traffic-control tower is shaped for, or what a kitchen expediter's pass is shaped for, or what a hospital charge nurse's board is shaped for. The form factor that is going to replace the IDE for serious agentic work is going to look much more like one of those control surfaces than like a single-buffer text editor.
What this means for who an operator is
The operator-class has been undergoing an identity revision for about eighteen months that nobody has named cleanly. The revision is this: the operator is no longer the person who does the work. The operator is the person who decides which work gets done, by which agent, in which order, with what supervision. The hands-on-keyboard work that used to define an operator's day has migrated, mostly, to the agent fleet. The judgment work has migrated up.
This is not the same observation as “AI will replace coders,” which is the form the conversation usually takes when it gets to the public surface, and which I have written before is the wrong frame. The judgment work that has migrated up is not new judgment work. It is the same judgment work operators have always done, which inevitably resurfaces every time the implementation tax falls and the planning tax becomes the binding constraint. The judgment shift is about what the operator's hands are doing, not about what the operator's brain is doing. The brain is doing the same thing it has always done. The hands are no longer typing the implementation.
I have been running an agentic stack for my own work since March 2025: a cockpit-and-autopilot pattern where my own attention sits at the cockpit (an LLM-mediated planning surface, conversational, where the strategy work happens) and a fleet of background agents on a small VPS handles the autopilot (long-running tasks, scheduled jobs, follow-ups, the work that does not need me in the loop to be done correctly). The cockpit-autopilot decomposition is the load-bearing pattern. The cockpit is where the operator-as-judgment lives. The autopilot is where the agent-as-implementation lives. The IDE is neither. The IDE is the box I open when I want to read what the autopilot did, and only then.
I expect this decomposition to be the dominant operating pattern across the operator-level by the end of 2026. Not because I am uniquely early. I have been doing it eight months, which is not very early. But because the mechanics, once an operator has crossed from one agent to three, will inevitably surface this shape on their own. The cockpit-autopilot pattern is what the work asks for, once the work is operating instead of typing.
What the form factor turns into
What is already legible, with the same clarity that the agent layer was legible in October 2024, is the shape. The successor form factor has three properties the IDE does not have, and once you have run a fleet for a season they are obvious in the way load-bearing things are obvious only after you have leaned on them. It will be multi-pane by default: the unit of attention is the fleet, not the buffer, and any UI that does not surface the fleet at a glance is going to feel like driving with a single mirror. It will have dispatch as a first-class verb: the operator's most-used action, by frequency, will be assigning a task to an agent or moving a task between agents, and any UI that buries that action two clicks deep is going to lose to one that makes it the spacebar. And it will have state on the work, not on the surface: the work will be the durable artifact, persistent across sessions, agents, restarts, and re-orgs of the fleet, while the panes themselves will be ephemeral, no more sacred than terminal windows are now.
The IDE has none of these properties, by construction. It was built when the operator and the implementation were the same person, and the affordances reflect that assumption. They are not bad assumptions. They are last-generation assumptions. The IDE will live on for a long tail of work where a single human is in fact the implementation, the way pencils still exist in 2025 and will still exist in 2050. But for the operator who is running a fleet, the IDE is the box of pencils on a desk where the work is now happening on whiteboards.
The form factor that succeeds the IDE is going to be built by people who already operate at a fleet, for people who already operate at a fleet. That is a small market in October 2025, and a market that will swallow the IDE category whole by the end of 2027. The interval between those two facts is the window in which the form factor gets defined. I do not know which team gets to define it. I know the team that does will have crossed the one-to-five threshold themselves, and will have spent the months I am spending now building scaffolding out of tmux and shell scripts and notebooks because nothing on the shelf yet fits.
What this looks like, looking back from 2027
From far enough away, the orchestrator-tier shift is going to look the way most form-factor shifts look in retrospect, which is to say obvious, undramatic, and faster than any of the people inside it thought it was at the time. The question every founder, CTO, and head-of-engineering will be asking by the second half of 2026 is not should we adopt agents. That question is already settled in 2025; only the noticing is on a delay. The question is going to be how is our operator layer organized to dispatch a fleet, and the companies that answer it the way they answered the IDE question (by picking a vendor, signing a license, and calling the procurement complete) will be the companies that look, in 2027, like they kept buying typewriter ribbons through 1985.
The shift is not from human to agent. The shift is from buffer to fleet, from typing to dispatch, from the operator-as-implementation to the operator-as-orchestrator. The agent is the new implementation surface. The operator is what the operator has always been. The room they have been sitting in for thirty years has been a waiting room the whole time, and the door at the back of it is starting to open.
—TJ