Generative interfaces: a glimpse of the future

In September I let a general-purpose AI agent run small errands for me. It ordered food on DoorDash and bought things on Amazon, which felt new. Then it failed to create calendar invites without explaining why, and said slightly the wrong thing when I asked it to message someone.

None of it was a disaster. But each failure made me less willing to hand it anything that mattered.

I think it showed me what rigid interfaces quietly do for us. A fixed UI makes clear what it can and cannot do, like a McDonald’s: same Big Mac, anywhere. An interface with no UI is closer to a slot machine. High variance, the occasional flash of brilliance, and no way to know which pull pays out.

AI is now starting to draw interfaces, somewhere between those two. Ask “am I running more than last month?” and the right answer is probably a bar chart. The question I keep coming back to is who decides what goes on it.

a dial

It helps to think of a dial. At each step down, one more decision moves from the model to the people who built the system:

The top setting is impressive. Google’s research has a model write a full page for any prompt, and people preferred it to plain text 82.8% of the time (paper). But it takes a minute or two, and pages made by human experts still won.

The middle is where most products sit. The model may only use components you built, so it can’t render anything you didn’t design. It still types the numbers into the chart itself, though.

Lower down is a newer kind of model. Jev and Clef don’t write text at all (TypeSafe, Cloudflare). You ask a question with fixed options, such as “does this person want a comparison?”, and they return a probability for each, in tens to hundreds of milliseconds.

The obvious objection is that any language model can already do this. Constrain its output to “yes” or “no”, read the probability of each token, and you have a decision model. Speed is part of my answer, but the bigger part is what the number means. In a chat model, token probabilities are a by-product, and post-training distorts them. In OpenAI’s GPT-4 report, the pretrained model’s confidence tracked its accuracy closely, and after reinforcement learning from human feedback it tracked it much less well (OpenAI). In a decision model, the probability is the output the model is trained to get right. Each question is also answered independently, so one answer can’t quietly steer the next.

read, judge, decide, draw

Put these together and you get the pipeline I’m most interested in:

extract(key_data)
  -> judge(small yes/no questions)
  -> decide(rules)
  -> compose(premade UI)

An LLM extracts the facts from your words, with the exact phrase each one came from. A decision model answers a few yes/no questions about them. Plain code picks the components and binds every number to your real data.

The model’s work ends at the second step, and the whole thing can run in a few hundred milliseconds. Cloudflare describes the same split in its Clairic launch (Cloudflare).

To see the difference, I built a sketch of it. The models in it are stand-ins for now: simple keyword rules play the extractor and the decision model, so it shows the mechanism, not how accurate real models are. Pick a request and watch each step, then flip the switch to see the same screen as a model would have written it:

The two versions draw the same chart, but the numbers come from different places.

A writer could put a wrong number on screen and nothing would tell you. In the composer, numbers come from two places, and each fails in a way you can see. Numbers from your data, such as last month’s distance, are read from the record by code, so no model ever types them. Numbers from your words, such as “last month” or “5 km”, are extracted, and an extractor can misread them. But each one carries the exact phrase it came from, so a misreading shows up next to the words that caused it.

The composer can also explain itself. For “am I running more than last month?”, a 0.90 on wants_comparison fired rule R4, which chose the bars. If the screen were wrong, I could tell whether the model misread me or my rule was bad. That is exactly what the agent in September couldn’t tell me.

maybe

Probabilities also make “maybe” visible. Ask the sketch “I’m running late to dinner” and it scores 0.55 on wanting to text my friends. That’s not a yes, so it doesn’t send anything. It shows a draft and a Send button instead. Try moving the probability yourself:

Rima Cao found something similar: people hesitated when they couldn’t predict what the assistant would do if they followed it (Fairy Cursor, DIS 2026). A draft answers that before you have to ask.

All of this depends on 0.55 meaning something close to a 55% chance, and nobody should assume that. TypeSafe’s own guide says to test thresholds by plotting confidence against accuracy on your own data (TypeSafe). In one of its examples, sorting 60 company filings into industries, the answers it was confident about were right 93% of the time, and the rest only half the time (TypeSafe). So the bands in the figure are where I would start. Where they end up should come from a reliability plot on real requests.

without a screen

All of this also assumes a screen and clean input. At Tacit I work on wearables for silent speech, where neither holds. Input from the body is noisier than typed text, and with a screen you fix a misheard word by glancing at it. Without one, a misheard word travels: the extractor reads the wrong phrase, the decision model judges the wrong facts, and the system acts confidently on something you never said. To me this is the strongest case for the pipeline. Each stage can hand the next one a probability and the span it came from, so doubt about what you said stays attached to the decision, and code can ask before it acts instead of after.

Conversation also sets the clock, and a page that takes a minute to generate is far outside it. I go through that budget, and how speech models try to fit inside it, in A survey of speech-to-speech models. On the body, I don’t think the top of the dial works at all.

Speed is not the whole problem, though. Dev Patel, the engineer behind voice AI at Boardy, says his team had more than 30,000 hours of conversation in a single month, and made a short video about what he learned (X). An answer can arrive instantly and still be hard to follow. When everything comes through words, “you have to build the picture in your head.” The video cites two experiments in which students solved over 50% more problems when the narration came with synchronized visuals.

His demo goes further than showing a chart. It plots a business’s costs against its revenue, and when you ask what happens if growth is slower, the curve bends and the break-even point moves. You can see why the answer changed, and point at the part you want to question.

I agree with him. If there is only voice, the system still has to help people see the picture. And once someone asks “what if growth is slower?”, the voice and the chart have to agree on a new number. I would want that number to come from code, the way the composer binds it, not from a model describing it.

faster won’t fix it

Models will get faster, and the top of the dial will become usable for more things. I don’t think that changes the conclusion, because the case for the composer was never only speed. A number on screen should come from your data. A decision should come with a probability you have checked. And when something goes wrong, you should be able to tell which part was wrong. A faster writer still can’t tell you that.

So I’d rather read with a model, judge with something small, and decide with code. If you’re building one of these, I’d like to know where on the dial you ended up.