A centre of gravity that quietly shifts
Anyone who learned to program in the last twenty years learned to do it inside an IDE. One window where everything lives: the editor, the file tree on the left, the console at the bottom, the debugger with its breakpoints, the context menu offering "Rename Symbol" and "Extract Method", the little green play button up in the corner. The command line was the place you switched to when the GUI couldn't do something – a relic for purists and server admins, not somewhere serious work happened.
That ordering is tipping over, and it's doing it quietly. Not because anyone declared the IDE dead, but because a new kind of tool has moved into daily practice: the AI coding agent. And that agent doesn't work in panels and buttons. It works in text, in files and in shell commands. It doesn't click "Extract Method" – it writes a diff. It doesn't press the play button – it types npm test. The natural habitat of an agent is exactly the place the IDE spent twenty years pushing to the margins: the terminal.
This isn't a nostalgic return to green text on a black screen. It's a sober observation about which interface a machine finds easiest to operate. And the answer, fairly unambiguously, is the command line.
Why the IDE won in the first place
It's only fair to start here, because the IDE earned its victory. It solved three problems that the bare command line fails to solve for most people.
The first is discoverability. In an IDE, you can see what you're able to do. Menus, context actions, autocomplete, the little lightbulb offering a quick fix – all of it shows a human the next possible step without requiring them to know it by heart. The command line does the opposite: it shows you a blank prompt and expects you to know the incantation already. For a beginner, that's a wall.
The second is the integrated debugger. Clicking a breakpoint into the margin, pausing the program, stepping through the lines, inspecting the state of your variables as an expandable tree – this is one of the few genuine superpowers of the GUI. A visual debugger makes state visible, and visibility is precisely what a human needs to understand why a program is misbehaving.
The third is refactoring as UI. "Rename Symbol" across fifty files, "Find All References", "Go to Definition" – the IDE understands code as a structure, not as text, and offers operations that respect that structure. For years this was an argument the command line had little answer to.
These three strengths are real, and they explain how VS Code became the dominant tool of an entire generation. But – and this is the point – all three are tailored to a human operator. Discoverability helps someone who doesn't know what's possible. An expandable state tree helps a pair of eyes. A context menu helps a hand on a mouse. The moment the operator is no longer a human but a model, those very advantages evaporate.
Why agents prefer the terminal
An AI agent has no eyes and no mouse. It has a text input and a text output. And the command line is the one interface in the whole of software that was built from the ground up for exactly that: text in, text out.
That's not a small advantage, it's the entire advantage. An agent like Claude Code needs no rendered surface, no DOM, no click target with coordinates. It composes a command as a string, sends it to the shell, and reads the result back as a string. git diff, grep -r "TODO", pytest tests/, ls -la – every one of those answers is text a model can process directly. A GUI it would first have to laboriously "see", interpret, and operate with simulated clicks. The terminal skips that whole intermediate step.
Then there's uniformity. In the Unix world every tool is a command with the same grammar: arguments in, text out, an exit code that reports success or failure. Whether the agent runs tests, searches the repository, installs a package or starts a container – the shape is always the same. There's nothing new to learn per tool, no hundred different GUI dialects, no buttons whose position shifts with the next update. A command is a command. For a model that has learned from millions of shell sessions, this is the most familiar language there is.
And then there's git. An agent's entire workflow – proposing changes, making them visible, reviewing them, backing them out – lives in git, and git is at heart a command-line tool. A diff is text. A commit is text. A branch is a name. The agent needs to know nothing about a graphical merge view; it works in exactly the representation that version control already exists in. The GUI layers on top of git are a convenience for humans – the actual model underneath is textual, and therefore agent-native.
Perhaps the most underrated point: the terminal works everywhere. Over SSH on a server, in a CI pipeline with no screen, in a container, in a cloud VM you never lay eyes on. An IDE needs a desktop, a window, a human in front of it. A terminal-native agent runs on a machine that renders not a single pixel. And that opens up possibilities that simply don't exist with a GUI – more on which in a moment.
What changes for the human
It gets interesting at the point where the human doesn't disappear but changes role. In the classic IDE model the human was the operator: they typed the code, clicked through the menus, set the breakpoints, pressed play. The machine was the passive tool, the human the active hand.
In the agent-first model that inverts. The agent types, searches, edits, runs. The human directs and reviews. They frame the intent in prose, let the agent produce a proposal as a diff, and then their real work is this: read that diff, understand it, accept it or throw it out. The centre of human attention shifts from typing to reading, from producing to judging – a movement we've described at length elsewhere: review becomes the core discipline.
What that means for tool choice is concrete. Someone who spends the whole day reading diffs and issuing commands to an agent no longer spends their time in the structure the IDE was built for – manually editing individual lines. They spend it in a dialogue: prompt, diff, review, next prompt. And that dialogue lives most naturally where the agent lives – in the terminal, or in a lean surface that wraps the terminal without replacing it. The heavy GUI machinery of the classic IDE – the refactoring assistant, the toolbar, the project explorer – doesn't become wrong in the process, but it drifts to the edge of the field of view. You still use it, just not constantly.
The real argument: composability
Clear everything else away, and one argument is left standing that weighs more than all the others combined: composability.
The command line is not a collection of isolated tools. It's a grammar for chaining tools together. The output of one becomes the input of the next – this is the classic Unix pipe philosophy, and it's over fifty years old: small programs that do one thing well, joined by a simple stream of text. git log --oneline | grep fix | wc -l is not a tool anyone built – it's a sentence you form in the moment, out of parts that were never made for each other. That very ability, to assemble new tools from old ones on the fly, is something no GUI has ever reproduced.
For agents this is the decisive lever, and for a very practical reason: an agent that works in the terminal can be automated. It's a process that takes text and returns text, and anything of that shape can be dropped into a script, wrapped in a loop, hung off a pipeline. You can run an agent headless in CI – with no screen, triggered by a commit landing on a build server no human ever looks at. You can start it over SSH on a remote machine and have it finish a task while your own laptop is shut. You can pipe its output into the next tool; its exit code decides whether the pipeline carries on.
None of that is possible with an agent bolted into a GUI. A tool that only runs when a human opens a window and clicks a button is, by definition, not automatable. It's chained to a human hand. That's the deep reason the terminal is the most model-friendly interface there is: not because it's old or looks cool, but because it's the only one that a human can type, a script can call, and an agent can drive – and all three do it in the same language.
A VS Code window with an embedded agent extension is convenient as long as a human is sitting in front of it. A CLI agent is a line in a script. Only one of the two can be launched a hundred times in parallel across a fleet of servers without anyone clicking a hundred times.
The honest other side
Now the point at which you have to be careful not to push the lesson too far. The terminal is not simply better. It's better for one particular, very important thing – driving agents – and worse for several others that don't vanish just because a model is typing the code.
Visual debugging remains superior in the GUI. When a program misbehaves and you don't know why, there's little more efficient than a breakpoint, a pause mid-run, and an expandable state tree. Reconstructing that in your head or with print statements is possible, but honestly more laborious and slower. Making state visible is a strength of the surface, not the line.
Large diffs are better read in a GUI. A 40-line diff in the terminal is pleasant. An 800-line diff across twelve files, with moves and renames, is a punishment in the terminal – and it's precisely those large diffs an agent is fond of producing. A side-by-side view with syntax highlighting, collapsible blocks and an overview of every affected file is, at that point, not a convenience but a genuine advantage for understanding. And understanding, as noted above, is the resource that's actually scarce.
Newcomers learn faster in the IDE. Discoverability was a real advantage and it has stayed one. Sitting someone down at a blank command line and wishing them luck is not a virtue, it's an obstacle. The GUI that shows you the next possible step is simply the friendlier place to onboard.
And that's why "terminal purism" is a trap of its own. Forcing everything into the shell on principle, because it's somehow purer, trades productivity for ideology. The honest answer is not either/or but hybrid: IDE extensions that embed the agent where the human already works, and marry the visual strengths of the GUI – diff view, debugger, navigation – with the textual nature of the agent. That's exactly the direction the tools are heading, and it's the right direction. What we're describing is a shift in the centre of gravity, not the death of the IDE. The centre of daily work drifts towards the terminal, because that's where the agents live – but the IDE keeps everything it honestly does better for the human.
Conclusion
The IDE absorbed everything for twenty years because it was the tool of a human operator, and humans need visibility, discoverability and clickability. AI coding agents shift the centre of gravity back to the terminal, because they are not a pair of eyes and a mouse but processes that take text and return text. The command line didn't become important again because it's fashionable, but because it's the most composable, scriptable, model-friendly interface software knows – and the only one a human, a script and an agent can all operate in the same language.
At NH Labs we therefore work agent-first in the terminal. Not out of nostalgia and not out of purism, but because an agent that is a line in a script can be automated, triggered headless in CI, and launched over SSH in parallel across a whole fleet of servers – and an agent bolted into a GUI cannot. At the same time we keep the IDE for exactly what it's best at: setting a breakpoint, reading a large diff at leisure, showing a new colleague the way. The terminal is not better than the IDE. It's the better place to direct machines – and that's what programming is increasingly about.