Designing for Agent Experience: Why AI Is Collapsing UX and DX

A lot of product development friction hides in plain sight. Someone has an idea, but before they can test it, they have to understand the tooling. They need to know where the work lives, how the deployment process works, what an error message means, who owns the system, and which undocumented rule they are about to break.

For experienced teams, this can feel like the normal cost of building software. For everyone else, it can stop an idea before it starts.

That was the tension Dana Lawson, CTO at Netlify, explored in her UXDX talk on designing for Agent Experience, or AX. Her original focus was redesigning a platform for AI agents, but the deeper lesson turned out to be far more human. When Netlify made its platform easier for agents to understand and use, it also made the experience clearer, safer, and more useful for the people behind the keyboard.

In Lawson’s framing, AX is not about making machines happy. It is about removing the hidden assumptions that make software delivery harder than it needs to be.

The Builder Is No Longer Just an Engineer

For years, most development platforms have been built around one central assumption: the person building software is a developer. That assumption shapes everything from the language used in tools to the way systems are documented. Platforms expect users to understand Git. Build systems expect people to read logs. APIs expect engineers to know the right order of operations. Internal workflows often rely on tribal knowledge, old Slack threads, and the person who “just knows” how something works.

AI is starting to break that assumption.

Lawson described how agents have turned intent into a kind of programming language. The interface is no longer only code; it is natural language. A person can describe what they want to build and expect a working product, prototype or deployment to come out the other side.

Dana's example was a friend, a massage therapist, who wanted to build a website for an all-inclusive retreat in Barbados. She did not want to learn Git or become fluent in deployment pipelines. She had a vision and wanted to get it into the world, so she used ChatGPT to help build it.

That story matters because it represents a much wider shift. Product managers, designers, researchers, marketers, operations teams, and domain experts are all getting closer to the act of building. The builder persona has expanded, and for product development leaders, that changes the question. It is no longer simply “how do we help engineers ship faster?” It is “how do we make building more accessible without making the system unsafe?”

AI Exposes the Assumptions in Your System

One of the most useful things about designing for agents is that agents are not particularly good at guessing their way around messy systems. They cannot rely on hallway conversations, ask the person who remembers why a service works a certain way, or interpret a build log full of vague human shorthand unless the system gives them a clear signal.

That makes AI a useful mirror for organisational debt. Agents expose the parts of a system that humans have quietly learned to work around. A vague error message, an unclear service boundary, or an undocumented dependency may feel manageable to an experienced team, but often only because someone knows the workaround. Once an agent enters the workflow, that hidden complexity becomes much harder to ignore.

At Netlify, one practical example was build logs. Traditionally, these logs were written as human-readable narratives, which might work for an experienced engineer but are less useful for agents. Netlify restructured them to include machine-readable error codes alongside the human text, so agents could parse what had happened and act on it.

The benefit was not limited to the agent. The experience became clearer for engineers too. A failed build could be categorised more easily, the reason for failure was easier to understand, and the system became more observable. This is the real value of AX: it forces teams to make implicit knowledge explicit.

UX and DX Are Becoming One Experience

The separation between user experience and developer experience made sense when users and builders were clearly different groups. That boundary is now far messier.

A product manager might prompt a prototype. A designer might refine a flow closer to production. An engineer might review agent-generated code, while an agent deploys, tests, or monitors on behalf of a human. The experience stretches across interfaces, APIs, permissions, documentation, infrastructure, deployment previews, and rollback systems.

Lawson argued that UX and DX are collapsing into one discipline because the experience of building is becoming part of the product experience itself. This matters for teams because a confusing error message can block a non-technical builder from progressing. Poor documentation can make agentic workflows unsafe. A vague deployment failure breaks the loop between intent and output.

Design is no longer limited to what appears on the screen, just as developer experience is no longer limited to the API. As agents become part of the workflow, teams have to consider the full journey of building: from the first prompt and prototype, through testing and deploy previews, to failure states, approvals and rollbacks. AX matters because all of those moments now shape whether people can build safely, confidently, and with the right level of control. It is not a niche technical concern, but a cross-functional product development challenge.

From Handoffs to Human-Agent Loops

Traditional product development has often worked like a relay race, with product defining the requirements, design turning them into mockups, engineering building the solution, QA checking the work, and DevOps getting it into production. Each stage adds value, but each handoff also creates delay and increases the chance that context will be lost along the way.

AI starts to compress that process. A product manager can describe a problem in natural language, an agent can turn that intent into a prototype, a designer can refine the experience, and other agents can support testing, deployment previews, and monitoring. Engineers are still essential, but their focus shifts towards validating the architecture, protecting quality, and understanding where the risks sit.

This does not remove the need for human expertise. It changes where that expertise has the most impact. Instead of manually pushing work through every stage, people are increasingly needed to provide judgment: whether the idea is worth building, whether it solves the right problem, whether the experience feels coherent, whether the architecture is safe, and whether the work is ready to ship.

That shift can feel uncomfortable, particularly for teams whose roles have been narrowly defined around one part of the process. But it also creates an opportunity. The most valuable people will not simply be those who operate one step in the chain, but those who understand how the system works, ask better questions and make stronger decisions across it.

The Architecture Has to Become Legible

Lawson was clear that teams cannot simply bolt agents onto legacy systems and expect good outcomes. Most organisations are dealing with fragmented architectures made up of APIs, microservices, CI/CD pipelines, internal tools and undocumented workflows built over many years. Much of the system still depends on tribal knowledge.

That does not work well in an agentic environment. Agents need to understand what capabilities exist, what events are happening, and which boundaries they must not cross. That requires teams to rethink the architecture around clarity.

Lawson highlighted three practical shifts. The first is moving from APIs to capabilities. Instead of exposing hundreds of technical endpoints and expecting an agent to work out the right sequence, platforms need higher-level operations such as creating a site, deploying a repository, or provisioning an environment.

The second is investing in event-driven signals. Agents need to observe what is happening, from a build starting or failing to a pull request being created or a deployment succeeding. These signals allow systems to respond intelligently, rather than waiting for a human to intervene.

The third is making architecture discoverable. Netlify created shared technical blueprints that described core services, cross-service contracts, deployment dependencies, and architectural decisions. The goal was not documentation for its own sake, but giving agents and humans the context they need to change systems safely.

Guardrails Matter More When Everyone Can Build

The promise of AI-assisted development is speed, but the risk is uncontrolled speed. If agents can deploy, configure systems, or access data, trust cannot be an afterthought.

Lawson pointed to three principles: sandboxed execution, human-in-the-loop approval, and auditability with rollback. Agents should only act within defined environments, risky changes should still require human judgment, every agent action should be logged, and every deployment should be reversible.

This is where leaders need to be careful. The goal is not to remove all friction, because some friction protects the user, the data, and the business. The goal is to remove unnecessary friction while strengthening the controls that matter. As more people become builders, safety has to be designed into the system rather than added at the end.

Code Is No Longer the Scarce Resource

One of the most important implications of Lawson’s talk is that AI changes what organisations should value. If anyone can generate code, code itself becomes less scarce. What becomes scarce is judgment: knowing what is worth building, when to ship and when to hold, how to protect quality and trust, and how to connect product, design, engineering and research around better decisions.

AX is useful because it gives teams a way to respond to that shift. It asks them to make systems clearer, safer, and easier to work with. It pushes them to remove hidden assumptions and design for intent.

The lesson is not that agents replace humans, but that agents reveal where human systems are already too difficult to navigate. Done well, Agent Experience becomes human experience. It helps the massage therapist with an idea, the designer working closer to code, the product manager testing a concept, and the engineer debugging a failed build.

For product development leaders, the opportunity is not just to adopt AI tools. It is to use this moment to clean up how building happens: clarify the architecture, improve the feedback loops, strengthen the guardrails, and make the system easier for more people to contribute to safely.

The question is no longer only: can we build it?

It is: should we build it, can we trust it, and have we designed the system so humans and agents can work together well?

Want to watch the full Talk?

You can find the full talk here: https://uxdx.com/session/designing-for-the-agent-experience-when-ux-and-dx-collide-in-the-age-of-ai/

Or explore all the insights in the UXDX USA 2026 Post-Show Report: https://uxdx.com/post-show-report