Yeah it's a funny thing - a lot of the things you need to feed the model are things that actually would have helped humans...

Starting with agentic task-time "grounding" being just good documentation, and "skills" being just playbooks and user guides.

Hell, skills are increasingly paired with dedicated CLI tools, that remove jank from actual utilities and adapts them to be token efficient.

So now, any CLI `tool` people want AI to use eventually grows `tool/SKILL.md` and then a `tool-for-llms` wrapper that exposes task-specific, logical, higher level interface, then the skill is rewritten in terms of "for LLMs" wrapper. The procedural knowledge moves from Markdown into the wrapper, making the skill more token efficient, and both skill and the tools are optimized for common tasks and... at this point, we are doing actual UX engineering.

Now the truly interesting part is the difference between what's good UX/DX for LLMs vs humans. Turns out, the conceptual/abstract/cognitive part is pretty much the same: which is why skills still look indistinguishable from well-written documentation for humans, and why the commands exposed by "tool but for LLMs" make sense to us. Same way of grouping ideas into higher level concepts.

No, the main difference is just that LLMs are perfectly content with tightly packed unprettified JSON, or other forms of Perl line noise. The tool output doesn't need to look nice, or to have any spatial structure - they're reading it token by token anyway, and the tokens come from a tokenizer that's reading it byte by byte.

That points at an interesting asymmetry for humans. LLMs are doing I/O the same way in both directions: sequences in, sequences out. Humans only do sequential output - inputs, particularly visual, are processed holistically.

For us, what's easy to read is hard to write, and what's easy to write is hard to read. LLMs don't have this friction.

(I don't know what the implications of this are, I just find this interesting.)