TL;DR: The coding agents developers reach for now — Claude Code, Codex CLI, Aider — are terminal programs, not IDE plugins. That isn’t nostalgia. An IDE is designed around a human at the keyboard; the terminal is designed around processes you don’t babysit. When AI coding shifted from “help me type the next line” to “go do this task and come back,” it moved to the substrate already built for autonomous processes: pipes, backgrounding, logs, exit codes. The IDE still wins for reading and reviewing. The half that became a job left for the terminal.

For a few years the obvious place to put an AI coding assistant was inside the editor. Copilot lived at the cursor; Cursor rebuilt the whole editor around it. Then the coding agents people actually reach for turned out to be terminal programs: Claude Code, Codex CLI, Aider. Not editor plugins. Command-line tools.

It’s tempting to read that as a retro twist. I don’t think it is. It’s the natural consequence of what an “AI coding tool” became.

An IDE is organized around the cursor

Look at what an editor is actually built around: the caret. Completions appear next to it. Diffs show up in the gutter beside the line you’re on. You accept or reject inline, in real time, without your eyes leaving the row.

For “AI that helps me type,” that design is exactly right. The unit of interaction is a small suggestion, small enough to glance at and wave through. The 2021–2022 generation of Copilot was precisely this, and putting it in the editor was the right call. What it did was the thing editors are best at: helping a person edit text at the cursor.

An agent is a job, not a keystroke

Tell an agent to “add proper error handling to the payments module” and it reads a dozen files, works out the structure, proposes a batch of changes, runs the tests, and reworks them when something breaks. That runs for minutes.

The unit changed. A suggestion became a task. And a task wants a completely different set of things than a suggestion does. It wants to run in the background while you do something else. It wants to leave a log you can read afterward. It wants to start in parallel, three at once, each on its own slice. It wants to finish with a clean result, a clear success or failure.

If that wishlist sounds familiar, it should.

The terminal has done this for fifty years

Pipes, redirection, exit codes, backgrounding, &, nohup, tmux. The terminal is, at its core, the place for running processes you don’t sit and watch. Its entire abstraction is built on that premise.

An agent is one of those processes. So Claude Code, Codex CLI, and Aider being terminal programs rather than IDE extensions reads to me like a tool going back to the environment built for it.

The real payoff is composability. In a terminal, a coding agent is just a process. You can git worktree three copies of the repo and run three agents in parallel, each on a different task. You can pipe its output into another tool, wrap it in a shell script, drop it into CI, run it overnight, and keep a log of everything it did. Inside an editor, the agent is a guest in the IDE’s event loop: it can do what the plugin API permits and no more. In the terminal it’s a citizen.

(This is the same shift I wrote about in Claude Code’s dynamic workflows: once the orchestration itself becomes a script you can save and re-run, what you need isn’t a smarter panel but somewhere to run processes. It’s also where the token economics get easier to reason about, since a process you can log is a process you can meter.)

This is not “the terminal wins everything”

Writing this as a clean victory for the command line would be both lazy and wrong.

IDEs still win at several things. Reading diffs: a visual side-by-side with jump-to-definition beats scrolling a unified diff in a pager. Navigation: LSP, go-to-definition, find-references, the things you lean on while checking what an agent changed. Discoverability: a menu is kinder than “you have to know the command exists.” And small inline edits are still typing, which the editor should own.

There’s a fair objection to part of what follows, too. The benchmark scores I’m about to point at track the model more than the harness. Codex CLI and Claude Code rank where they do largely because they ship with frontier models. A leaderboard shows terminal-native tools can sit at the top. It doesn’t prove the terminal is why.

So most people don’t pick one. They run both: dispatch the job in the terminal, keep the editor open to read code and review what came back. The half of coding that became a process moved to the terminal; the half that’s still keyboard-sized stayed in the editor.

Watch where the tools are growing

The most convincing evidence isn’t an argument. It’s which direction the tools are evolving.

Cursor — an IDE-first product, and a good one — added an agent mode and background agents. Its background agents even spin up a cloud VM, work on a branch, and open a pull request. That’s about as “don’t babysit it” as a job gets, and it’s the IDE reaching for the exact shape this whole post is about. Meanwhile the agents at the top of Terminal-Bench are terminal-native — custom harnesses and CLI tools alike — and the IDE-first products don’t appear there at all.

When opposing sides start growing each other’s features, there’s usually something real underneath pulling them together. Here I think it’s the thing above: a chunk of programming quietly stopped being typing and became dispatching work.

Next time you start a task

I won’t pretend this is settled. The tools are still moving and I’d be guessing about where they land in a year. But if you’ve noticed you’re spending more time talking to a terminal and less time accepting suggestions in your editor, that’s probably not an accident.

Next time you open a fresh task, notice which one you’re doing: typing, or handing off a job? If it’s the second, the terminal was always the place for jobs. It’s been waiting for this kind of work for a long time.

Related reading:

Chinese version: AI 寫 code 為什麼又搬回終端機了