Skip to content

The Interface Is a Spectrum

Why useful AI products need fixed UI, conversation, and trusted dynamic surfaces at different moments.

Updated

A cashier should not negotiate with an AI every time they close a receipt.

That sentence is my fastest way of explaining why I do not believe chat will replace UI.

The first AI feature in a product is usually a chat box. It makes sense. The user says what they want, the model answers, and the product suddenly feels like it can listen.

Then the user asks for actual work.

A number. Ten orders. A filter. A form. A refund. A comparison. A risky action.

The chat box starts pretending text is an interface.

That is where the future gets more interesting.

Fixed UI still wins

Menus, tables, forms, dashboards, and buttons are not old because AI exists.

They are excellent for known work. They are fast, scannable, and predictable. Repetition builds muscle memory, and muscle memory matters when someone is serving customers, closing a shift, or managing money.

A cashier should know where the total is. An admin should know what a delete button will do. A finance user should not wait for a model to invent a date filter.

The boring parts earned the right to be boring.

Fixed UI struggles when intent crosses the product's route structure. The user may know exactly what they need without knowing which screen, filter, or report contains it.

That is where conversation helps.

Chat has limits

Language is a strong starting point for ambiguity.

It is good for questions like:

  • Why did revenue drop?
  • Which orders look suspicious?
  • What should I inspect next?
  • Find customers who ordered twice but disappeared this week.

But text is weak for structured work.

A KPI should not hide inside a sentence. Records should not become a wall of markdown. A form should validate fields. A confirmation should expose the action and its pending state.

Text can describe those affordances.

UI can hold them.

The problem is not chat. The problem is turning chat into the final shape for every task just because it is the newest shape in the room.

The middle

The useful layer sits between fixed screens and open-ended generation.

The user can begin with language, then the product can respond with a trusted surface:

  • a metric
  • a chart
  • a table or browser
  • a short form
  • a confirmation
  • suggested next steps

The AI does not have to invent the interface.

It can understand the intent and route it to a surface the product already knows how to trust.

That approach is less infinite than generating arbitrary UI at runtime.

It is also much closer to software I would ship.

The spectrum

The mental model I use is:

Fixed UI
Conversation
Trusted dynamic surfaces
Runtime-generated UI
Full app generation

Each point solves a different kind of problem.

Fixed UI is best for repeated, high-frequency work.

Conversation is best while the intent is still unclear or needs explanation.

Trusted dynamic UI is best when the intent changes but the interaction pattern is known.

Runtime-generated UI is useful for exploration and sandboxed work where the exact shape cannot be predicted.

Full app generation is powerful for prototypes, internal tools, and software creation. It is not automatically the right boundary inside an existing product.

The mistake is treating one point as the future of everything.

Intent is a design layer

Take four prompts.

What is today's revenue?

Show one metric, with enough context to make it meaningful.

Show all open orders.

Give the user rows, search, filters, sorting, and detail.

Close table 7.

This changes real state. Show the action clearly, ask for confirmation, then let the server decide whether it is allowed.

Why did revenue drop yesterday?

This may need a conversation plus a chart and source records. There is no reason to force it into only one medium.

AI does not remove interface design.

It adds routing to interface design.

The product team now decides what surfaces exist, what each one is for, what data it may receive, which actions need confirmation, and what should stay fixed.

That is not less design. It is design at the level of product grammar.

Where Fable fits

Fable UI is my attempt at the trusted dynamic part of the spectrum.

Each installed surface can carry its React component, typed tool, schema, renderer states, manifest, examples, and eval prompts.

The model selects from surfaces the developer allowed. The host still owns data, auth, validation, and side effects.

Fable is not the whole future of UI.

It is one practical answer to the middle.

The question

The future is not menus versus chat.

Human intent changes shape. Sometimes we need the stability of a screen. Sometimes we need to speak before we know where the work lives. Sometimes we need the product to meet that intent with a trusted interface.

So the durable question is not:

Should this product become chat?

It is:

What is the right interface for this intent?

AI does not kill UI.

It makes that question impossible to avoid.