I Helped Build Your IDE. Here's What Will Replace It

From Cockpit to Control Tower: Developer Tools for the Agentic Era

“I literally have not opened up an IDE in at least six months.”

My friend Bryon dropped this in Slack last week, and I’ve been turning it over in my head ever since. Bryon’s a serious engineer. A hard-bitten chopper-bopper. Decades of experience. The kind of person whose opinion on tooling I trust. And he hasn’t opened an IDE in six months.

“I do not open source files and read them,” he continued. “Or, by extension, write them. I discuss it with Claude, who does all the actual coding. I scan some pull requests occasionally in the GitHub web UI, so technically I see some code there, but that’s rare.”

I started to type a response about how different our workflows were, and then I stopped. Because I realized they weren’t that different at all.

The Wizard’s Staff, Somewhat Rusty

I still open IntelliJ IDEA every day. It’s been my primary tool for nearly thirty years. I have keybindings burned into my muscle memory. I have plugins I’ve been using since plugins were a new idea. I have color schemes I’ve tweaked for decades. This is my wizard’s staff, honed and polished and exactly weighted for my hand.

And I realized, sitting there trying to explain to Bryon how different we were: I don’t edit code in it anymore either.

I use IntelliJ for PR management, because the tooling has gotten good-ish for that. I use it to read markdown files, because I produce a lot of markdown now (and when I say “I produce” I mean “I tell Claude to format his ideas as a report in Markdown”). I use it as a file browser, occasionally. I use it to run git commands through the UI when I’m feeling lazy. I hit the green arrow for a test run/code coverage report after every change. I use IntelliJ’s terminal tool to run Claude Code in, mostly so I don’t have to juggle an extra window.

What I don’t do is type in the edit window. I don’t manually trigger refactorings. I don’t run inspections and step through the results. I don’t use the intentions system — the system that suggests fixes, that anticipates what you need, that made IntelliJ feel like it understood your code.

That’s a lot of stuff I don’t use anymore. Stuff that I helped build.

The Cathedral and the Rising Sea

From about 2002 to 2006, I worked with JetBrains building out the intentions and inspections functionality in IntelliJ IDEA. This was the stuff that made the IDE intelligent. The lightbulb that appeared when the IDE knew how to help. The red squiggle that caught your mistake before you ran the code. The quick-fix that could refactor your code with a keystroke. The stuff that made IntelliJ IDEA something new under the sun.

I’m proud of that work. It’s probably the most impactful code I’ve ever shipped. I count approximately every enterprise Java or web developer for the last two decades among my users. Every time someone hits Alt-Enter and IntelliJ offers to fix their code, that’s the system I helped create. For a while there, it was probably one of the ten best pieces of software on the planet. I made out well, and helped make the founders of JetBrains the nicest billionaire Russian oligarchs you could ever hope to meet.

And now I open IntelliJ to read markdown files. Pidgin HTML.

This isn’t a tragedy. I want to be clear about that. IntelliJ and I had a great twenty-five-year run. The skills transferred, even if the tools didn’t. The work I did understanding how to anticipate developer needs, how to analyze code for problems, how to suggest fixes — that’s exactly what I’m doing now when I work with Claude. I’m just doing it in conversation instead of in Java.

But there’s something melancholy about watching a cathedral you helped build slowly vanish into the sea.

JetBrains Sees It Coming

Last week, JetBrains announced they’re killing Fleet, their attempt at a next-generation lightweight IDE. But the interesting part isn’t that they’re killing it. The interesting part is why, and what they’re building instead.

From the announcement:

“The developer doesn’t write the code themselves. They guide the agent and review its output. This is fundamentally different from the classic IDE workflow, which is based on immediate feedback, synchronous control, and a single stable local state.”

Read that again. JetBrains — the company that defined what an IDE is, the company that built the tools that shaped how a generation of developers work — just declared that the IDE paradigm is over.

They go further:

“The agentic loop relies on structured task definition, context assembly, multiple asynchronous runs, isolated execution, and review-first workflows. Combining them in a single tool results in a disjointed experience.”

They’re not pivoting Fleet to be a better editor. They’re building what they call an “agentic development environment.” Something fundamentally new. Something designed around the workflow that Bryon described, and that I’ve drifted into without quite naming it.

From Cockpit to Control Tower

Here’s the metaphor that’s been crystallizing for me:

The traditional IDE is the cockpit of a fighter plane. You’re the pilot. Hands on the controls. Direct manipulation. You fly the plane. Every second counts. The IDE gives you instruments — syntax highlighting, code completion, error detection, refactoring tools — but you’re the one doing the flying. Every keystroke is yours. Every decision is immediate. The feedback loop is synchronous: you type, you see the result, you adjust, you type again. I and a bunch of badass Russians went to a lot of trouble to make that cockpit as responsive and supple as possible with error highlighting creating a “heads-up display” to give developers exactly the view on their code that they needed and never had before, and affordances like automated refactorings giving you precisely the tools needed to manipulate it as fast as thought.

This model of “IDE as cockpit” assumed that the scarce resource was the code itself. The pilot had to fly because there was no one else who could.

In the agentic model, you are an air traffic controller. You’re not flying any of the planes. You’re directing traffic. You have multiple agents in the air — this one’s working on the authentication module, that one’s refactoring the database layer, another one’s writing tests for the API endpoints. Your job is situational awareness. Prioritization. Conflict resolution. Clearing approaches. Intervening when something’s going wrong. Just as fast, just as intense, just as technical, but on a much bigger scope.

The skills are different, although there is some overlap. A great pilot isn’t necessarily a great air traffic controller. The hand-eye coordination, the muscle memory, the direct manipulation expertise — none of that transfers. What transfers is understanding the airspace. Knowing what a good approach looks like. Being able to evaluate whether a pilot is doing something dangerous.

The JetBrains announcement describes exactly this shift: from “immediate feedback, synchronous control, and a single stable local state” to “structured task definition, context assembly, multiple asynchronous runs, isolated execution, and review-first workflows.”

That’s not an IntelliJ feature upgrade. That’s a new beast, slouching toward Bethlehem to be born.

What Control Tower Tooling Looks Like

Nobody’s really built the control tower yet. We’re all working in makeshift arrangements — Claude Code in a terminal, IDE open for PR review, GitHub web UI for scanning diffs, half a dozen browser tabs for documentation, issue-tracking, and monitoring.

What would purpose-built tooling for this paradigm actually look like?

Conversation history and context management. What did I tell which agent? What context does each one have? When I said “follow the existing patterns” to Agent A, does Agent B know about that too? Right now this is all in my head, or scattered across terminal sessions. This need for context also goes outward into the rest of the organization, encompassing inputs from requirements gathering, issue tracking and CI/CD.

Multi-agent orchestration. Who’s working on what? What’s blocked? What’s ready for review? What’s conflicting with what? I should be able to see my airspace at a glance.

Verification dashboards. The bottleneck in agentic development is review, not generation. I need tooling that helps me review efficiently. What’s been reviewed? What’s suspicious? How many new tests were created for this functionality, and how good are they? Where should I focus my attention? Show me the diffs that are most likely to be problematic.

Architectural coherence monitoring. When five agents touch a codebase, it can drift toward five different styles, five different patterns, five different architectures. I need something that detects drift before it becomes rot. I need something that proactively tells me “Agent C is using a different error handling pattern than Agents A and B, and Agent D has an idea that looks interesting but weakens an invariant you were trying to enforce”.

Confidence indicators. How sure is the agent about this change? Where did it struggle? What assumptions did it make? Right now I have to infer this from the code itself. The tooling should surface it, and do so in ways at least as accessible as IntelliJ’s squiggly underscores and lightbulbs.

Audit trails. Why did the agent make this decision? What was it trying to accomplish? “Show your work” should be a first-class feature, not something I have to explicitly prompt for.

Impact visualization. What breaks if this merges? What depends on what? The agents know this in some sense, but the knowledge is tacit. It should be explicit and visual.

I’ve been prototyping some of this myself. Bad Dave’s Robot Army — my collection of specialized Claude Code agents — includes early experiments in exactly this direction: agents for project management, issue juggling, context maintenance across workstreams, high-level code quality analyses. They’re crude. They’re held together with prompt engineering and wishful thinking. But they work, and every time I use them I get a clearer picture of what the real tooling needs to do.

Why the Terminal Isn’t the Answer

Claude Code is terminal-native. So is Cursor’s agent mode, more or less. This is how the first generation of agentic tools have been built, and there’s a reason for that: it was, in the words of the sage, “the simplest thing that could possibly work”.

The terminal is the universal interface. Every developer already has one. It doesn’t require building a GUI framework or designing a new visual paradigm. You can ship something useful in weeks instead of months. That’s useful when your competition is measuring their cycle-time in days.

But terminal-based agentic development is a transitional stage, not the destination.

The terminal is linear. Conversation flows in one direction. Context is implicit. State is invisible. When you’re orchestrating multiple agents across multiple tasks with complex interdependencies, the terminal becomes a keyhole through which you’re trying to view a panorama.

The future tooling will be spatial, not linear. It’ll show you the airspace, not just logs of the radio chatter.

That said — and this is important — the great big hammer of problem-solving will always need to exist. Even air traffic control has a way to say “pilot, take manual control.” Even the bridge of the Enterprise has manual override. Sometimes you need to reach through the abstraction and type a command directly.

Who Builds This?

This is the interesting question. The paradigm shift is clear. The direction is clear. But who actually ships the tooling?

JetBrains is an obvious candidate. They just announced they’re building exactly this. They have twenty-five years of understanding developer workflows down to the level of pixels. They know exactly what great tooling looks like. But they’re also carrying twenty-five years of cockpit assumptions. Their entire company is built around the direct manipulation model. Can they make the leap? The Fleet announcement suggests they’re trying, and based on my history I have no small hope, but who knows.

GitHub has a strong position. They’re already the review layer for most of the industry, and have made in-roads on both issue tracking and CI/CD. Copilot gives them an agent play. The network effects are enormous. And if cash is needed, I’m sure Microsoft would be happy to write a check. But GitHub has historically been a platform, not a tool. They build the airspace; they haven’t built the control tower.

Anthropic builds the agents, not the environment. Claude Code is deliberately minimal — they’ve said publicly they try to put as little UI as possible between the user and the model. They might keep it that way. Or they might decide that the environment is strategic and start building more aggressively. Claude Code hitting a billion dollars in revenue in six months has to have stirred some thoughts in that direction.

Some startup we haven’t heard of is probably the right answer. The paradigm shifts usually come from outside the incumbent players. Someone who doesn’t have twenty-five years of cockpit assumptions. Someone who looks at the problem with fresh eyes and builds for the control tower from day one.

I don’t know who it is. But I’m watching. And if any of my fine readers happens to have $10M for an A-round, I confess I would be tempted. I’ve built IDE intelligence before. I’ve been living in the agentic workflow for months now. I have capital-O Opinions on all of this. My robots can have wireframes in hours, and prototypes in days. I’m pretty sure I could assemble an elite team of hard-hitting agentic coding motor-scooters to attack this problem with no more than a few phone calls.

Just saying.

What to Learn Now

If the cockpit-to-control-tower shift is real — and I think it is — the implications for what developers should be learning are significant.

The cockpit skills are becoming commodities. Typing speed. Syntax memorization. The muscle memory of a thousand keybindings. The ability to hold a complex function in your head while you write it. These mattered enormously when you were the one flying the plane. They matter less when you’re directing traffic.

The tower skills are becoming essential. Specification clarity — can you describe what you want precisely enough that an agent can build it? Verification speed — can you review code efficiently, spotting problems without reading every line? Architectural judgment — can you evaluate whether a solution is good, not just whether it works? Context management — can you keep track of multiple workstreams and their interdependencies?

And maybe most importantly: knowing when to take manual control. The escape hatch isn’t just for emergencies. Sometimes the fastest path to a solution is to type it yourself. The judgment to know when to direct and when to do — that’s the skill that’s hardest to teach and most valuable to have.

The Wizard’s Staff, Reborn

I still open IntelliJ every day. Muscle memory is powerful, and thirty years of accumulated use is hard to abandon. But I know, now, that I’m not really using it anymore. I’m visiting it. Haunting it, some might suggest.

The work I did on intentions and inspections in IntelliJ IDEA was about anticipating developer needs. About analyzing code and suggesting improvements. About making the tool feel intelligent, like a partner rather than a passive target for keystrokes.

That’s still the work. It’s just that the partner got a lot more capable, and the interface changed from keystroke-and-lightbulb to conversation-and-review.

I don’t mourn the IDE. The IDE was a means to an end, and the end was always: help developers build better software faster. It was the biggest lever I had to make the world a better place. If agentic tools do that better than cockpit tools did, then the paradigm shift is progress, not loss.

I do sometimes miss the feeling of hands on the yoke. But then I direct five agents to refactor a module while I grab a Diet Coke and tune my guitar, and the feeling passes.

---

This post was constructed with the able assistance of Claude Opus 4.5. Our collaboration somehow manages to produce better work than either of us could produce on our own, something that I’ve never said about a human. That used to be surprising, but here we are.