Agent Experience: fifty is two and a half twenties

I learned English from a schoolbook in Denmark, working through the numbers chapter the way every Danish kid does: one, two, three, easy. Ten, twenty, thirty, forty - fine, there is clearly a system here. Then I hit fifty and stopped, because the English word is embarrassingly honest. Fifty is literally "five tens". The word I had been using my whole life, halvtreds, unpacks to "half-third times twenty" - two and a half twenties. My own language had been doing vigesimal arithmetic behind my back since before I could count, and I only noticed when I learned someone else's.
That is the strange gift of a second language. Most of it is not new at all - nouns are nouns, questions still go up at the end, and the patterns you already know carry you a very long way. But every so often you hit a word like halvtreds: something that looks like it should map cleanly and simply does not, because centuries of history are fossilised inside it. You cannot derive it. You just have to learn that this is how the other speaker counts.
Right now, software tooling is learning a second language. We spent two decades optimising Developer Experience (DX) for human engineers, and suddenly there is a new speaker at the keyboard: the coding agent. Designing for that speaker has a name - Agent Experience, or AX - and the agentic developer experience matters just as much as the human one did. The good news is that most of your DX instincts are cognates that transfer straight across. The trap is the handful of halvtreds words: patterns that look identical and mean something completely different to an agent.
Mostly cognates: DX speakers already know AX
The modern DX framework, formalised by Noda, Storey, Forsgren, and Greiler, distils developer productivity into three dimensions: feedback loops, cognitive load, and flow state. Every one of them has a direct AX translation - same concept, new pronunciation:
- Feedback loops become structured tool results. An agent does not mind waiting for a build, but it cannot do anything useful with a spinner or a progress bar. Fast still matters; parsable matters more.
- Cognitive load becomes the context window. Humans run out of patience; agents run out of tokens. Both degrade badly when you make them hold too much irrelevant detail at once.
- Flow state becomes the uninterrupted autonomous loop. An agent mid-task that hits an interactive yes/no prompt is a developer who just got pulled into an unplanned meeting.
There is also a very human reason to care. Longitudinal DevEx studies found that after adopting AI assistants, the share of developers reporting a worsened overall experience nearly doubled from 14% to 27%, and those reporting worsened flow state tripled from 7% to 20%. Researchers call it the Productivity-Experience Paradox: output goes up while the human is reduced to reviewing a firehose of nearly-correct suggestions. The way out is not more autocomplete - it is agents that can run whole loops themselves, in environments actually built for them. Which is exactly where the cognates stop being enough.
False friends: the DX-to-AX phrasebook
A false friend is a word that looks familiar in the other language and betrays you anyway. AX is full of them. Here is the phrasebook I wish someone had handed me - the same architectural dimension, spoken in both languages:
Read the right-hand column long enough and a theme emerges: an agent is a brilliant colleague with no eyes, no memory between sessions, and a strictly rationed attention span. Everything that follows is a consequence of those three constraints. And two rows of that table hide the biggest surprises of all.
The first halvtreds: more documentation makes agents worse
In DX, "write more documentation" is about as controversial as "drink water". So when agents arrived, we did the obvious thing: we wrote them long, loving AGENTS.md and CLAUDE.md files with directory overviews, coding standards, and tool inventories. It looked like a perfect cognate. It is halvtreds.
Researchers at ETH Zurich put context files through SWE-bench Lite and AgentBench and found that auto-generated context files reduced task success rates by an average of 3% while increasing inference costs by more than 20%. Even carefully human-written files bought only a marginal 4% success gain against up to a 19% cost increase.
The trace analysis explains why: agents are hyper-obedient.
Mention a tool in the context file and the agent will dutifully use it whether the task needs it or not - calls to the uv package manager jumped 1,600% and repo-specific tools 2,500% just from being named. Meanwhile the directory overview you lovingly wrote is redundant noise, because a modern agent can explore the file system on its own, and every wasted token accelerates context rot: in the LOCA-bench evaluations, frontier model accuracy fell from above 70% to below 10% as environment descriptions grew, with the task itself unchanged.
The AX principle is minimal effective context: the file should contain only what the agent cannot infer by looking. Not a tour of the codebase - a list of the fossils, the halvtreds words of your repo:
# AGENTS.md - only the non-inferable invariants## Build and test- npm run dev # port 1337, NOT 3000- npm run typecheck # tsc --noEmit, also runs as a pre-commit hook## Rules you cannot guess- lib/blog-posts.ts is generated; never edit it by hand- meta.json tags must exist in lib/tags.ts or the build fails- No em dashes anywhere. Plain hyphens only.# That's it. No directory tour. The agent can read.
Everything in that file is something an agent would get wrong without being told, and nothing in it is something the agent could work out alone. That is the whole test.
The second halvtreds: tokens are the currency, not seconds
DX taught us to optimise latency, because human attention decays in seconds. Agent attention decays in tokens, and that changes which architectures win. The clearest head-to-head is browser automation with Playwright: the MCP server streams accessibility trees and screenshots straight into the model's context, while the CLI writes them to disk and returns a file path.
- Playwright MCP: roughly 114,000 tokens for a standard automation task, plus about 3,600 tokens up front just to load the schemas for its 26 tools.
- Playwright CLI: the same task in roughly 27,000 tokens - a 4x saving - with about 68 tokens of schema overhead and no context degradation over long sessions.
The pattern generalises well beyond browsers: write results to disk, return a path, and let the agent choose what to read. It is the same instinct as a colleague who says "I put the full report in the shared drive" instead of reading you all forty pages over the phone. Pair it with the CLI adaptations from the phrasebook - JSON output when an agent is detected, idempotent commands that survive the try-learn-retry loop, and informative rather than instructive output - and you have the core of a tool an agent can actually live in.
Note: this is also the honest case for being picky about MCP servers. MCP is a genuinely useful universal adapter, but every schema you mount and every verbose result you stream is rent paid from the context budget. Mount what the task needs, not what the marketplace offers.
Improving the AX
You do not need a platform team or a rewrite to start. This is the order I would do it in, cheapest first:
- Diet your context files. Open your AGENTS.md or CLAUDE.md and delete everything an agent could discover by reading the repo. Keep only the invariants: weird ports, generated files, hard style rules, commands with non-obvious flags.
- Ship an llms.txt. A root-level manifest that tells agents which docs are current and which are deprecated. Agents increasingly request it before crawling anything else; this site serves one for exactly that reason.
- Add a JSON mode to your internal CLIs. One flag that swaps spinners and prompts for structured events and machine-readable errors, and make destructive commands idempotent while you are in there.
- Audit your tool results for token spend.Anything that returns more than a screenful into the context window should probably return a file path instead.
- Give agents a safe room. If your agents execute code, isolate them properly - microVM sandboxes like Firecracker-backed E2B cold-start in about 150ms and give every session its own kernel, which is more than your laptop's Docker socket can say.
None of these hurt your human developers. Most of them quietly help: tighter docs, cleaner CLI contracts, and less noise are good DX too. The two languages share a lot of vocabulary - you just have to know which words are false friends.
Put the five steps together and the budget story looks like this - rough estimates for a single tool-heavy task, but the shape is the point:
Illustrative estimates in thousands of tokens for one tool-heavy agent task. Hover or tap a point for values.
View data as table
| Improvement point | Without optimisation | With optimisation |
|---|---|---|
| Baseline | 120k tokens | 120k tokens |
| 1. Context files | 120k tokens | 100k tokens |
| 2. llms.txt | 120k tokens | 92k tokens |
| 3. JSON CLIs | 120k tokens | 78k tokens |
| 4. Tool results | 120k tokens | 45k tokens |
| 5. Safe room | 120k tokens | 43k tokens |
Counting to halvtreds
Back in that numbers chapter, the lesson was never really about English. Fifty being "five tens" did not teach me much about fifty; it taught me that halvtreds was strange, and that I had been fluent in something arbitrary my whole life without noticing. You only see the fossils in your own language when a new speaker tries to learn it.
That is what the agents are doing to our tooling right now. Every interactive prompt, every 40-page README, every tool that dumps its entire output into the conversation is a "two and a half twenties" - a convention we stopped questioning because every speaker we had ever met just knew it. The agentic developer experience matters, and optimising it starts with the humility of the language learner: keep the grammar that transfers, write down the fossils that do not, and stop expecting the new speaker to find your irregular verbs charming.
So, what is the halvtreds in your toolchain - the pattern you never questioned until a new kind of speaker showed up?
Further reading
- Biilmann, M. (2025). AX - is it Agent or Agentic? The Netlify CEO who coined Agent Experience, on what the term should actually mean.
- Noda, A., Storey, M., Forsgren, N. & Greiler, M. (2023). DevEx: a new metrics framework from the authors of SPACE. The source of the three DX dimensions - feedback loops, cognitive load, flow state - that this post translates into AX.
- Vella, A. (2025). The Productivity-Experience Paradox. Where the 14%-to-27% worsened-experience and flow-state numbers come from.
- InfoQ (2026). New research reassesses the value of AGENTS.md files. The ETH Zurich study behind the first halvtreds: context files that cost 20% more and deliver 3% less.
- TestDino (2026). Playwright CLI vs MCP: key differences for AI agent tools. The 114,000-vs-27,000-token benchmark behind the second halvtreds.
- Howard, J. (2024). The /llms.txt file. The spec for step 2 of the improvement list - a root-level manifest for machine readers.