When engineers hear “legacy,” their first instinct is usually to hide it. Andrej Karpathy went the other way and made it the selling point:

CLIs are super exciting precisely because they are a “legacy” technology, which means AI agents can natively and easily use them, combine them, interact with them via the entire terminal toolkit.

Not “CLIs are old, but they still work.” It’s “CLIs work because they’re old.” Mogu would boil it down to something more shareable: CLI is the native language of agents.

Native means no interpreter needed

Karpathy only gave the conclusion. What follows is Mogu’s reading of it. To an agent, a human GUI is a foreign language. Where’s the button? Should that popup be closed? How far down do I scroll this table? Everything starts with “understanding the screen,” and then turning that understanding into an action. There’s a layer of translation in the middle.

CLIs don’t have that layer. The command is text, the flags are text, --help is text, the output is text, even the errors are text. What the agent reads in and what it writes out are the same kind of thing. Karpathy’s “entire terminal toolkit” takes it one step further: one command’s output can feed straight into the next. Filter with grep, pick apart with jq, keep piping. Once you know the words, you can build your own sentences.

Mogu , seriously:

As for why agents are “born” speaking this language, Karpathy just says “natively” and leaves it there. My guess: the terminal is probably one of the most heavily written-about interfaces humans have ever had. Decades of man pages, scripts, tutorials, and forum Q&A, all plain text, all in roughly the same format. In the pile of stuff these models were trained on, example sentences in this language are everywhere.

That’s my inference, not something Karpathy said. But if it holds, the “old” in “legacy” is really decades of accumulated teaching material.

About three minutes: the CLI supplies the words, the agent writes the sentences

Karpathy’s example was a tool that had just shipped. That same day, @SuhailKakar released the Polymarket CLI, written in Rust and pitched by its author as the fastest way for AI agents to access prediction markets: agents can query markets, place orders, and pull data, all from the terminal.

Karpathy’s suggestion: ask your Claude or Codex agent to install this CLI, then ask for any arbitrary dashboards, interfaces, or logic, and the agent will build it for you. His own example was a terminal dashboard Claude built in about 3 minutes, showing the highest-volume Polymarket markets and their 24-hour change. He added two more points: you could make it a web app instead, and it gets even more powerful when you use it as a module in bigger pipelines.

He also called out the GitHub CLI: install it, and you can have the agent navigate a repo, look at issues, PRs, and discussions, even read the code itself. He’d previously shown handing an agent the GitHub CLI plus an MCP service that answers questions about repos, then letting it dig the functionality he needed out of someone else’s library (see MP-66).

The most interesting part of this example isn’t the three minutes. The Polymarket CLI’s author didn’t build that dashboard, and never had to anticipate that someone would want “top markets by volume plus 24-hour change.” The CLI just has to provide a full set of words — query markets, pull data — and the agent writes the sentences. The interface author doesn’t have to guess what screens users want, and that’s what really makes CLIs agent-friendly (that’s Mogu’s take).

There’s also a small twist: the “legacy technology” in the example was a brand-new Rust tool released that very day. So when Karpathy says “old,” he means the shape of the interface — text in, text out, composable — not the age of the software.

Does your product speak the agents’ language?

After the example, Karpathy turned the question back on the people building products:

If you have any kind of product or service think: can agents access and use them?

  • are your legacy docs (for humans) at least exportable in markdown?
  • have you written Skills for your product?
  • can your product/service be usable via CLI? Or MCP?
  • …

It’s 2026. Build. For. Agents.

The three questions map neatly onto three levels of the same language.

Can your docs become markdown? That’s about letting agents read. If your docs are locked behind logins and layers of menus, the agent has to wrestle with all those screens first. Karpathy has been making this argument for a while: in his June 2025 talk at YC’s AI Startup School, he talked about building for agents and converting human-facing docs into formats LLMs can read (see MP-116). This time he brought a three-minute example.

Skills are instructions written for agents. A Skill is a folder built around a SKILL.md file of instructions, optionally bundled with scripts and reference material, that teaches an agent how to do a certain kind of task or use a certain tool; the agent only loads it when needed. In native-language terms, it’s the phrasebook: beyond the vocabulary, it tells the agent how things are idiomatically said in this particular product.

CLI or MCP is what lets the agent speak up and actually do things. Karpathy wrote “CLI? Or MCP?” — he didn’t say it has to be a CLI. And the ellipsis at the end of the list means he wasn’t trying to be exhaustive.

Mogu inner monologue:

Of the three, the one I’d push hardest is markdown, because it’s the least sexy and the cheapest. A CLI means designing commands, MCP means standing up a server, but making your docs exportable as markdown is often a single button. And it’s the foundation for the other two: if an agent can’t even read your docs, the best tools in the world just leave it groping around in the dark.

Full disclosure: gu-log’s own writing workflow is a CLI (gp-pipeline) paired with a SKILL.md. The agent reads the instructions and runs commands in the terminal. This very rewrite was done by an agent reading and writing files in a terminal. As it happens, this blog has turned in answers to all three of Karpathy’s questions (⁠￣⁠▽⁠￣⁠)⁠／

Once agents speak the language, the next question is permissions

Make your product something agents can talk to — that’s where Karpathy’s post wraps up: “Build for agents.”

But look back at the example he picked. The Polymarket CLI’s vocabulary doesn’t just include “query markets” and “pull data.” It also includes “place orders.” The more fluent an agent gets, the more sentences it can say, including the ones that move money. The post doesn’t touch this. Mogu thinks it’s the question that comes right after “can agents use it?”, and one every product builder will have to answer sooner or later: which words should agents only be allowed to read, and which should they be allowed to say?

Further reading: