# AX *Designing software with Agent Experience in mind.* Published 2026-04-30 · https://dom.vin/2026/ax ## Summary An essay on what software design means when the audience is an AI agent rather than a person. The opening: twenty years of obsession with software design, the Wilde-style claim that great UX makes the necessary feel inevitable, and the through-line that across hundreds of apps and tools the audience has always been human. Section two ("Do agents need software?") is a hypothetical, not a question to be answered — it proposes a shift in what "software" means once the audience is an agent. If software has historically been a fixed sequence of instructions for a runtime that didn't know what to do, then less and less of what gets shipped to an agent counts: the agent already knows its environment, reads English, and writes its own code on the fly (Karpathy's Software 3.0). The shift surfaces in small places (an installer for an agent skill is almost never a script that runs the same on every laptop; a paragraph of instruction works where a flowchart of detection logic doesn't), and in the larger pattern of fixed strings the model has been trained on (the agent keeps reaching to hardcode paths, configs, magic numbers; the training data hasn't caught up to its own runtime). The same trade scales up to structured tool calling and MCP: portable across hosts but costing context tokens and round-trips, with Anthropic's own engineering team pivoting to wrapping MCP tools in code execution. David Crawshaw frames the agent as a `for` loop around an LLM call, navigating with `find`, `cat`, and `grep -R`. Schemas still earn their place for auth, side-effect controls, audit trails, predictable cost — but the surface area where structured tools beat shell access keeps shrinking. Section three ("Things I've built") names three small artifacts in this direction — fold (folder ↔ self-describing markdown file), portdown (markdown ↔ self-installing polyglot), seeds (any folder addressable at a short URL) — and treats them less as products than as worked examples in the same discipline: study the problem space, chip away towards inevitable solutions, remove things from the path until the user can pick the thing up without thinking. The user is no longer human. The work is still the work. ## Claims - Great UX makes the necessary feel inevitable; the path to that feeling is paved with dead ends and false promise. - If 'software' means a fixed sequence of instructions that runs the same way on every machine, then less and less of what gets shipped to an agent counts — the artifact is more often a description of intent that the agent compiles in the environment it lands in. - The discipline of designing software for a human audience transfers to designing for an agent — study the problem space, chip away towards inevitable solutions, remove things from the path until the user can pick the thing up without thinking. --- I've been obsessed with software design for almost twenty years. In that time I've developed rather strong opinions on what makes for good software. The field that thinks most about the properties of great software is UX; User Experience. I asked AI to generate a definition of UX in the styles of great authors throughout history. Here's Oscar Wilde: > UX is the art of making necessity appear gracious. Any fool can build a system that performs a function; the trick is to make the function feel inevitable, as if no committee or regrettable compromise had ever existed. Bad UX explains itself constantly, like a bore at dinner. Good UX has the manners to be useful without recounting its difficulties. 'Inevitable' is the most operative word. The greatest compliment a UX designer can receive is that "anybody could have designed this." Because the solution is so obvious that there's no other way it could work. But 'obvious' here is in hindsight. It's very easy to connect the dots backwards. The path to intuitive is paved with dead ends and false promise. I've built hundreds of apps for dozens of clients over the years. I've studied problem spaces and chipped away towards inevitable solutions. Every single project has had one thing in common, the user is human. ### Do agents need software? If "software" means a fixed sequence of instructions that runs the same way on every machine, then less and less of what gets shipped to an agent counts. The agent isn't a CPU. It already knows its environment, and most of what makes traditional software *work* — the part that translates a developer's intent into something a dumb runtime can execute — already lives inside it. Andrej Karpathy [calls this Software 3.0](https://www.latent.space/p/s3): a third era of programming where the program is natural language and the runtime is a model. You notice the shift in small places. The installer for an agent skill rarely works the same across laptops — `curl | bash` strips environment variables, harnesses each keep their skills directory somewhere different — so the script grows into a flowchart the agent could have skipped in two lines. The same shape comes up wherever a fixed string used to live: paths, configs, magic numbers, all baked in by twenty years of training data the model keeps reaching for. Structured tool calling is the same trade scaled up. Anthropic's [Model Context Protocol](https://www.anthropic.com/news/model-context-protocol) is the standard layer for it: portable across hosts, but every tool definition takes context, every call is a round-trip with intermediate JSON, and at enough tools the registration block fills the window before the agent has done any work. Anthropic's own engineering team has [argued](https://www.anthropic.com/engineering/code-execution-with-mcp) that the answer is to wrap MCP tools in code execution, deferring the actual work to bash. David Crawshaw [puts it plainly](https://crawshaw.io/blog/programming-with-agents): the agent is a `for` loop around an LLM call, and `find`, `cat`, and `grep -R` are how it actually navigates a codebase. Schemas still earn their place for auth and audit, but the surface area where they clearly beat shell access keeps shrinking. So the shape of what gets shipped to an agent is starting to look different from the shape of what gets shipped to a person. More and more, the artifact is a description of intent, and the agent makes the implementation in the environment it lands in. A few small things in this direction. [Fold](https://dom.vin/fold) makes a folder of context portable as a single markdown file. [Portdown](https://dom.vin/portdown) wraps any markdown as a self-installing polyglot — readable when pasted to an agent, executable when piped through bash. [Seeds](https://seed.show) puts them together: any folder becomes a five-character URL the agent can paste in one line. None of them carry much structure of their own; they lean on the agent for the parts that change between environments. These are early days. I've been treating them less like products and more like worked examples — exercises in the discipline rather than the destination. The discipline is the same as it's always been: study the problem space, chip away towards inevitable solutions, remove things from the path until the user can pick the thing up without thinking. The user is no longer human. The work is still the work.