If that took "several rounds of clarification", then the support they're paying for is worthless. Getting version of the application should be among the first bits of information collected, possibly even required for opening the ticket.

A big problem with CLI tooling is it starts off seeming like it’s an easy problem to solve from a devs perspective. “I’ll just write a quick Go or Node app that consumes my web app’s API”

Fast forward 12-18 months, after several new features ship and several breaking API changes are made and teams that ship CLIs start to realize it’s actually a big undertaking to keep installed CLI software up-to-date with the API. It turns out there’s a lot of auto-updating infrastructure that has to be managed and even if the team gets that right, it can still be tricky managing which versions get deprecated vs not.

I built Terminalwire (https://terminalwire.com) to solve this problem. It replaces JSON APIs with a smaller API that streams stdio (kind of like ssh), and other commands that control browsers, security, and file access to the client.

It’s so weird to me how each company wants to ship their own CLI and auto-update infrastructure around it. It’s analogous to companies wanting to ship their own browser to consume their own website and deal with all the auto update infrastructure around that. It’s madness.

"almost nobody"

Sure,

The agents have a tendency to make the "Examples" section of the help message way too long by stuffing it with redundant examples, so it needs to be manually pruned from time during development if you use an agent for tool development.

`gh-install` is a fish script (using curl and jq), it was made by an agent.

  gh-install -h
  Usage: gh-install [-i] [-q] [-s] [-p PATH] [-n NAME] [-f FILE] [-e EXECUTABLE] <repo> [version]
    -i            - Show info about what would be installed (no install)
    -q            - Quiet mode (suppress all output except -i info line)
    -s            - Install to /usr/local/bin (system-wide)
    -p PATH       - Install to the specified directory (incompatible with -s)
    -n NAME       - Install with custom binary name
    -f FILE       - Select specific file from release assets and use as binary name (unless -n is specified)
    -e EXECUTABLE - Select specific executable from extracted archive (when archive contains multiple executables)
    repo          - GitHub repository in format owner/name
    version       - Optional version tag (defaults to latest)

  Examples:
    gh-install cli/cli v2.40.1
    gh-install cli/cli
    gh-install -i cli/cli (show info only)
    gh-install -i -q cli/cli (show info quietly)
    gh-install -s cli/cli (install system-wide)
    gh-install -p /opt/bin cli/cli (install to /opt/bin)
    gh-install -n gh cli/cli (install as 'gh')
    gh-install -f zed-remote-server zed-industries/zed (install server file)
    gh-install -e server some-org/multi-tool (install 'server' executable from archive)

  Use `gh-install -h` to install asdf, hadolint, ripgrep, fd, delta and bat.

  Do x using the tools found in `./tools` (they all have a `-h` option).

[dead]