Primitives for Generation

Earlier this year, Michael Grinich gave a talk called “The Death of UI”. One phrase stuck with me: the components we build and maintain should become “primitives for generation.” I take that to mean components a model can compose into a useful interface.

I’m a designer who writes front-end code, and I’ve worked on a lot of product interfaces. Now I work on a large product and the design system behind it. Models and agents can answer many of the questions that once sent customers hunting through a UI. I’ve been trying to work out what that shift means for the interface itself.

Ask and you shall receive

Not every product makes its capabilities equally easy for an agent to use. An agent can fall back to operating the product as a person would: driving a browser, reading pages, and clicking through flows. But then it has to infer what each page is for and how to use it. A product built for agents makes those capabilities explicit. The agent can discover what it can do, send structured input, and get structured results, with the same access as the person who asked.

Cloudflare’s new CLI is one example. Its cf cli search command lets an agent find an operation from a natural-language description, then query an account directly. Say you want to know which HTTP status codes appear most often in your traffic. With the right access, cf can answer that:

$ cf sql query \
  'SELECT edgeResponseStatus AS status, COUNT(*) AS requests
   FROM events.httpRequests
   GROUP BY edgeResponseStatus
   ORDER BY requests DESC
   LIMIT 5' \
  --scope-account "$ACCOUNT_ID" \
  --time-since "2026-10-14T00:00:00Z"
[
  { "status": 200, "requests": 184392 },
  { "status": 304, "requests": 12841 },
  { "status": 301, "requests": 2964 },
  { "status": 404, "requests": 1207 },
  { "status": 403, "requests": 418 }
]

For a question like this, the dashboard is no longer the only path to an answer. You could find it there too, but first you’d need to know which page has the data, choose an account and time range, and work through the available controls. The answer is still in the product; the dashboard makes you follow the route someone designed to reach it. An agent can start with the question instead.

The product UI sets the path

A dashboard sends you somewhere to do something, and someone has to decide where that is. Does single sign-on live under Settings or Security? Does a new product get its own section or a tab on an existing page? Those choices become routes customers have to learn.

Sometimes an answer is split across pages. To find out whether a release changed performance, you might check when it went out in one place and look at latency somewhere else. Neither page is broken; they divide the product into sensible parts. Your question just crosses the boundary between them.

Different people need different views

Dashboards serve people with different jobs. The person checking the bill once a month uses the same navigation as the developer on call tonight, though they need different things. One sidebar has to make room for both, and everyone in between.

Custom views and pinned pages help, but they still ask people to tailor a view somebody else started. The person checking the bill does not want to rearrange anything. They want to know how much they owe this month.

When pages fall short

Sometimes the page in front of you doesn’t offer the view you need. Maybe you need to filter a list by a field it doesn’t include, or look at a time range outside its presets.

Until recently, you had to wait for the page to change or find another route: export a CSV, pull data from the network tab, or write a script against the API.

An agent can handle that workaround. It can apply the missing filter, use the range you need, or join data from two parts of the product, then give you an answer without waiting for a release.

The same components, rearranged

An agent’s reply doesn’t need a new kind of interface. It can use the charts, tables, and log lists we already ship, arranged around a question instead of a page.

That’s what makes a component a primitive for generation: it can stand on its own. A chart can’t depend on the filters or layout of the page around it. It needs typed inputs, like a service and time range, and enough context to explain the result and show its source. With those, the same chart can work in a reply or on a dashboard.

My guess is design-system teams will need to define components by what they need and do, not just where they belong on a page. UI engineers will need to make sure they still work when an agent combines them in ways no one designed by hand.

The product UI stays

Michael’s argument goes further: agents will go straight to APIs and MCP servers, and a product’s UI will become “just a projection layer” on top of its data. I don’t think that’s the whole story. Customers still need somewhere to come back to.

A blank prompt is a poor place to start when you’re trying to understand a product or keep track of something over time. Michael made a similar point about ChatGPT, which starts each session with an empty box despite knowing a lot about you. A dashboard can provide orientation, but it can do more: it can become a canvas, a stable place to arrange components into a view that fits the work in front of you.

A dashboard can make the wider situation visible, too: an error rate climbing over the last hour, a feature being retired, or a metric changing after a release. That context is useful even when nobody thought to ask the right question.

Teams need that shared space, too. Five people investigating an incident need a screen they can look at together; support needs a page to link in a reply. Michael put the value of consistency plainly in the Q&A: “Every time I get in my car, I don’t want the steering wheel to be in a different place.”

Where the hours go

I wonder if this changes how design engineering teams think about their work. A chart on a dashboard can rely on the page around it to give it context. In an agent’s answer, that same chart may need to make sense on its own. And if an agent can answer a question by combining data we already expose, do we need to build another page or add another filter to the UI?

That makes me wonder how we decide what belongs in the dashboard. A view people check each morning, watch during an incident, or share with support needs somewhere to live. As customers find different ways of working with agents, at their own pace, their expectations of the product may change too. I suspect we’ll be having this conversation more often: which views need a place to come back to, and which can be assembled when someone asks?