The End of IDEs and Agentic CLIs? The Rise of ADEs

My grey hair probably gives it away, but I’ve been building software for a while.

The funny thing is that when I started programming, back in 2003, IDEs were already there. I’ve always lived with them, so they feel completely natural to me.

Programming inside an IDE made us far more efficient. It let us produce more complex code in less time and, above all, stop depending entirely on our own brains to write valid code.

That function you don’t remember how to type. That closing semicolon. Even JetBrains IDEs were pioneers in helping us transform code with some confidence that it wouldn’t break.

Programming can’t exist without the IDE.

Or can it?

We can disagree on how much AI we should use to build software, but one thing is already impossible to deny: this is a revolution on the same level as IDEs, or bigger.

And ironically, it may also be the beginning of their decline.

AI as support for the IDE

When GitHub Copilot first appeared, it blew everyone’s mind a little. An autocomplete so smart that our job was basically reduced to pressing Tab on its suggestions.

After a while, and after wearing out the Tab key, we realized that maybe this wasn’t the real path forward.

If what we wanted was for AI to generate our code, or at least part of it, it didn’t make much sense to accept nearly every line manually. At that point we already had side chats where we could ask questions, and those chats could use our code as context.

That was the first real shift: let AI modify the code directly. Some people moved quickly and saw the potential, creating what we started calling agentic IDEs, or AI-powered IDEs.

Every repetitive task a human performs can become more efficient with AI. Cursor became the clearest example, and the rest of the industry started moving in that direction.

But that only looked like a patch for what was coming next.

The rise of agentic CLIs

IDEs were still accelerating our classic workflow. But what if there was another way?

Claude Code was one of the clearest signals that there was. If the goal is simply to generate code, then what you need are tools that are really good at doing exactly that, while pushing review to the last step.

For that, you don’t need to stay inside the IDE all the time. You can work from a terminal.

Or much better, from many terminal instances.

If we’re no longer reviewing every step an agent takes, what stops us from having one agent working on a feature, another one reviewing a bug, and another updating documentation?

Or even working on several projects at once.

The terminal enables that, but it’s also true that it isn’t the most friendly tool. Some people are obviously very comfortable there. Others, like me, got there because there simply wasn’t another option with the same level of versatility.

In my case, I’d already been working with agentic CLIs since July last year. First with Claude, and from September onward with Codex CLI.

Then Codex App arrived.

Agent Development Environment

That’s what ADE stands for, in case you were wondering this whole time 😄

The first time I seriously used one, before I even knew the term was crystallizing, was with Codex App.

I’ve been seriously testing Codex App as a software development tool.

What matters isn’t that it “writes code”, but how it manages state, context, and flow when multiple tasks are happening at once.

The real question was: is it better than the CLI, or is the terminal still the better place to work?

See post

A few days later I wrote this:

Codex App feels more like an IDE adapted to the new world than the classic alternatives such as Cursor, Windsurf and the rest.

In Codex App, the focus is on agent orchestration, not on code.

It’s a fact that we’re going to review less code, and write even less of it ourselves. So filling most of the workspace with code is no longer the most practical design.

See post

If the new paradigm is parallel agent management, then an IDE where code remains the center starts to feel too limited.

The focus shifts toward things like:

• Orchestrating agents: the process is no longer sequential, it’s parallel, so moving across agents quickly becomes essential.
• Making sure they don’t step on each other: in a personal project you may tolerate four agents working on main for a while. That does not scale. These tools are starting to integrate concepts like worktrees from the ground up.
• Keeping review, but moving it aside: review doesn’t disappear. It just stops being the central pane and becomes something you open when you need it. Code is no longer the center of gravity.

A few days later I read someone, I can’t remember who, saying they were moving to Cursor because they believed ADEs were the future. That was the first time I heard the term explicitly.

And then it became obvious this wasn’t new at all:

• Cursor has Agent Mode.
• Antigravity has Agent Manager.
• And yesterday, JetBrains introduced Air, which they explicitly describe as an ADE.

I’m sure I’m forgetting others that either recently or for quite a while have been moving in the same direction.

But it does look like all the major players are converging here.

We are not ready for this shift

I’m not saying this isn’t the future. I’m saying it clearly isn’t the present for most developers.

I’m a strong believer in using AI for software development. I’m convinced that if you decide not to use it at all, you’re shooting yourself in the foot in your career.

People who use it with judgment and real understanding are far more productive, often maintaining or even improving the code quality they had before.

But that is not the majority.

A lot of people still don’t know how to make even a single agent write code properly, following their rules and producing reliable results.

We’ve been sold the idea that AI is magical, and that a well-written prompt is enough to get perfect output.

It isn’t.

You need a proper ecosystem around the agent:

Context (static and dynamic), guardrails, validation, workflows.

You don’t learn that in two days. It’s exactly the kind of work we do in AI Expert, and every time I teach it I feel six intensive weeks are still too short.

What many companies are doing right now is the opposite:

They give people a subscription to whatever AI tool is fashionable and tell them to be more productive starting tomorrow.

The damage a single badly used agent can do is already huge. Now imagine three, four, or ten agents running in parallel.

That’s why I think the industry still needs to mature before this way of working can really deliver value at scale.

Will we get there? I think so. And for some people, this is already the best possible way to work. I use Codex App myself as a development tool.

But for the average developer who isn’t riding the edge of the wave all the time, this is still years away from being a realistic day-to-day workflow.

My recommendation

If you’re just getting started with AI, the first thing you need is to make a single agent do the work the way you expect.

Start by delegating very small tasks. Validate the output line by line. Adjust the context every time it does something that doesn’t match what you wanted.

Then, little by little, delegate more.

Maybe first a slightly larger feature. Later a full commit. Later even letting it review a PR, but only once everything before that is already validated.

Only when you are comfortable with the tool, and the tool behaves the way you expect.

Before coordinating ten agents, make sure you know how to work well with one.

And if you want to accelerate that process, maybe I’ll see you in May inside AI Expert 😊