I talked with Rhys Sullivan about building product in a moment where agents are changing what "user experience" even means. Rhys has worked on products like Vercel Domains, built side projects like Ship Talkers, and is now working full time on Executor, an open source MCP gateway for integrations.
What stood out to me in this conversation was how quickly we moved from "AI tooling is interesting" to a much more fundamental product engineering question: what are the primitives your product is built on, and are they strong enough for the ways people - and agents - will use them next?
Rhys kept coming back to the idea that good product experience and good engineering are tightly connected. When he described working on domains at Vercel, the product problems were not only about interface polish. They were also about error states, API shape, architecture, and whether the system made the right behavior easy to represent.
That is a very product-engineering way to think. The best UI in the world cannot fully compensate for weak underlying primitives. But when the primitives are right, you can build better interfaces, better APIs, better CLIs, better docs, and better agent workflows from the same foundation.
UX, DX, and agent experience
One of my favorite threads in the episode was the way Rhys connected developer experience to user experience in the agent era.
For years, it was easy to think of UX as mostly a frontend concern. But if a user's agent is interacting with your product through APIs, docs, MCP servers, CLIs, or browser automation, then your backend and developer-facing surfaces become part of the user's actual experience.
Rhys made the point that companies with good docs and good OpenAPI specs are especially well positioned right now. Those assets are not just documentation chores. They are reusable product primitives. They help frontend teams, external developers, SDK generation, search indexing, MCP servers, agent workflows, and whatever comes next.
That matters because agents will find ways to interact with products whether we design for them or not. If we do not provide official, thoughtful, secure ways for agents to get work done, people will push agents into worse paths: scraping, browser automation, overpowered CLI commands, or other workarounds.
Slowing down when shipping gets easier
Another theme I appreciated was Rhys's reminder that you do not have to ship everything users ask for, and you do not have to sacrifice product quality just because agents make implementation feel cheaper.
That has been a recurring idea in this season. Agents can help us ship more, and I think they absolutely will. But product engineering is still about judgment. It is still about deciding what should exist, how it should fit together, and when moving a little slower produces something more coherent.
Rhys put it well: the job is to take in signals, find the right primitives, and build a product that works well together. That is becoming more important, not less, as implementation speed increases.
Build a product sense library
Rhys's homework was simple and practical: create a place where you collect examples of products doing something well.
That could be a notes channel, bookmarks, screenshots, links, or whatever system you will actually use. The point is to stop letting good product examples disappear. Save them, revisit them, and use them as input the next time you are designing a flow.
That advice is even more useful with agents. If you have a collection of product examples and lessons, you can feed that context into an agent and ask it to help you apply those patterns to your own work. Product sense becomes something you can compound.
