The CLI Is Having a Second Life

1

AI coding agents are making command-line tools easier to use — and developer-tool companies are starting to design for it.

For a long time, command-line tools had a simple trade-off: they were fast, scriptable, and powerful, but you had to learn them first. A dashboard could show you a button that said Deploy. A CLI expected you to know whether the command was wrangler deploy, vercel deploy, railway up, or something else. Then came the flags, authentication, config files, and the inevitable trip to the docs when something failed.

LLMs have changed that trade-off in a surprisingly practical way. The command line itself did not become easier; we simply gained a layer that is very good at translating intent into commands. Instead of searching for the right command, I can tell a coding agent, “Check why the latest deployment failed.” If the tool is available in the environment, the agent can inspect the project, run --help, find the right command, read the output, and keep going. What looks like a small convenience starts to feel more significant when the same pattern works across deployment tools, databases, cloud platforms, package managers, and infrastructure CLIs.

The CLI is gradually becoming an interface for both humans and agents.

The biggest weakness of the CLI was discoverability

Developers have always liked CLIs for good reasons. Commands are deterministic, they work well in scripts and CI, they compose with other programs, and they usually map closely to the underlying platform. The painful part was remembering how to use them.

Take Kubernetes. kubectl get pods -n production is perfectly reasonable once you already understand kubectl, but it is not something a new user would naturally guess. The same applies to most cloud platforms: you may understand exactly what you want to do without knowing the command that does it.

LLMs are unusually good at filling that gap. They can read documentation, inspect --help, edit configuration files, understand shell output, and try the next command when the first one fails. The developer still needs to understand what a deployment, migration, namespace, or rollback actually means, but there is much less reason to memorize the syntax.

That changes the economics of building a CLI. It used to be an interface that a developer had to actively learn. Now it can also be an execution surface that an agent learns on the developer’s behalf, and some developer-tool companies are clearly starting to design around that idea.

Cloudflare is making the agent a first-class CLI user

Cloudflare is probably the clearest example. Its current agent setup documentation has dedicated guidance for tools such as Codex, Claude Code, Cursor, and GitHub Copilot. It does not present MCP, agent skills, and the CLI as competing approaches. Instead, it explains how they work together.

Wrangler is still the tool Cloudflare recommends for local development, deployments, migrations, logs, and Workers-specific operations. The interesting part is that Cloudflare also ships a Wrangler skill that teaches an agent when it should use the CLI.

Cloudflare is now developing a broader cf CLI as well. In the same documentation, the company describes the technical preview as having consistent verbs and “ergonomic output for agents.” Machine-readable output has existed forever, and CI systems and shell scripts have always benefited from predictable commands. What is different here is the product assumption. When a major infrastructure company explicitly talks about designing CLI output for agents, it suggests that the person typing the command is no longer the only user that matters.

Cloudflare is doing something similar with its documentation. Its docs can be fetched as Markdown, and top-level product sections expose llms.txt files intended to give agents token-efficient references. The product surface is no longer just dashboard + API + docs; there is an additional agent-readable layer around all of them.

Railway is going even further

Railway’s direction is even more explicit. In April 2026, Railway announced a Remote MCP server, a Railway Agent inside the CLI, and one-command installation of agent skills. Their framing was straightforward: if an agent can write the code, it should be able to ship it too.

The CLI gained a railway agent command. Railway skills can be installed for Claude Code, Cursor, Codex, and OpenCode, while the MCP server gives compatible agents another structured way to interact with the platform.

A month later, Railway described improvements where its agent skills could switch between MCP tool calls and CLI calls depending on the user’s setup. That is a useful detail because it shows how little the agent needs to care about interface boundaries. It does not need a preference for MCP or CLI; it can simply use whichever surface is appropriate for the task. From the developer’s perspective, the distinction starts fading because the request is expressed in terms of an outcome while the agent chooses the mechanism.

Supabase is designing the CLI around agent behavior too

Supabase provides another good example because it has documented some of the failure modes directly. In its post announcing Supabase Agent Skills, the company says agents often know a lot about Supabase but still use it incorrectly. They may rely on outdated training data, invent CLI commands that do not exist, or miss security requirements.

Their solution is not to remove the CLI. The Supabase skill explicitly teaches agents to use --help instead of guessing commands, and it also explains when an agent should use the CLI and when it should use Supabase's MCP server.

The current Supabase CLI reference makes the direction even more obvious. The CLI has a global --agent option for agent detection, alongside output options for json, toml, and yaml. Structured output, help commands, and non-interactive software are not new ideas, but the audience is changing. Features that once mainly made a CLI pleasant for automation now also make it pleasant for an AI coding agent.

Supabase has gone far enough to build evaluations around this. In July 2026, it open-sourced a benchmark for measuring how coding agents perform on real Supabase tasks. The company describes agents as increasingly interacting with Supabase through its CLI, MCP server, skills, and documentation, which gives a fairly concrete picture of where this interface layer is heading.

Vercel is turning CLI commands into agent workflows

Vercel has taken a slightly different approach. In January 2026 it introduced vercel api, a CLI command that exposes Vercel's APIs from the terminal. Vercel explicitly says the command provides a direct access point for AI agents and notes that an agent with access to the environment and Vercel CLI can work with the user's existing permissions.

That removes an entire integration step. The agent does not necessarily need a custom Vercel integration just to perform an operation. If the developer is already authenticated in the CLI, the agent has a usable interface sitting in front of it.

Vercel also publishes CLI Workflows that show how several commands fit together into real tasks such as debugging production errors, rolling back deployments, managing environment variables, working with domains, or investigating slow functions. These guides are explicitly designed to help AI agents learn not only individual commands but also the reasoning that connects them.

The distinction is useful: an API describes what operations exist, a CLI describes how to invoke them, and a workflow teaches the agent how an experienced developer combines those operations to solve a problem. Vercel also publishes an llms-full.txt version of its documentation for large language models, so the documentation itself is becoming part of the machine interface.

MCP does not make the CLI obsolete

With MCP becoming popular, it is tempting to think that agents will eventually stop using CLIs and talk directly to MCP servers instead. I am not convinced, mainly because coding agents already live close to the shell.

They need to run builds, tests, Git commands, package managers, database migrations, and local development servers. They need access to files and environment configuration. The terminal is already part of their working environment, so a CLI remains a natural execution surface.

A CLI also has one major advantage: companies have spent years encoding product behavior into it. Authentication works, project discovery works, configuration loading works, error handling exists, the commands are documented, and CI often already depends on them. Throwing all of that away simply because MCP exists would make little sense.

What we are seeing from Cloudflare, Railway, Supabase, and Vercel is more pragmatic. MCP can be used where a structured remote interface is useful, while the CLI remains useful for local development, repository-aware workflows, deployments, and existing shell-based automation. An agent can move between both without the developer having to care much about which interface was chosen.

A good CLI now has two users

This changes what good CLI design looks like. Humans like colors, interactive prompts, progress bars, tables, and helpful terminal interfaces, while agents care more about predictable behavior. They benefit from stable commands, useful exit codes, non-interactive modes, structured output, clear error messages, and a way to preview destructive operations.

A command like:

mytool projects list --json

has become more valuable, and so have flags such as:

--json--yes--non-interactive--quiet--dry-run

These features were already good engineering practice. The difference is that there is now another important consumer of them.

The same is true for documentation. A beautiful documentation website is useful to a person, while an agent may prefer the same information as Markdown. A concise --help command can be more useful than a tutorial, an llms.txt file can make documentation easier to discover, and a small agent skill can explain the product-specific rules that the model should not guess. None of this requires rebuilding the entire product around AI; it mostly requires exposing the product in ways that software can reliably understand.

The learning curve did not disappear

There is still an important downside to all of this. It is easy to confuse not knowing the command with not needing to understand the system, but those are very different things.

I do not need to remember the exact syntax for rolling back a deployment, but I should still understand what a rollback does. I do not need to memorize every database migration command, but I should still understand whether the agent is about to modify production data. I do not need to know every Cloudflare or Railway flag, but I should still understand the infrastructure the agent is changing.

LLMs reduce the syntactic learning curve much more than the conceptual one, and that is probably the healthier version of this shift. We can spend less time remembering command names and more time understanding the systems behind them.

A new question for developer tools

There is a question I think more developer-tool companies will start asking: Can an agent use our product without opening the dashboard?

That question quickly turns into more concrete ones. Can the agent install the CLI without getting stuck in an interactive setup? Can it discover commands using --help? Can it request JSON instead of parsing a pretty table? Can it authenticate safely, understand an error well enough to recover, perform a dry run before doing something destructive, and read the documentation without scraping a JavaScript-heavy website?

A few years ago, these would mostly have been questions about automation and CI. Now they are increasingly product questions as well.

There is something slightly ironic about the result. Natural-language interfaces were supposed to make old interfaces disappear, but they may instead give one of computing’s oldest interfaces a second life. The developer speaks natural language, the agent speaks CLI, and the command line finally has a translator.

Sources

• Cloudflare — Codex + Cloudflare: Agent setup
• Cloudflare — Wrangler commands
• Railway — Remote MCP, Railway Agent in the CLI, one-command skills install
• Railway — CLI and agent skills improvements, May 2026
• Supabase — AI Agents Know About Supabase. They Don’t Always Use It Right.
• Supabase — CLI Reference
• Supabase — Introducing Supabase Evals
• Vercel — Introducing the vercel api CLI command
• Vercel — CLI Workflows
• Vercel — Agent Resources