AX is the only Experience that Matters

What should developer tools look like if agents become their largest group of users? Ivan Burazin opens with a deliberately speculative prediction: the agent population could resemble the human population raised to some power N. He does not know N. The practical observation behind the metaphor is that people already use multiple agents, and agents can start more agents.

Burazin cites 25% of YC startups saying AI writes 95% of their code. He also cites 37% of the then-latest YC batch building agents as products. These are attributed figures, without a survey methodology or independently established cohort in the talk. The distinction matters: agents are becoming products in their own right, beyond autocomplete and copilots embedded in existing software.

That creates a concrete tooling problem. A workflow may appear complete while a person is available to handle its awkward steps, yet break as soon as that person disappears. If agents become the developers operating these tools, the product must support them as direct users. Designing only for the person behind the screen leaves that dependency unresolved.

Agent experience, or AX, extends the familiar concerns of user, customer, and developer experience to agents. Burazin credits Matt, Netlify’s co-founder, with coining the term, and separately attributes the definition he uses to Sean at Netlify. The Netlify AX discussion provides the broader context: how easily can agents access, understand, and operate within digital environments to accomplish a user-defined goal?

Authentication is the first obstacle. An agent sent to complete a task may stop at a login screen, but handing it the user’s passwords is a poor solution. Burazin uses Arcade to describe a handoff: the agent requests authorization, the user logs in, and the agent resumes. Delta and Booking.com are his illustrative destinations, rather than established integration guarantees. Authorization can also be prepared before the task starts. The useful pattern is to separate user authorization from agent execution; retained authorization can still expire or be revoked.

Documentation is the next layer. Stripe provides Burazin’s example: append .md to a documentation URL to obtain clean Markdown. Removing presentation clutter makes the underlying instructions easier for an agent to consume. He also recommends the llms.txt proposal, pointing to the conference website as an example. The purpose is straightforward: make the information an agent needs easy to find and read.

Readable instructions only help if the corresponding operations are accessible. API-first design exposes functionality through a machine interface that an agent can invoke efficiently. Burazin leaves MCP’s future open; his point is that the underlying operations still need APIs. He names Neon, Netlify, and Supabase as services that, to his knowledge, expose the key functionality agents need.

Authentication support, readable documentation, and APIs improve access. But do they complete the definition? Burazin adds one word to each part: an agent should autonomously access, understand, and operate within its environment. This changes the design question from whether an agent can perform individual operations to whether it can finish the task.

The authentication handoff illustrates the boundary. It helps an agent proceed, but a workflow that repeatedly returns to a person still depends on that person being available. Imagine nobody is there to click the next button or debug an error. Those interruption points are where tool builders have more work to do.

Burazin frames this distinction through swyx’s challenge that AX is simply developer experience with a new wrapper. If the product only makes familiar developer operations easier to call, that criticism has force. Autonomous task completion is the proposed distinction: the environment must also address the steps that otherwise require a developer to intervene.

The infrastructure examples come from Burazin’s progression through several generations of developer tools. He began with physical data centers and server rooms: installing servers, running cables, and loading Windows Server from CDs. He then built what he describes as the first browser-based IDE in 2009, an early effort that required custom orchestration and isolation. Later, he led developer experience at Infobip, a communications platform exposing email, SMS, and voice through APIs.

At Daytona, he reunited with people from earlier companies, briefly recommending that founders work with trusted former colleagues when possible. The new product is presented as secure, elastic infrastructure for running AI-generated code: an agent runtime built around sandboxes.

Those sandboxes provide computing environments for code execution, data analysis, reinforcement learning, computer use, and even agents playing games such as Counter-Strike. The analogy is a laptop: a human uses a laptop to work, while an agent uses a runtime. Building that environment required translating AX principles into concrete infrastructure behavior.

The first requirement is speed. When a person interacts with an agent through Claude or ChatGPT, tool startup becomes part of that person’s wait. Burazin reports approximately 27 milliseconds for Daytona runtime spin-up, without benchmark conditions. API access then lets the agent start, stop, clone, and delete machines itself.

Once the machine is running, the agent needs useful operations inside it. Daytona preloads headless tools—a file explorer, Git client, language server protocol tooling, and terminal—to reduce dependence on interpreting terminal output for every action. Fast startup and accessible operations satisfy much of the original AX definition.

Customer workflows exposed the remaining gaps: agents could reach a point where they could not proceed without a human. The resulting features are examples of how to discover missing capabilities, rather than a universal checklist that every tool should copy. Each begins with a task the agent could almost complete.

A Daytona sandbox can start from an existing Docker image. If the agent needs another dependency, it can install it through the terminal API. For example, adding a Python data-analysis package can be as simple as:

python -m pip install pandas

That solves a missing package in one running environment. Repeating the process for many dependencies across successive environments wastes time and resources.

The conventional repair introduces another workflow: a human builds an image, publishes it to a container registry, and makes it available to the agent. Asking the agent to manage that whole build-and-publish sequence removes the explicit human handoff, but Burazin describes it as slow and brittle. The environment setup problem remains.

A declarative image builder moves that work behind a smaller request. The agent specifies what it needs; the infrastructure constructs and launches it:

1. Select a base image.
2. Declare the dependencies to install and commands to run.
3. Have Daytona build the image and open a sandbox from it.

For the package example, pandas becomes part of the requested environment rather than a repair repeated after each launch. The agent can request something new and obtain a usable environment without waiting for someone to prepare an image externally.

A developer running several containers on a laptop has a shared local context. A large dataset on that laptop can be made available to multiple environments. Remote, isolated agent sandboxes do not automatically have that common storage. Burazin describes customers needing approximately 100 GB of data in every machine. Repeated downloads from, or uploads to, S3 recreate the transfer work for each environment.

Daytona Volumes supply the missing shared storage. The agent creates a volume, uploads the dataset once, and mounts it as a network drive on each machine that needs access.

The change is where the shared context lives: in a volume accessible to the sandboxes, rather than on a human’s laptop. Burazin describes flexible volume sizing; this is not an unlimited-capacity guarantee.

Parallel execution changes the shape of the work itself. A person typically concentrates on one machine, perhaps two. An agent can try alternatives concurrently instead of repeatedly attempting an approach, rejecting the result, returning to the starting point, and trying again.

The runtime operation is to fork a machine, pursue different alternatives in the forks, and use their results to reach an output. Burazin mentions five, ten, and even 100,000 forks as illustrative scales, not measured throughput. The essential capability is concurrent exploration from a common starting environment. Like image building and shared volumes, this feature emerged from what customers needed their agents to do.

The future AX feature set is still being discovered. Burazin does not claim to know what comes next; teams building agents are only now revealing what their tools lack. A point where a person must step in is a useful place to investigate an unfinished workflow. His prediction that agents will become the largest user population motivates this focus, rather than a belief that humans will disappear.

Daytona’s own priorities changed accordingly. The team initially invested heavily in developer experience, including its terminal interface. With a small company’s limited resources, the question became less about how polished that interface could be and more about whether the agent could complete the task end to end. A good CLI still has value, but it does not resolve a missing operation, an environment that needs manual preparation, or a task that stalls before completion.

Burazin closes with a deliberately absolute warning that products agents cannot use will eventually have no users. Read as a design priority rather than an established forecast, it directs attention to who will actually operate the product. His invitation to inspect Daytona’s public repository was an open-source invitation at the time of the talk; the repository now says core development moved private in June 2026 and public maintenance ended. The enduring product question is whether the agent can carry the user’s task all the way through.