Agent Experience Is The Next Product Surface

At AI Native DevCon London, I talked about agent experience, or AX, because the builder persona has changed. The people our platforms were originally built for are no longer only professional developers. Developers are still builders, but they are not the only people who can create software now.

That is the uncomfortable starting point. Agents have turned intent into something much closer to a programming language. A therapist, teacher, small business owner, student, product manager, or someone standing in line at a store can describe what they want and get working software back. That does not make engineering disappear. It changes what engineering has to make possible.

In the talk, I referenced IDC's prediction that more than 500 million new applications will be built by 2028, more than the previous 40 years combined. Whether or not that exact number is the one we remember later, the direction is clear: the number of people who can create software is expanding faster than the number of professional engineers.

At Netlify, we build an agentic web application platform. We help people build, deploy, and create experiences. In an agentic world, "people" now includes a much wider group of builders, and "experience" includes the agents that help those builders move from idea to production.

The surprising part is that when we redesigned parts of the platform for agents, we made it better for experienced developers too. That is the AX paradox: designing for agents can improve the human experience, because the same structure that helps an agent reason also helps a human scan, debug, trust, and iterate.

Use This Talk As Agent Context

Tessl has turned my AI Native DevCon talk into a skill your agent can use as context. You can also watch the full recording.

Toria Shows What Changed

I told the story of my friend Toria because she makes the shift concrete. She is a licensed massage therapist, a drummer, and someone with a clear vision for an all-inclusive Barbados massage and wellness experience. She did not want a static website. She wanted community, payments, content, and an application that could carry the experience she had in her head.

She did not write code. She wrote intentions. She opened ChatGPT, described what she wanted, and started building. That is where the old assumptions broke down. She did not know what Git was, and she should not have had to know. She did not want to understand deployment configuration, pull requests, or platform internals. She wanted to turn a vision into something people could use.

That is the reality for millions of new builders. Agents often still speak fluent developer, but the humans they serve do not. Our tools assumed a level of technical literacy that most of the world does not have. If we keep that assumption, we make agents powerful only for people who already know how software delivery works.

What Is Agent Experience?

Agent experience is the practice of designing for the place where humans and agents collaborate. It is not about making machines happy. It is about removing unnecessary friction so a human can express intent, an agent can act on it, and the platform can keep the work safe, inspectable, and useful.

We have talked for years about user experience and developer experience. AX sits next to those disciplines because the user, the developer, and the agent now interact with the same system. The end user may speak plain English. The agent may handle Git, deployment, testing, and configuration. The developer may spend more time validating architecture, writing context, and building guardrails.

This is not only about API calls being agent-friendly. It requires rethinking the stack: how intent is expressed, how systems communicate, what context is available, what signals are exposed, and how humans decide whether to trust the result.

The AI Coding Landscape Has A Common Pattern

The tool landscape is changing quickly. In the talk I mentioned tools such as Claude Code, Cursor, Codeium, GitHub Copilot, v0, Bolt, Glyphs, and Lovable. Names will change, and the category names will probably change too. The common pattern matters more than the current list.

The pattern is intent as input and working software as output. A person describes what they want. The agent generates code, runs tools, fixes errors, deploys, or opens a pull request. That pattern only works well when the infrastructure understands the task, the deployment target, the CI pipeline, the edge network, and the signals the agent needs to continue.

This is where platform design becomes agent design. A platform that was built only for human operators will expose too much mechanical detail in some places and too little structured signal in others. An agent-native platform has to make capabilities, state, errors, previews, and trust signals legible.

Shift One: Specs Become Intent

The first shift I described was from specs to intent. Specs still matter, especially in large-scale technical platforms. But many new builders are not starting with a 50-page requirement document, a Jira ticket, or a complete PRD. They are starting with a prompt, a sketch, a reference, or a problem description.

For Toria, the input was not "implement a booking workflow with these deployment constraints." It was closer to "I want a wellness retreat experience with booking, payments, community, and content." The system has to turn that intent into software without forcing her to learn every internal step.

At Netlify, we have been using agent runners that take intent, generate code, and move the output into real engineering workflows: preview deploys, automated tests, production pipelines, and review surfaces. What used to take a long sequence of handoffs can now happen much faster, but only if the platform can preserve enough structure for the result to be trustworthy.

Shift Two: Handoffs Become Shared Creation

The second shift is from sequential handoffs to shared creation. The old workflow was a relay race. Product wrote the spec. Design made the mockup. Engineering built it. QA validated it if there was a QA stage. DevOps deployed it because nobody trusted anybody else to push the button.

Agents compress that sequence. Product teams can generate working prototypes. Designers can refine directly in code. Engineers can spend more time validating architecture and shaping the context agents use. Agents can handle testing, deployment, and iteration in the loop.

That does not mean everyone does everything without boundaries. It means the software development lifecycle becomes more collaborative and more continuous. The human role changes from passing artifacts along a chain to providing judgement, taste, direction, and review while the work moves at machine speed.

Shift Three: CI Becomes An Autonomous Loop

The third shift is from passive CI pipelines to autonomous development loops. CI used to be something that ran after a human pushed a change. It produced a pass or fail signal, and then a person came back to interpret what happened.

Agents can participate in the infrastructure lifecycle. They can generate tests, detect failed previews, analyze build blocks, propose fixes, open pull requests, and keep iterating. CI becomes a continuous feedback loop rather than a final checkpoint.

Deploy previews are central to this because they bring humans back into the loop. Every change can get a unique preview URL. The agent can use structured signals, and the human can visually inspect the result. If you have ever built this way, you know the rhythm is preview, inspect, adjust, preview again.

Build Logs Are An AX Surface

I gave build logs as a concrete example because they show what AX looks like in practice. Our build logs used to be human-readable narratives. They were useful for scanning if you already understood the system, but they were poor inputs for agents.

We restructured them with machine-readable error codes alongside human text. An agent can now parse a build failure, identify a misunderstanding, and propose or apply a fix. But the same change made the dashboard clearer for human engineers. Error categorization, failure reasons, and structured output made debugging faster for everyone.

That is the AX paradox again. Designing for agents forced us to clarify the system. Once the system was clearer, humans benefited too.

Legacy Systems Have To Become Legible

Most of us do not live in a perfectly greenfield world. We are introducing agents into fragmented systems made of APIs, microservices, CI pipelines, undocumented Terraform modules, Slack-thread tribal knowledge, and workflows designed around human operators.

Agents struggle with that. They cannot see across service boundaries by default. Every API speaks a different dialect. Critical context lives in people's heads. If agents cannot observe the system, they cannot act intelligently.

That is why we cannot simply bolt agents onto legacy architectures and expect them to work. The architecture itself has to evolve so agents can understand what they are allowed to do and what the system is trying to accomplish.

The first architecture shift is from APIs to capabilities. Traditional systems expose mechanical operations: post to this endpoint, put that resource, fetch this object. Agent-native systems should expose intent-level operations such as create a site, deploy a repository, or provision edge compute. Those are capabilities an agent can reason about.

The second shift is from request-response to event-driven architecture. Agents should not have to constantly poll and guess. They need events such as deploy started, pull request created, build failed, preview ready, or policy check failed. Those events let agents observe and respond.

The third shift is making architecture legible to agents. At Netlify, we created a system of record called blueprints: skills, context, recipes, architecture decision records, and guidance that coding agents can use before they make changes. The goal is not better documentation as a vanity exercise. The goal is safe operation in complex systems.

Trust Has To Be Built Into The Platform

When agents can deploy code, provision infrastructure, and modify production systems, trust cannot be optional. At Netlify we follow three principles.

First, sandbox execution. Agents should not escape their sandbox or access resources they were not granted. Second, human in the loop by default. The human should approve the meaningful parts of the work instead of rubber-stamping noise. Third, audit and rollback. Every agent action should be logged, and the system needs a reliable way to return to a known state.

This is where events matter again. If you cannot explain what the agent did, why would you trust it in production? Transparency is not decoration. It is part of the trust model.

AX Changes The Organization

The organizational impact is large because more of the company can participate in building. Support can create internal tools. Product teams can test hypotheses. Designers can make working prototypes. Customers can express their needs closer to the product surface.

Engineering does not become irrelevant. Engineering moves toward building the guardrails, architecture, policy, context, and systems of record that make this democratization safe. That is where AX is critical. It lets more people build without pretending that everyone understands deployment, security, governance, and runtime behavior.

This also came up in Q&A. If we really build hundreds of millions of new applications, we have to talk about what not to build, environmental cost, complexity, compression, compaction, and responsible engineering. New builders may not understand those tradeoffs. Professional engineers still have to carry that responsibility.

Accountability also changes under abstraction. Some users just want to build an app or website and have the platform handle the underlying system. Larger organizations need policy engines, control planes, identity, governance, and visibility for CISOs, production teams, and R&D leaders. The platform has to serve both realities without hiding the parts that matter for accountability.

Why Does Agent Experience Matter?

Agent experience matters because code is becoming less scarce. When anyone can generate software, the scarce resources become taste, judgement, architecture, and knowing what is worth shipping.

AX forced us to clarify our architecture, our structure, and our signals. It made the platform easier for agents to use, but it also made us better developers because we had to make implicit assumptions explicit.

That brings the story back to Toria. With an ecosystem designed for agents and for her, she could move past Git, CLI, and deployment configuration. She could put her intention into the world and see the result. She built the experience. The agent and the platform made the path possible.

I gave the full version of this argument at AI Native DevCon London. Agent experience is not really about designing for agents instead of people. It is about designing systems where agents amplify human creativity while humans keep judgement, accountability, and trust.