AI coding agents now open pull requests, run test suites, and refactor across dozens of files while you do something else. That makes the terminal look like a relic — a green-on-black holdover from before the IDE, before graphical tooling, before agents existed at all. Sourcegraph is betting the other way. Its Amp agent treats the command line as the place agentic work belongs, and the Neo CLI effort is an attempt to rebuild that surface for an operator who is no longer a person.
This piece looks at why the terminal keeps absorbing AI coding agents instead of being replaced by them, what actually changes when the primary user is software, and what that leaves you doing.
The terminal didn't disappear — agents moved in
We looked at the coding agents that shipped a usable interface over the last two years, and the pattern is hard to miss. Claude Code, OpenAI's Codex CLI, Aider, and Amp itself all run in a terminal. That isn't nostalgia or a shortcut. An LLM reads and writes text, and the terminal is a text-in, text-out interface with a stable contract: a command has stdout, stderr, and an exit code. Output is parseable. The file system is one ls away. A graphical app, by contrast, forces an agent to interpret pixels or scrape accessibility trees for the same information.
The terminal is also composable in a way no GUI matches. Pipes, redirection, exit codes, and shell scripts let an agent chain git, grep, npm test, and cargo build without anyone shipping a custom integration first. Every CLI you have already installed becomes a tool the agent can call. That existing install base — decades of command-line software — is the real reason agents land in the shell.
Amp's framing follows from this: the agent is the product, and the terminal is where it does the work that matters — editing files, running builds, reading logs, reacting to failures. Neo is the bet that the terminal itself should be redesigned around that operator rather than left as-is.
What "rebuilding the terminal" actually means
The terminal we have today assumes a human at the keyboard. Scrollback exists because people scroll. Color exists because people see. Interactive prompts — a sudo password, a y/N confirmation, the editor that pops open mid-git rebase — exist because a person is expected to answer them.
An agent breaks every one of those assumptions:
- It cannot answer an interactive prompt mid-run, so a tool that blocks for input simply hangs.
- It pays for every token it reads, so a build that dumps 40,000 lines of output can swamp both its context window and your bill.
- It needs output it can parse reliably, not text formatted for human eyes.
- It runs with real permissions, so "what is this process allowed to touch" stops being an academic question.
Rebuilding the terminal for agents means flipping the defaults. Non-interactive unless a human is explicitly in the loop. Output that is summarised or structured instead of streamed raw. Commands that fail fast with honest exit codes. A permission boundary the agent runs inside. And observability — a durable record of every command the agent issued, because you are going to review it later. That last point is the one most worth holding onto: the terminal is being treated as agent infrastructure, not as a legacy surface to tolerate.
An agent that hits an interactive prompt does not error — it hangs, silently, until something times out. Before you point an agent at a repository, audit your scripts for blocking prompts: bare
readcalls, an unconfiguredgiteditor, package managers that pause for confirmation. Then run the agent inside a container or sandbox with scoped file and network access. The terminal hands an agent the same reach it hands you, and an agent does not pause to reconsider.
Where this leaves you
The shift here is not human-out. It is a role change. You move from typing the commands to directing and reviewing them — closer to a tech lead reading a junior engineer's pull request than to someone driving the keyboard directly.
The terminal stays central to that because it is the audit log. Every command an agent runs in a shell is text you can read, diff, replay, and reason about after the fact. A graphical agent's clicks evaporate the moment they happen; a CLI agent's session is a transcript. When an agent does something you did not expect — and it will — that transcript is the difference between a five-minute review and an afternoon of guessing.
A few things follow from that in practice:
- Keep the project legible. A clear
README, scripts with obvious names, and fast deterministic tests help an agent for the same reason they help a new hire: less guessing, faster feedback. - Treat noisy tooling as a cost. Verbose output is now a line item on an invoice. Quiet flags, sane log levels, and test reporters that summarise instead of stream pay for themselves quickly.
- Decide where you want the agent to live. Terminal-native agents like Amp, Claude Code, and Codex CLI keep you in the shell. Editor-native tools keep the agent inside the file you are reading.
Neo CLI is one team's answer to a question the whole field is now asking: what does a command line look like when most of its users are software? Amp's wager is that the terminal earned its place by being simple, scriptable, and inspectable — and that those are exactly the properties an autonomous agent needs. You do not have to adopt Amp to take the point. The terminal you have been treating as legacy is quietly becoming the control plane for agentic development.
Originally published at pickuma.com. Subscribe to the RSS or follow @pickuma.bsky.social for new reviews.
Top comments (0)