Engineers are replacing IDEs with terminals 🖥️
Let's understand why this is happening, and what may be coming next.
Six months ago, every developer I knew who was serious about AI coding used an IDE — like Cursor or Windsurf. I know because I asked them — which is part of my fiduciary duty towards readers: I ask people how they work, so I can later write about it.
And to me, this AI IDE stuff felt pretty natural: we have been using IDEs for 20+ years, refining and making them better, so the next evolution of this journey had to be an AI-powered IDE.
Or has it?
Fast forward to today, most of those same people are not using Cursor anymore. They are not even using an IDE. They are mostly using CLI tools, like Claude Code or Codex. Sure, they might jump into the editor every now and then, but the core work loop happens in the terminal.
How did we get there? And why?
Today’s article explores what makes CLI AI tools special right now, why many people are preferring them to IDEs, how to use them for good, and what the future might look like.
So here is the agenda for today:
💻 What is coding really about? — how the traditional split between writing code and running commands is changing.
⚖️ Engineer context vs manager context — IDEs optimize for the wrong type of work in the AI era.
📋 Good vibe coders are good managers — while the opposite is not necessarily true.
🔭 What the future holds — why we need entirely new interfaces for AI-first dev.
Let’s dive in!
To learn more about this topic, I am also partnering with the folks at Warp, which gave me a lot of good food for thought!
I have been a happy user of Warp as my main terminal app for more than one year now, and they have now launched Warp Code, which is their own take on all of the above.
Disclaimer: I will only write my unbiased take on all the practices and tools mentioned, Warp included!
💻 What is coding really about?
When you look at what developers do when they say coding, it’s two main things:
✏️ Writing actual code — in a text editor.
🔨 Running commands — build, execute code, run tests, commit, deploy, etc, in a terminal.
Now, the I in IDE stands for integrated, which means, among other things, that you can do in the editor some of the things you would otherwise do in the terminal. For the most common ones, like building and running code, or git operations, modern IDEs provide native support. For others that are less common, or for those where devs need to see terminal output, IDEs can also embed full-fledged terminal windows.
The latter—terminals inside IDEs—always felt like an afterthought to me, but it kinda made sense because the breakdown of work for a normal developer is probably 80% write code / 20% run commands. So the editor is the star, while the terminal is the sidekick.
And here we get to the crucial point: what if this breakdown changes?