Google Workspace CLI - https://news.ycombinator.com/item?id=47255881 - March 2026 (136 comments)
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.
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.
Is there progress happening in that trajectory?
> gws ships 100+ SKILL.md files
Which must altogether be hundreds of lines of YAML frontmatter polluting your context.
LLM assistants are going to be a good forcing function to make sure all app features are accessible from a textual interface as well as a gui. Yes, a strong enough AI can drive a gui, but it makes so much more sense to just make the gui a wrapper around a command line interface that an LLM can talk to directly.
https://x.com/ID_AA_Carmack/status/1874124927130886501
https://xcancel.com/ID_AA_Carmack/status/1874124927130886501
Andrej Karpathy reiterated it a couple of weeks ago:
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.
For decades now, pro design print shops have required text files describing the design to print from.
And as every Danish pelican cyclist knows, graphics are their most scalable as text vectors.
Inkscape does fine with these.
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 works really well. I got it to work with i18n too.
Not schilling, just easier to show you the repo since it's open source. https://github.com/coast-guard/coasts
Claude was struggling to use the ‘gh’ command to reliably read and respond to code review line level comments because it had to use the api. I had it write a few simple command line tools and a skill for invoking it, instantly better results.
YMMV
Maybe asking agent to write/execute code that wraps CLI is a better solution.
Everything old is new again...
Build for humans, including good man pages or `--help` docs as needed.
If LLMs are worth the name AI they will understand how to discover and use Unix-style commands. In my experience, this is exactly the case and I need only say "I use tool X for use case) Y."
AIs don't. If they don't reach for the --help switch every time they'll attempt the statistical average, which may or may not work.
For super-common or popular tools like `gh` the usage is already in the training data though.
Them: Agents will write code 10x faster than a human.
Also them: You will have to dumb down your CLI for them to function properly.
Right now a lot of the focus is on getting them to execute tasks reliably. But the harder problem might be reconstructing what actually happened later, why a decision was made, what context the agent had, and how you audit or override it if something goes wrong.
Feels like autonomy is moving faster than the accountability layer around it.
---
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.
1. Deterministic & Non-Blocking Execution(--yes)
2. Not just Structured Outputs but strictly validated Inputs also("count should be a valid integer")
3. Actionable Structured Errors("")
4. Semantic Exit Codes(0 - ok, 1 - input error, 2 - critical)
5. Granular Verbosity Control(-v, -vv, -vvv)
6. Composable Structured Pipes
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.
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...
The whole "raw JSON > flags" argument sounds clean in a blog but falls apart in practice. Agents are actually good at parsing messy human output. stderr, exit codes, even tables.
I run AI agents against CLIs every day. The failures are almost never, "the outpt wasn't structured enough." They're context window overflows, permission issues, and the agent confidently running the wrong command over and o ver.
The real insight here shouldn't be "rewrite for agents" — it's "make your CLI not actively hostile." --output json and non-zero exit codes on failure. That's should be it.
Maybe we are optimising the wrong layer..
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.
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.
I don’t disagree with your point about agent abilities with older, concise, well-represented-in-training-data tools though.
I don't think this is true?
You want me to hand type a file name? I’ll flip a letter or skip one!
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
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.
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?
I took away a completely different message: humans and LLMs make different mistakes that require different validation.
