The Past: Command Line Insanity
I'm a generalist product manager with a development background spanning over a decade. And I'm drowning in command line interfaces. Every day, I juggle dozens of CLIs:
Build a Java app, offline, in parallel:
mvn clean install -DskipTests -o -s settings.xml -Denforcer.skip=true -T 4
Run an app:
docker run -p 8080:80 -v ./data:/app/data myapp:latest
Find out why something is failing:
kubectl get pods -n monitoring -l app=prometheus -o jsonpath='{.items[0].status.phase}'
Run a sidecar on specific port:
dapr run --app-id secure-app --resources-path ./components --dapr-http-port 3500 --config=./components/tracing-config.yaml --metrics-port 9090 -- tail -f
Sign, commit, push:
checkout -b feature/new-branch
,commit -s -S -m "ABC-123: Fix null pointer exception" --no-verify
,push -u origin HEAD
Redis, psql, Supabase, Netlify, AWS, GCP, Heroku… no, no Heroku.
Everyday utilities:
curl
,ping
,awk
,grep
…
Then I need meta-CLIs to make other CLIs easier to use:
Spring Boot CLI for bootstrapping applications
KNS for navigating k8s namespaces, k9s for visualization
Dozens of custom bash functions in my
.zshrc
to automate routine tasksSome projects (Kafka) don't even have proper CLIs but use bash scripts that pretend to be CLIs
Each CLI has different argument structures. One tool uses -r
for recursive, another spells it out as --recursive
. Some accept --help
, others only -h
. Is it --help
, -h
, -?
, or just help
? Who knows! (I still don't remember how to check the Java version. Is it java -version
or java --version or java version
? )
This situation exists across every tech stack. Backend, frontend, DevOps. While IDEs get more intelligent, Programming as We Know It Ends, CLIs are stuck in time. Not to mention that, in cultural terms, in some teams, developers are often judged by their mastery of CLI commands!
The Present: Disintegrated Assistants
Things are spiralling out of control. The AWS CLI alone has over 360 commands. That's not a CLI—that's a programming language disguised as a command line tool.
But recently, since I've started asking Claude what commands to execute, my productivity has increased noticeably (by myself). I forget a command or flag (happens every five minutes), instead of digging through man pages, I tell Claude exactly what I need – "How do I sign this git commit?" – and it spits out the exact 10 CLI commands to type. This has taken the fear out of exploring new tools. I'm willing to experiment with unfamiliar CLIs now because I know Claude will guide me when I get stuck.
This is just the beginning. The newly released Claude Code can much more.
I can already hear the objections: 'But understanding the CLI is fundamental to understanding the system!' Sure, and understanding assembly is fundamental to understanding CPUs, but we don't write enterprise applications in assembly anymore.
The Future: From Command to Language Interface
Anthropic's introduction of Model Context Protocol (MCP) demonstrated what is possible. MCP is an open standard that lets AI models safely connect to infrastructure and services. In practice, it means I can query or control complex systems by just describing what I want.
For example, an MCP server for Kubernetes allows Claude to get cluster status or troubleshoot issues using plain English. I could simply ask, "Show me the logs for the failing pod in the payment namespace," and the model fetches the logs through Kubernetes' API—no kubectl
command needed from me. Similarly, with MCP integrations for databases like Postgres, I might ask, "How many cancelled orders today?" and the AI runs the appropriate SQL query behind the scenes.
My intent, expressed in natural language, gets translated to the right API calls or CLI commands.
MCP is promising but still clunky and slow(250-500ms round trips). Every request must go to Claude's API and then back locally to execute. What must come next is bring this intelligence local. I'm looking forward to a small language model running on my machine, tuned specifically for CLI translation. Just smart enough to understand my prompt and output a correct command. Because it's running locally, responses would be near-instant and it could securely execute using my installed tools.
The end of CLI as I know it is coming. Not because CLIs will disappear, but because we'll stop interacting with them directly.
The programmer’s expertise will shift from remembering syntax to clearly expressing intent. This isn't the death of CLIs outright – it's the end of CLI as we know it. With all of the multi-modal options for expressing intent (text, audio, images), the CLI is frankly the worst. It's time to move on. The command-line interface must shift from a user-facing tool into behind-the-scenes infrastructure. And I couldn't be happier about it.
Ah, historically, 'cli' stuff just got wrapped up in context.
aka shell scripting -- dump related cli programs in file & run file / dump binary api of OS in program file & run file.
gui programms -- create an application by wraping GUI stuff around 'cli program' inside of a binary file.;
IDE / framework -- wrap set of cli program / gui applications inside of "context framework".
AI -> wrap programs/applications/"human interface " inside of "AI file".