The IDE is dead
Multi-agent development is here and your editor wasn't built for it
There’s a moment in every technology shift where the old tool doesn’t break — it just stops making sense.
The spreadsheet didn’t kill paper ledgers because paper stopped working. It killed them because once you saw what a spreadsheet could do, going back felt absurd. GPS didn’t kill printed MapQuest directions because they were wrong — they got you there just fine. But once you had a screen rerouting you around traffic in real time, printing out twenty pages of turn-by-turn instructions felt like a joke. Netflix didn’t kill Blockbuster because the movies were better. It killed it because driving to a store, hoping the movie you wanted was in stock, and then driving back to return it stopped making any kind of sense once the alternative existed.
That’s where we are with development environments right now.
Developers aren’t writing code anymore
If you manage engineers or work alongside them, you’ve probably already noticed the shift — even if nobody’s named it yet. The day-to-day work of building software looks fundamentally different than it did eighteen months ago.
Developers aren’t sitting in an editor typing functions line by line. They’re describing what they want to an AI agent and reviewing what comes back. They’re prompting, steering, and approving — not typing semicolons and closing brackets. The craft hasn’t disappeared, but it’s moved up a level. The skill now is knowing what to ask for, how to evaluate the output, and when to intervene. The mechanical act of translating intent into syntax? That’s increasingly the agent’s job.
This is already happening at scale. If you’re still thinking of AI coding tools as fancy autocomplete, you’re about two iterations behind what your best engineers are actually doing with them. And it means the tools we’ve built around the old workflow are starting to feel like they’re in the way rather than helping.
Which brings me to what actually pushed me over the edge.
I’ve been building with Superset for the past few weeks, and I need to be honest: I don’t think I can go back to a traditional IDE. Not because VS Code is bad. Not because JetBrains is broken. Because the entire model — one human, one editor, one file, one cursor — is built for a world that no longer exists.
Here’s what my workflow actually looks like now.
I have seven completely separate projects running simultaneously — seven independent apps and tools, all building at the same time. Each one has its own workspace, its own context, its own AI agents. I’m running structured workflow automation in all of them — agents that manage planning, execution, and verification across each project autonomously.
When an agent finishes a task, Superset notifies me. I check on it, review the output, approve or course-correct, and move on. While I’m reviewing a PR in one project, agents are running tests in another, researching a dependency upgrade in a third, scaffolding a new feature in a fourth. I’m not waiting on anything. There’s always something ready for my attention.
I'm not writing code. I'm managing these agents like a team. I assign work, review output, make decisions, unblock things. My job as a developer has completely shifted — I'm an AI orchestrator now — or to borrow Jason Calacanis's term, an "AI Maestro." That's exactly what it feels like. I'm conducting an orchestra of agents across seven projects and my only job is to make sure they're all heading in the right direction.
One project, multiple agents, zero conflicts
That’s the multi-project workflow. But there’s an even more powerful pattern: multiple workspaces for a single project.
Superset creates a git worktree for each workspace, so when you open multiple workspaces on the same project, each one gets its own isolated code, its own ports¹, its own running environment. Nothing bleeds between them. You can have one agent building the auth system in one worktree, another building the dashboard in a second, and a third writing the API layer in its own — all on the same project, all at the same time, completely isolated from each other. When they’re done, you merge them in. Work that would normally take a week gets knocked out in a day.
That’s not a marginal improvement. That’s 5–10x faster on a single project.
Now layer on workflow frameworks that give your agents structured processes for planning, debugging, testing, code review, and execution — and the multiplier compounds again. The agents aren’t just fast, they’re disciplined. They follow repeatable workflows, verify their own work, and produce output that’s actually mergeable. Combine multi-workspace orchestration with agents that know how to work, not just how to generate code, and you’re building at a pace that would’ve required an entire team six months ago.
Code reviews in parallel (this one blew my mind)
Say you’re on a team and five coworkers have PRs waiting for review. In the old world, that’s context-switching hell — you check out a branch, read through the diff, leave comments, check out the next branch, repeat. It kills your flow and eats half your day.
With Superset, you open a workspace for each PR branch, spin up a code review agent in each one, and let them all run simultaneously. Five code reviews happening in parallel while you’re off building features in your other workspaces. When the review agents finish, you get notified, skim their findings, add any human context, and submit. Five reviews done in the time it used to take to do one — and you didn’t break your building flow to do it.
That’s the part that’s hard to convey until you experience it. It’s not just faster. It’s a fundamentally different relationship with your own time.
The IDE was built for a different species
Think about what an IDE assumes about you:
You work on one project at a time
You write code character by character
You context-switch by opening a different tab
Your output is limited by your typing speed and your ability to hold state in your head
Every one of these assumptions is now wrong.
And beyond the conceptual mismatch — IDEs are just slow. You’re loading a 2GB Electron app so you can ... look at a file tree and some syntax highlighting? You’re waiting for extensions to initialize, indexes to build, language servers to spin up. All that overhead made sense when the IDE was where the work happened. But the work doesn’t happen there anymore.
The modern developer — the one actually using AI well — doesn’t type code line by line. They describe intent. They review agent output. They orchestrate parallel workstreams. They make architectural decisions while three agents execute simultaneously. None of that requires a heavyweight graphical editor.
VS Code can bolt on Copilot. JetBrains can add an AI assistant. Cursor gets closer, but it’s still an IDE at its core — still built around the assumption that you, the human, are the one writing the code. You can’t patch a single-threaded interface into a multi-threaded workflow. The architecture is wrong.
The compound effect nobody is talking about
One AI coding assistant is useful. It’s autocomplete on steroids. Fine.
But multiple agents running across multiple projects simultaneously? That’s not a linear improvement. It’s a phase change.
Most of the friction in software development isn’t writing code. It’s context-switching. It’s remembering where you left off. It’s the cognitive tax of holding multiple systems in your head at once. It’s waiting for tests to run before you can move to the next thing.
Multi-agent orchestration eliminates almost all of that friction. The agents hold the context. The agents run the tests. The agents handle the mechanical work. You just ... think about the problem.
I built more in the last two weeks than I did in the previous two months. Not because I worked harder. Because the overhead disappeared.
This creates a real skill gap
I want to be direct about this because I think people are underestimating it.
The gap between a developer who knows how to orchestrate multiple agents across multiple projects and a developer who’s still using Copilot in VS Code is going to be enormous. Not “10% more productive” enormous. “Different order of magnitude” enormous.
It’s the same gap that existed between developers who learned to use Google effectively in 2004 and those who were still reading man pages cover to cover. Or the gap between teams that adopted CI/CD pipelines and those still deploying by SSH-ing into a server and running scripts by hand.
Except this gap is bigger because the multiplier is bigger.
The developers who figure out multi-agent orchestration — who learn to think in parallel workstreams, who get good at writing intent rather than implementation, who develop intuition for when to intervene and when to let agents run — those developers are going to look like they have superpowers.
Because they will.
What this means for teams and careers
If one developer can effectively orchestrate multiple agents across multiple projects, the math on team size changes. A team of three developers who are good at agent orchestration can cover the output of a traditional team of fifteen. That has real implications for hiring, org structure, and how companies think about technical leadership.
The “10x developer” meme was always a bit of a joke. The “50x developer” — the one running a fleet of agents — isn’t a joke. They’re already here.
This doesn’t mean developers become irrelevant. It means the role evolves. The developers who lean into this — who learn to orchestrate, who get comfortable directing agents instead of typing every line — are going to become dramatically more valuable. They’ll manage seven projects simultaneously, spin up review agents across five PRs without breaking their build flow, and treat agents as a workforce they direct rather than a tool they type into. Each one of them will do the work of a small team, and leadership will notice.
The shift is happening whether we’re ready for it or not. The question isn’t whether AI changes how software gets built — that’s already settled. The question is whether you’re the one driving that change or reacting to it. And right now, there’s still time to be on the right side of that line.
The developers who get this now have a head start. The rest will catch up eventually.
But “eventually” is a long time when the people ahead of you are moving at 50x.
¹ Port isolation across worktrees requires some additional scripting and configuration — Superset doesn’t handle this out of the box. But once you set it up, each workspace runs its own dev server without conflicts.