People use UIs for git despite it working so well in the terminal... Many people I knew at uni doing computer science wouldn’t even know what tmux is. I would bet that the demand for these types of UIs is going to be a lot bigger than the demand for CLI tools like Claude Code. People already rave about cowork and the new codex UI. This falls into the same category.
I’ve had a great experience with CLI-related skills at work. We have written CLIs for systems like Jira, along with skills that document the CLIs and describe the organisation of Jira at our company. Claude Code loads these reliably whenever you mention Jira or an issue number.
Alternatively, I’ve had less luck with purely documentation skills. They seem to be loaded less reliably when they’re not linked to actions the agent wants to take, and it is frustrating to watch the agent try to figure something out when the docs are one skill load away.
Documentation-based skills don’t really work in practice. They tend to waste tokens instead of adding value.
CLI skills are also redundant when the CLI already provides clear built-in help messages. Those help messages are usually up to date, unlike separate skills that need to be maintained independently.
If the CLI itself is confusing (and would likely be confusing for humans as well) then targeted skills can serve as a temporary workaround, a kind of band-aid.
Where skills truly shine is when agents need to understand non-generic terms and concepts: unique product names, brand-specific terminology, custom function names, and other domain-specific language.
I strongly disagree about CLI help being a good enough solution. Skills with CLIs backing them is the gold standard right now for a reason.
1. Skills let the agent know the CLI is available because they get an entry in the context window.
2. They let you provide a ton of organisational knowledge and processes that the agent would have a hard time figuring out from the CLI alone.
3. It is just more efficient to provide quick information in a skill than it is to require an agent to figure out every detail from CLI help messages alone every single time.
OpenAI and Anthropic give you a lot of usage/$ through their plans. For the Anthropic Max plans, this can be like a ~90% discount. Copilot does not benefit from this (their pricing model is also different though, it is request-based rather than token usage based, so it is hard to compare).
That's not to mention that the models generally work better in their own harnesses, which is perhaps unsurprising because the models have been trained with the specific harness in mind (and vice versa). That said, I think some 3rd-party harnesses do a lot of work to make different models work well in their harness.
You cannot just directly compare prices like this. It is like comparing share prices, it doesn't really mean much unless you also know how many tokens the models use.
For example, GPT-5.2 is even cheaper than Gemini, but in real-world usage it ends up costing similar amounts to Opus 4.6 because it uses a lot more tokens.
Claude Code and Cowork are incredible products, and can do much more than just search. Lots of people are paying hundreds of dollars a month for them.
If you’re just using AI for search then I can see why you’d not see the value. But many people really are getting a huge amount of value out of agents, and are already paying for it.
That said, agentic search connected to your companies information sources is very valuable on its own. We have just connected up our internal zendesk, Jira, confluence, and github in Claude Code and it’s incredible how useful it is to find information spread across different services in 1 minute instead of it personally taking me 15 minutes of manual search.
I think this originated from old arguments that say that the total _cumulative_ time spent reading code will be higher than the time spent writing it. But then people just warped it in their heads that it takes more time to read and understand code than it takes to write it in general, which is obviously false.
I think people want to believe this because it is a lot of effort to read and truly understand some pieces of code. They would just rather write the code themselves, so this is convenient to believe.
reply