The Next Customer Is an Agent

Claude Code has no file tree. No editor pane, no tabs, no project dashboard, no split view with the tests on the right. Twenty years of IDE work went into helping a human hold a codebase in their head, and Claude Code ships none of it. Boris Cherny said as much in an interview last year: they “didn’t spend time building all this kind of nice UI and scaffolding on top of it.” It’s raw access to the model, “as raw as I get.”

What it does ship is for the model. A tool that reads a file with line numbers, because the model asks for lines. A search tool that returns matches with context, because the model reads matches, not trees. A system prompt that explains the tools like you’d explain them to a new hire. Compaction that keeps the context under the limit. Memory files. Hooks. The human gets a text box, a permission prompt, and a diff scrolling past, and that is the whole human surface.

I don’t read that as a gap they haven’t got around to. I read it as the design, and I think it’s most of why the thing works. The part of an IDE that helps a human understand the state of the code is the part a human doesn’t need when a model holds the state. So they didn’t build it, and put the effort where the reader actually is.

That’s what I want to write about, because I don’t think it’s a coding tool thing. I think it’s what software looks like when the customer is an agent.

Walk it through on an API

Take any API you’ve integrated, a payments one, say. Think of what got built for you as its customer. A landing page. A quickstart. SDKs in six languages. A dashboard with a request log. An error page with a friendly sentence and a link to the docs. Rate limit headers you were supposed to read. All of it exists because the customer is a person who browses, skims, and gets frustrated.

Now the customer is an agent. It doesn’t browse. It reads the tool description, makes a call, gets a response, makes another. The landing page is invisible. The quickstart is the tool description, or it is nothing. The error page is the error string, and it is read once, by something that will act on it in the next turn. The dashboard is a call to read state back. Every affordance you built for a human reader is now either unreachable or a cost, because it went through the context window on someone else’s token budget.

So the things that matter shift. Names have to mean what they say, because nobody is going to look one up. An error has to say what to do next in the words the model would have used, because the model’s next move is copied out of it. Calls have to be safe to repeat, because this customer retries. State has to be cheap to read back, because this customer re-reads instead of remembering. And the number that decides whether you get used at all is the tool-call error rate. An agent that fails your tool twice will route around you if it can, and its operator will drop you if it can’t.

None of this is new engineering. It’s the same taste that made Stripe’s API feel good. The difference is who it’s for, and that the new customer never fills in a survey.

The interface was the lever

I learned how much of the error rate lives in the interface the hard way. At one point roughly nine in ten of my agent’s tool calls came back as errors, and every instinct said the model was bad. The logs said otherwise. The biggest single bucket, about a quarter of the errors, was a per-turn movement budget I had added three days earlier. The model would ask to walk somewhere, the harness would refuse because the turn’s budget was spent, and the model couldn’t see the budget, so from where it stood the refusal made no sense. It was acting rationally against a gate nobody had told it about. The fix wasn’t to explain the budget. It was to delete it. Movement calls now queue and return at once, the body walks while the model thinks, and the turn ends when the model stops talking. The model never changed.

Anthropic tell the same story about SWE-bench in Building effective agents: the model kept getting relative paths wrong after changing directory, so they made the file tool require absolute paths, and it “used this method flawlessly.” Their rule of thumb is to put as much effort into the agent-computer interface as we already put into the human one. My version is blunter. When an agent fails your tool, assume it responded sensibly to what it could see, then go and find out what it saw.

Taste turns into a number

Here’s the part that excites me. Whether an API was nice used to get settled in a design review by whoever had the most conviction, and measured, if at all, by a survey months later. Humans are hard customers to measure. They don’t say why they left, they contradict each other, and they quietly adapt to a bad interface without telling you it was bad.

An agent is a customer you can rerun. Change one line of a tool description, run the same two hundred tasks, count the failures. The thing we used to call taste becomes a column.

Vercel published a clean case of this in January. They evaluated agents on Next.js 16 APIs newer than the models’ training data. With no docs, 53% of tasks passed. With their skills as shipped, still 53%. With skills plus explicit instructions to use them, 79%. With a docs index inlined into AGENTS.md, 100%. Then they compressed that index from 40KB to 8KB and stayed at 100%. Nobody argued about which docs format was nicer. They ran it.

The warning is in there too. My intuition about what reads well to a model is worse than my intuition about what reads well to a person, and more words for the agent are not free. The one study I’ve seen that rewrote tool descriptions at scale bought six points of task success with two thirds more execution steps. The number replaces the intuition rather than confirming it, and it’s a number for one model on one day. But it is a number, and for taste, that’s new.

What’s left for the human

Netlify’s Matt Biilmann called this agent experience back in January 2025, so I’m late to the name. What I think I’m early to is how far it goes. Claude Code isn’t a coding tool that happens to use an agent. It’s agent-first software, and the tell is the size of its human surface: just enough to point the agent somewhere and watch it work.

That’s the shape I expect most software to take. The customer is an agent. The interface is for the agent, and it gets measured like one. The human keeps a window, and the window keeps getting smaller, because what a person needs from software they don’t operate by hand is only to see what it did and to say yes or no.