I was reading Bubble’s write-up of its October founder AMA (held on 26 October), and one demo made me sit up: co-founder Emmanuel Straschnov showed the Bubble MCP working inside both ChatGPT and Claude. Bubble launched its Agent 2 and the Bubble MCP (still in beta) at the start of October, and the idea is that you connect your own AI tool to your Bubble account and build from there.

Now think about that for a second. Bubble is a no-code app builder. Its whole reason to exist was a visual editor: drag this, drop that, wire up a workflow, no code needed. And here it is, meeting its users inside somebody else’s chat window, where the “editor” is a conversation. If even the companies whose product IS the user interface are doing this, I think it’s fair to say something has shifted.

The Front Door Moved

I’ll be honest, I hold a fairly strong view on this one: UIs as we know them are on their way out. Not overnight, and not for everything, but for a lot of the software people use at work, the interface is going to be their agent (Claude, ChatGPT and the likes), which does the clicking, the filling in and the navigating on their behalf. You’ll still have screens for the things humans genuinely want to look at. You just won’t spend your day hunting through menus to change a setting.

Sure, you can argue that chat is a clumsy way to build an app, and for some tasks you’d be right (try describing a pixel-perfect layout in words and see how far you get 🙂). But that misses the point. The point is where the user starts. If people begin their working day in an AI assistant, then the products they use need to be reachable from there, or they’ll slowly stop being used at all.

Agent Experience Is the New UX

Here’s what this means for engineering teams: the quality of your product, as an agent sees it, matters more and more, and the agent doesn’t care how nice your buttons look. What it cares about is your API, your MCP tools and, above all, how well those tools are described. I’d go as far as saying the tool descriptions are the new UX copy, and most teams are writing them as an afterthought.

I see this every day with Calendrz. It has an MCP server that Claude.ai and ChatGPT connect to, with tools to read your events, look at and change your availability mirroring preferences, trigger a sync, add or remove connected accounts and so on. When you’re logged in to the web app, the same kind of tools are exposed to in-browser agents through WebMCP. And as far as the agents are concerned, the code behind those tools matters a lot less than the text describing them.

Let me give you a real example. Our tool for reading events takes optional startDate and endDate parameters, while the events it returns have start and end fields. Perfectly sensible to a human. An agent, though, can quite happily send start and end as the filter, because that’s what it has just seen in the output. So the description says, in plain words, that the JSON key must be startDate and that it shouldn’t use start/end, which are only the names of fields in the returned events. Not elegant, but it works. Similarly, the description of the tool that removes a connected account opens with a “WARNING” in capitals: it’s destructive and irreversible, and the agent must always confirm with the user before calling it. In a UI you’d put that in a confirmation dialog; for an agent, the description IS the confirmation dialog.

What I’d Tell a CTO

If you’re running a product team, I’d start treating agents as a first-class user segment, with their own “UX” reviews. Build API-first and MCP-first, so anything a human can do in the UI an agent can do through a tool. Have someone own the tool descriptions the way a designer owns the screens. Test them the way you’d test a UI: hand a real agent a real task and watch where it trips up. And think hard about what needs a human confirmation, because an agent that can do everything with no friction is also an agent that can delete everything with no friction.

Bottom line: your next most important user might not have eyes. Make sure your product makes sense to it 😉