This feels completely speculative: there's no measure of whether this approach is actually effective.
Personally, I'm skeptical:
- Having the agent look up the JSON schemas and skills to use the CLI still dumps a lot of tokens into its context.
- Designing for AI agents over humans doesn't seem very future proof. Much of the world is still designed for humans, so the developers of agents are incentivized to make agents increasingly tolerate human design.
- This design is novel and may be fairly unfamiliar in the LLM's training data, so I'd imagine the agent would spend more tokens figuring this CLI out compared to a more traditional, human-centered CLI.
Yeah, people seem to forget one of the L's in LLM stands for Language, and human language is likely the largest chunk in training data.
A cli that is well designed for humans is well designed for agents too. The only difference is that you shouldn't dump pages of content that can pollute context needlessly. But then again, you probably shouldn't be dumping pages of content for humans either.
That's how artificial this "intelligence" is, when LLMs can't even use text based tools full of txt based documentation formatted coherently without those very tools being adapted.
I like CLI tools with json output that can be piped through jq. I've seen llms do that with existing tools.
The human needs and llm needs seem to overlap, especially if the human is using scripts and piping between tools.
The number of times it implies you didn't need to validate "human" input until llms arrived is scary too.
I'm also surprised to hear them say llms shouldn't Google, as that seems an area that Google themselves could optimize their search service for their llms and get an advantage.
Finally, I wonder if just using older, smaller llms is a valid fuzzing approach for clis (or anything else llms might be controlling). Or do you need a high powered llm trained to generate adversarial input?
With all due respect, but if humans can figure out how new unseen programs work by using -h and seeing what options exist and what they do, I am sure robots can figure it out too, or else they weren’t that intelligent to begin with.
No. Nope. Agents do just fine with all sorts of CLIs. Old standards, new custom stuff, whatever.
The CLIs I’ve seen agents struggle with are those that wrap an enormous, unwieldy, poorly designed API under one namespace. All of Google Workspace apis, for example.
Human DX optimizes for discoverability and forgiveness.
Agent DX optimizes for predictability and defense-in-depth.
These are different enough that retrofitting a human-first CLI for agents is a losing bet.
> The real question: what does it actually look like to build for this?
What was the not-so-real question? Or the surreal question?
I know it's becoming tiresome complaining of slop in HN. But folks! Put a bit of care in your writing! It is starting to look as if people had one more agent skill "write blogpost", with predictable results, as we are not a Python interpreter putting up with meh-to-disgusting code but actual humans with real lives and a sense of taste in communication
And for more persistent services, worth considering using varlink, for your agents sake and just if you need two cli thinks to chat.
https://varlink.org/
The systemd universe is moving this way from dbus, and there doesn't seem to be a ton of protest against giving up dbus for json over unix sockets. There's really not that many protocols that are super pleasant for conversing with across sockets.
I love how AI gave the command-line and TUI interfaces a kind of Second Renaissance. It is not just AI that loves CLIs. It is especially blind people like me, who still use a lot of text-mode tools for their implicit accessibility. I gave codex a whirl recently, and hey! No accessibility problems at all. Just works. A few years back, that would have been released as a GUI-only program and would have locked me out completely[1]. A blessing that text oriented interaction is becoming important again!!!
1: Strictly speaking, there are ways to access some GUI programs on Linux with a screen reader. However, frankly, most are not really a joy to use. The speed of interaction I get from a TUI is simply unmatched. Whenever I work with a true GUI, no matter if Windows, Mac or Linux, it feels like I am trying to run away from a monster in a dream. I try to run, but all I manage to do is wobble about...
A second renaissance? The entire time internet had been running on CLI. All modern services relying om containers rely on images based on CLI. There is no renaissance needed because it never stopped.
I write my tools for humans, without help or use of AI. If the AI agent wants to use my tool so bad, they need to rise to that level. I'll not crouch on my knees to meet it.
If I ever write a tool for AI interaction, I'd give it a well-defined API, to make it even easier for the agent.
This feels completely speculative: there's no measure of whether this approach is actually effective.
Personally, I'm skeptical:
- Having the agent look up the JSON schemas and skills to use the CLI still dumps a lot of tokens into its context.
- Designing for AI agents over humans doesn't seem very future proof. Much of the world is still designed for humans, so the developers of agents are incentivized to make agents increasingly tolerate human design.
- This design is novel and may be fairly unfamiliar in the LLM's training data, so I'd imagine the agent would spend more tokens figuring this CLI out compared to a more traditional, human-centered CLI.
Yeah, people seem to forget one of the L's in LLM stands for Language, and human language is likely the largest chunk in training data.
A cli that is well designed for humans is well designed for agents too. The only difference is that you shouldn't dump pages of content that can pollute context needlessly. But then again, you probably shouldn't be dumping pages of content for humans either.
Surely the skill for a cli tool is a couple of lines describing common usage, and a description of the help system?
Sure, but the post itself brags,
> gws ships 100+ SKILL.md files
Which must altogether be hundreds of lines of YAML frontmatter polluting your context.
You don't need to install all of them.
That's how artificial this "intelligence" is, when LLMs can't even use text based tools full of txt based documentation formatted coherently without those very tools being adapted.
Some of this seems a bit overhyped.
I like CLI tools with json output that can be piped through jq. I've seen llms do that with existing tools.
The human needs and llm needs seem to overlap, especially if the human is using scripts and piping between tools.
The number of times it implies you didn't need to validate "human" input until llms arrived is scary too.
I'm also surprised to hear them say llms shouldn't Google, as that seems an area that Google themselves could optimize their search service for their llms and get an advantage.
Finally, I wonder if just using older, smaller llms is a valid fuzzing approach for clis (or anything else llms might be controlling). Or do you need a high powered llm trained to generate adversarial input?
The article states that agents work better with JSON than documented flags - that seems counterintuitive . How is this assumption validated?
Try building a CLI with a complex JSON as flags approach. :)
With all due respect, but if humans can figure out how new unseen programs work by using -h and seeing what options exist and what they do, I am sure robots can figure it out too, or else they weren’t that intelligent to begin with.
“Need”?
Why would I need to do that?
Someone else might ”want” me to do that but it’s not a ”need” I have. I don’t see the article making a good case for that.
cliwatch.com, creating some benchmarks, reach out if you are interested :)
Are we reinventing RPC again? Calling CLI program with JSON sounds like RPC call. The schema feels likes something LSP can provided for such function.
Maybe asking agent to write/execute code that wraps CLI is a better solution.
Confused? You won't be, after this week's episode of https://en.wikipedia.org/wiki/SOAP.
Everything old is new again...
Doesn't powershell have structured input and output?
I'm working on a CLI now.
The pattern I used was this:
1) made a docs command that printed out the path of the available docs
$ my-cli docs
- README.md
- DOC1.md
- dir2/DOC2.md
2) added a --path flag to print out a specific doc (tried to keep each doc less than 400 lines).
$ my-cli docs --path dir2/DOC2.md
# Contents of DOC2.md
3) added embeddings so I could do semantic search
$ my-cli search "how do I install x?"
[1] DOC1.md
"You can install x by ..."
[2] dir2/DOC2.md
"after you install..."
You then just need a simple skill to tell the agent about the docs and search command.
I actually love this as a pattern, it work really well. I got it to work with i18n too.
I do not.
No. Nope. Agents do just fine with all sorts of CLIs. Old standards, new custom stuff, whatever.
The CLIs I’ve seen agents struggle with are those that wrap an enormous, unwieldy, poorly designed API under one namespace. All of Google Workspace apis, for example.
Title is a little clickbait, but not really! :)
---
Human DX optimizes for discoverability and forgiveness. Agent DX optimizes for predictability and defense-in-depth. These are different enough that retrofitting a human-first CLI for agents is a losing bet.
Why are you calling it "AI" if it can't even parse a goddamn man page?
> Humans rarely typo a traversal.
I don't think this is true?
The typos are a bit different, but that’s one reason I hate the command line as a human.
You want me to hand type a file name? I’ll flip a letter or skip one!
I like to let tab completion write my filenames for me whenever possible.
I tab complete and fish shell also gives a nice little arrow selectable menu if options
There are so many diffierent CLI, why not use them or basic on them to rewrite?
I suspect this CLI madness is just a phase, but if the trend continues, I trust AI agents to handle the necessary rewrites.
Related ongoing thread:
Google Workspace CLI - https://news.ycombinator.com/item?id=47255881 - March 2026 (136 comments)
> The real question: what does it actually look like to build for this?
What was the not-so-real question? Or the surreal question?
I know it's becoming tiresome complaining of slop in HN. But folks! Put a bit of care in your writing! It is starting to look as if people had one more agent skill "write blogpost", with predictable results, as we are not a Python interpreter putting up with meh-to-disgusting code but actual humans with real lives and a sense of taste in communication
blogslop
The content is good, who cares. What gets more tiresome is complaints like this. The post was upvoted so people like it.
And for more persistent services, worth considering using varlink, for your agents sake and just if you need two cli thinks to chat. https://varlink.org/
The systemd universe is moving this way from dbus, and there doesn't seem to be a ton of protest against giving up dbus for json over unix sockets. There's really not that many protocols that are super pleasant for conversing with across sockets.
I love how AI gave the command-line and TUI interfaces a kind of Second Renaissance. It is not just AI that loves CLIs. It is especially blind people like me, who still use a lot of text-mode tools for their implicit accessibility. I gave codex a whirl recently, and hey! No accessibility problems at all. Just works. A few years back, that would have been released as a GUI-only program and would have locked me out completely[1]. A blessing that text oriented interaction is becoming important again!!!
1: Strictly speaking, there are ways to access some GUI programs on Linux with a screen reader. However, frankly, most are not really a joy to use. The speed of interaction I get from a TUI is simply unmatched. Whenever I work with a true GUI, no matter if Windows, Mac or Linux, it feels like I am trying to run away from a monster in a dream. I try to run, but all I manage to do is wobble about...
A second renaissance? The entire time internet had been running on CLI. All modern services relying om containers rely on images based on CLI. There is no renaissance needed because it never stopped.
Sure, server-side. What I am talking about is user-facing programs. That is why I mentioned codex as an example.
This is a very silly premise to begin with.
If AI agents are so underdeveloped and useless that they can’t parse out CLI flags, then the answer is not to rewrite the CLI.
You either give the agents an API layer or you don’t use them because they’re not mature enough for the problem space.
Haha, no.
I write my tools for humans, without help or use of AI. If the AI agent wants to use my tool so bad, they need to rise to that level. I'll not crouch on my knees to meet it.
If I ever write a tool for AI interaction, I'd give it a well-defined API, to make it even easier for the agent.