AI can make the interface. Who decides it's the right one?

In August, Anthropic published a playbook for developing software with AI agents. Nielsen Norman Group read it closely and found that UX has no stage or gate of its own in it. We think NN/g is right, and that it matters most for organizations that move design decisions to the teams building with agents.

What the playbook leaves out

The playbook keeps the six familiar stages: plan, design, build, test, deploy and maintain. Along the way AI writes the documents (an intent, a spec, a plan) and people approve them at gates: a product owner, an engineer, a technical lead. In The Role of UX in Agentic Software Factories, Tanner Kohler of NN/g points out that none of those gates belongs to UX. User research is not mentioned. The test stage checks the code against the team's own documents, not against what users need. UX is reduced to context for the AI.

NN/g names three roles for UX: deciding what is worth building, evaluating what gets built and adding context to what AI generates. The playbook covers only the third.

Making an interface is not knowing it's the right one

An agent can make a screen that looks finished in an afternoon. The spec is approved and the tests pass. That still says nothing about whether it is the right screen. Whether people understand it, whether it solves the problem they actually have, whether it should exist at all: no spec answers that, since a spec holds what the team already believed. Only users answer it.

The same goes for an organization that moves design decisions to the teams building with agents. The move makes sense: the people closest to the product decide. But the decision moves and the expertise does not come along by itself. Move the decision, and you have to organize the quality assurance with it: user research, UX expertise and someone who owns the whole journey, not just one team's screens. Otherwise each team gets its own flow right and nobody sees where a user gets stuck between two of them.

The three roles in our loop

Our process has the same three roles under other names. It starts with the core: what do your users need, and what should your business achieve? Around it runs a loop of make, choose and measure. AI does much of the making. NN/g's roles live in the other parts.

Deciding what is worth building is the core. Before anything is made, we talk to users and stakeholders and agree on what has to be true for both. NN/g suggests organizing the intent template around user needs, with evidence that the problem is real and an understanding of why it happens. That is what a core is for.

Evaluating what gets built is choose. NN/g asks teams to define the moments when a UX review or a quick usability test is required, such as a change to the navigation or a flow that breaks with convention. In our loop that moment is fixed: we test what we make, first quickly with AI and then with users, and only then choose what stays and what goes live.

Watching the signals once it is live is measure. NN/g wants user signals in the monitoring beside the technical alerts: tasks abandoned halfway, a spike in support tickets. Those are the signs we watch for after launch, against the goals set in the core. What we learn goes back to the core and becomes the next loop.

Context holds what we already know

The third role, adding context, is the one the playbook does cover, and we work on it ourselves. Meridian, a tool we developed, is shared configuration for Claude Code that loads into every one of our projects and keeps itself up to date. It carries our house rules: how we review accessibility, how we write interface copy, which design tokens a component may use. An agent that writes code in our projects follows them, and a check in the pipeline stops a color that is not a token.

It works, and it shows NN/g's point from the inside: context can only hold what we already know. Meridian makes an agent follow our rules for a good form. It cannot tell us whether this form should exist, or whether the people filling it in understand the question. The same goes for a design system agents can read, which NN/g rightly recommends: it keeps the components consistent, not the product right. That still takes the core, a test with users and the numbers after launch.

If your team develops with agents

Four questions decide whether UX keeps its place:

• Who decides what is worth building, and with what evidence from users?
• At which moments does a UX expert review it, or a user try it, before it goes live?
• Which signals from users sit in your monitoring beside the technical ones?
• Who owns the whole journey, across the teams that each make a part of it?

An agent answers none of the four. It does make every answer quicker to test, once someone asks the question.