The Terminal as an API

I spent the better part of an hour today bantering with my colleague about why Postman CLI is getting so much attention, and somewhere in the middle of it I realised I had never written the argument down. So this post is that argument.

It starts with something fairly mundane: the command line in your computers. And with the possibility that, for forty years, we may have misunderstood what was wrong with it.

Read more: The Terminal as an API

What did we lose to technological evolution?

Open a terminal and type ls. Open Finder (or Windows Explorer) and look at the same folder. Both show you your files. The latter simply is wearing a better suit! Now try something slightly less ordinary, but quite plausible: find every PDF in this folder that has the word invoice in it. Keep only the ones created in leap years.

In a terminal, this is not a particularly intriguing problem. You compose a few things together and you are done. Nobody who built the operating system had to imagine that one day somebody would care about PDFs created in leap years!

That is the important bit.

In the terminal, using the computer was also a form of programming. The software gave you primitives. You arranged them into outcomes. Composition was not a feature added later for power users, it rather was the substrate. We traded much of that away when software became graphical. Though, I think, it was the correct trade for the times.

The problem with the command line was never really typing. It was memory — your memory. Not merely whether you remember a command correctly, but whether you can summon the right scrap of semantic knowledge, connect it to an episodic recollection of having used it before, and draw upon whatever procedural fluency you’ve acquired through sheer repetition. A command line tells you almost nothing about what it can do. You need to remember the command, its syntax, its flags, the order of arguments, and often a pile of conventions peculiar to that tool. The interface lives largely inside your head.

Graphical software moved that memory into the software. A button tells you that an action exists while a menu exposes capabilities you did not know were there. An empty state can teach you what to do next. Essentially, the software began explaining itself.

When Postman was built back in 2012, it started by making something as fundamental as an HTTP request legible. Over time came collections, specifications, mocks, monitors, collaboration — eventually a place where a team’s API work could accumulate somewhere another person could open, understand and continue. A lot of software followed the same arc: build the capability, then build the interface that makes it understandable, then build solutions that become possible because those capabilities are now living together somewhere coherent.

But something was lost along the way — the same programmability that had made computers so powerful became expensive and relegated to us, the software builders.

Once you descend into a graphical interface, every useful permutation becomes something somebody has to imagine and somebody designs it. Somebody decides where it lives and then builds the state around it. Somebody tests it, delivers it and yet again somebody else explains and sells it.

So over the years we started buying programmability back into GUIs. Workflow builders, Node editors, Programmable canvases, Visual languages. A great deal of ingenuity had gone into recovering a property Unix pipes had made commonplace decades earlier. Heck, Bret Victor made that his life’s mission with Learnable Programming, and yes, he was a source of inspiration for Postman Flows.

A small number of primitives can produce a very large number of behaviours.

~me!

This is the reason why a tiny command-line tool can sometimes feel disproportionately powerful next to a much larger graphical product. The builder does not need to anticipate every outcome. The user does the arranging. The entire cost of that power is paid in memory and for decades, that cost of using command-line tools was too high for most people.

Then it suddenly collapsed.

The constraint that disappeared

The interesting thing AI changed was not simply that computers became better at generating text or code.

It removed a human constraint from software.

You no longer need to remember whether the flag is --output, -o, --format, or something somebody thought was clever in 2007. The agent remembers.

More importantly, it can discover. It can read the help text, inspect the output, recover from an error and try again. Not infallibly — goodness knows agents can invent a command with as much conviction as a human can misremember one. But they can go looking for the answer rather than needing to have carried it in their head all along.

And the moment that became possible, a very old interface acquired a completely new property. All the programmability we had hidden behind human memory suddenly became accessible again.

Without a new canvas; without another visual builder, and hopefully, without anybody designing the leap-year-PDF workflow!

This is the sentence I keep coming back to: The terminal is an API for the agents running on your computer.

Once you look at it that way, quite a few things stop looking accidental. Take the GitHub CLI for instance. For many humans, opening the GitHub website or using a Git App was often easier than remembering the command.

For an agent already sitting inside a repository, the opposite is true.
The repository is here.
The files are here.
The local server is here.
The command is here.
The agent can invoke it, inspect the response and continue.

The CLI did not suddenly become dramatically better. It now acquired a caller whose limitations mated better with it than ours ever did.

There is another accident of history here. Command-line tools never really disappeared. They could not, simply because some work always happened without human triggers, in the form of automations. So while most product attention moved towards graphical interfaces, serious software tools quietly retained the command-line surface: scriptable, composable.

We now have an enormous amount of software already shaped rather well for agents. Entirely by accident.

Old interfaces, new economics

I can already hear the objection. Why the terminal, though? Why not an API or one of the new agent-facing protocols? And surely a shell command, with its capricious output and occasionally terrifying side effects, is a rather questionable API?

Quite right. Sometimes a structured API or an MCP server is the better interface. The terminal is not special because it is technically purer. Far from it. It is special because it is already here, close to what runs your computer, the Operating System — in the repository, beside the source code, the build tools, the local server, the configuration and a thousand other capabilities assembled over decades. The agent finds itself in the middle of this rather untidy, extraordinarily useful workshop. Why would it not use what is lying about?

None of this means everything becomes a CLI. That would be a particularly boring conclusion.

Humans still need graphical software. We need legibility. Exploration. Collaboration. Direct manipulation. Shared state. And agents, for all their newfound facility with commands, still need permissions, reliable results and a way to know when they’ve made a mess.

The interesting shift is not GUI to CLI. It is that we now have a caller capable of moving between these surfaces. The agent does not care about the taxonomy. It cares whether it can reach the capability it needs. And that changes some of the economics of software design.

For years, a great product experience meant anticipating more of the user’s journey. What will they want next? What flow should we build? What permutation deserves a button? Agents make another strategy viable again:

Build strong primitives, make them legible to machines, explain why they exist, and let the operator compose.

That is a very old idea. It just looks new because the person doing the composing is no longer always a… person.

The terminal never stopped being programmable. We looked at it for forty years and saw an interface that demanded too much from its user.

Perhaps the stranger truth is that it was waiting for a different user.

Now that user is here.

Leave a Reply