Denniskortsch

Developer In The Loop

May 26, 2026

The Web Becomes Headless

A human-first web page dissolving into an agent-first web, where agents fetch structured information and operate software without traditional browser interfaces

The boring version of the AI product story is: every app gets a chatbot.

I do not buy it.

The chatbot is the first crack in the wall. It starts small, usually inside the product. A better search box. A shortcut for making a chart. A support feature that can do more than paste links from the docs.

Then, if it works, it becomes the fastest way to use the product.

And once that happens, the awkward question shows up: why did the user have to open the product at all?

That is the part I keep coming back to. Software is starting to feel less like a place you visit and more like something your agent calls in the background.

The apps do not disappear. If anything, they may matter more. They hold the data, permissions, history, business logic, and all the messy context that makes work possible. But the place where the user says what they want may move somewhere else.

Maybe that place is Claude. Maybe it is an IDE. Maybe it is Slack. Maybe it is some internal agent console with a terrible name that quietly runs half the company.

Whatever wins, it probably sits above the apps and websites we use now. It calls them, combines them, asks questions across them, and makes whatever temporary interface the human needs to stay in control.

That sounds like a small product change until you follow it down.

It puts pressure on a lot of things we treat as fixed: products live at URLs, users navigate apps, dashboards are built by humans, APIs sit behind the UI, and websites are the natural shape of the internet.

Maybe those assumptions survive for years.

Or maybe we are at the start of a stranger shift: from software you visit to software your agents operate for you.

The pattern

The five-step evolution of software products: AI chat inside the UI, agent access through MCP and APIs, more interactions outside the original interface, and eventually a headless product model

The pattern is becoming hard to miss.

First, AI shows up inside the product. Usually as a chat assistant. A little awkward. Sometimes useful. Often overmarketed.

Then it gets good enough that people prefer it for certain jobs. Not everything. Enough that clicking through the old UI starts to feel slow.

Then the company has to expose more of the product to the outside world. APIs get more attention. MCP shows up. Docs stop being just docs and start becoming instructions for agents.

Then more work happens outside the product. Agents create dashboards. Reports appear from Slack. Setup happens through a wizard. Engineers query the product from their editor.

Eventually the UI is no longer the main character.

It still exists. It still matters. But the product has become headless in practice, even if nobody has put that on the homepage yet.

PostHog is a good live example

PostHog wrote about this in PostHog's next chapter, and the numbers are the interesting part.

They started with an AI assistant inside PostHog. After enough iteration, they found that PostHog AI had become the best way to use the product in many cases, so they made it the default for new users.

Then they shipped an MCP so people could query PostHog from code editors and agent tools. It became more popular than they expected.

The line that stuck with me: last week, the majority of dashboards were created by agents through PostHog AI, MCP, the API, or the onboarding wizard.

That is a strange sentence if you grew up with classic web apps.

Dashboards used to be one of the most UI-native things in a product. You clicked around, picked widgets, arranged them, saved them. Now most of them are being created somewhere else, or by something else.

That is the shift.

Not "PostHog added AI."

More like: PostHog is watching part of its product usage leave the product interface.

And they seem to be leaning into it.

Agents need a new access model

The current human-centered internet, with messy user interfaces and separate APIs, compared with an agent access layer built around MCP servers, machine-readable docs, llms.txt files, and agent permissions

APIs used to be treated as the developer surface. Important, but separate from the main product experience.

That split does not hold up when agents become users.

The current internet was built for humans. Websites assume eyes, hands, patience, and a person willing to interpret a messy page. Buttons, menus, cookie banners, modals, dashboards, hover states. It all sort of works because humans can improvise.

Agents need something else.

They need to know what a product can do, what they are allowed to touch, and how to do the work without scraping a UI that was never meant for them. The access has to be structured enough to be reliable, but not so rigid that every product needs its own private protocol.

I do not think anyone knows exactly what this looks like yet. We are in the weird early phase where a few patterns are showing up, none of them feel final, and everyone is pretending the naming is more settled than it is.

Some of the pieces are already visible:

  • MCP servers that expose product capabilities directly to agents
  • webMCP, or whatever this becomes, for making websites callable from agent environments
  • llms.txt files that tell models where the useful context lives
  • Markdown docs written for machines as much as for people
  • API references that read less like documentation and more like operating manuals
  • permission models that let an agent act for a user without giving it the keys to the whole account

This is the access layer the agent internet needs.

Probably not a website. Also probably not just another API endpoint with nicer docs. More like a strange new layer where an agent can ask: what can I do here, what am I allowed to touch, and how do I show the human what happened?

UI becomes generated

Prebuilt static interfaces at fixed URLs compared with generated temporary interfaces that combine analytics, payments, tickets, commits, and design rules into task-specific screens

I do not think this means UI goes away. People still need something to look at. We need surfaces for approval, debugging, exploration, and trust.

But I am less convinced those surfaces will keep living as static destinations at fixed URLs.

Today, every product has its own place. You go to app.something.com, learn its layout, and operate inside that company's idea of a workspace. The UI is prebuilt. It waits for you.

In the agent version, the UI may be created when you need it.

The same agent that queried your product data can generate a temporary interface to inspect the result. Or a subagent can. It can pull from PostHog, Stripe, Linear, GitHub, and your database, then render the screen you need for the decision in front of you.

Not the main dashboard. Not the settings page some product team argued about months ago. Just the screen you need right now. Then it can disappear.

Show me the five accounts where usage dropped after the pricing change. Give me the relevant sessions, invoices, support tickets, and commits. Add approve and rollback buttons where they make sense. Hide everything else.

That is a very different idea of interface.

And then there is the design question. If the agent generates the UI inside Claude or OpenAI or whatever app I am using, who decides what it looks like? Maybe websites will start shipping something like DESIGN.md: a small design system file that tells agents how the product should feel when they generate a screen somewhere else. Colors, spacing, components, tone, accessibility rules. Not a full app. Just enough taste and structure so the generated thing does not look like random gray boxes.

Where does this happen? Right now it looks like the big labs want it to happen inside their own everything apps. Claude Desktop. OpenAI's apps. Whatever these products become as they absorb chat, browser, code editor, file system, memory, and tool use into one place.

Maybe that is the new super app. Maybe it is just the messy transition before something more open appears. I do not know.

But if agents are the ones touching the product data, it would be strange if the old app or website always remained the place where the resulting UI appears. More likely, the interface shows up wherever the agent is already working.

Meet the users where they are already.

What happens to the browser?

If you keep pulling on this thread, it gets weird fast.

Why do we need the browser in its current form?

The browser is an incredible piece of software, but it was built for a human internet. Pages, tabs, URLs, forms, buttons, cookies, ads, search results, back buttons. It assumes a person is sitting there, looking at pixels and deciding where to click next.

But if the user is increasingly represented by an agent, the browser starts to look like a compatibility layer. Useful because the old internet is still there. Maybe necessary for a long time. But maybe not the natural interface for what comes next.

Will websites still exist? Probably. Will URLs still matter? Also probably. Infrastructure has a way of sticking around forever. We still have email. We still have PDFs. We still have fax machines hiding in hospitals and government offices like ancient cursed objects.

But the center of gravity could move.

A website might become less of a place people visit and more of a bundle of instructions for agents: here is what we do, here is how to call us, here is how to authenticate, here is how to render our stuff, here is what a human needs to approve.

That has strange implications for the internet we have now.

What happens to SEO when agents read the web for us? What happens to landing pages when the buyer never lands on them? What happens to analytics when the most important user is not a browser session, but an agent acting across five tools? What happens to ads when nobody is staring at the page? What happens to cookie banners when there are no cookies because there is no page view in the old sense?

And then there is the uncomfortable people question.

What does this mean for developers and designers?

I do not think they disappear. That answer is too lazy. But the work changes. A lot.

Designers may spend less time polishing fixed screens and more time defining systems that can survive being generated elsewhere. The job becomes taste, constraints, interaction rules, trust, accessibility, and brand as something an agent can apply on demand.

Developers may spend less time building every workflow as a page and more time exposing clean capabilities. The hard part becomes access, permissions, state, context, safety, and making sure an agent can do useful work without quietly wrecking everything.

That sounds less glamorous than shipping a beautiful dashboard. It is also probably more important.

The web was built for humans asking machines for pages.

The next one may be built for humans asking agents for outcomes.

I do not know exactly what that internet looks like. Nobody does. But I am pretty sure it will make a lot of today's product assumptions feel strange in hindsight.

Maybe the browser remains the main window into software.

Or maybe, a few years from now, opening ten tabs to answer one question will feel as outdated as opening a phone book.