The paradox of chat
Chat is great for ambiguity. It is a bad map of what a product can do.
Something feels off about a lot of AI products.
ChatGPT feels like a power tool. Claude Code feels like a power tool. Even a raw model in a plain playground can feel like a power tool if you know what you want from it.
Then the same technology shows up inside ordinary apps and somehow becomes weaker: a little sparkle button, a text box in the corner, “Ask AI,” a long answer where a button should have been.
The model did not get worse. The interface did.
The difference is the map.
Developers tolerate the blank chat box because they already have one. Claude Code works partly because developers know terminals, files, tests, git, logs, diffs, and package managers. The model may be new, but the action space is familiar.
Most users do not have that map. They do not know what the chat can see, what it can change, what tools it has, or where its authority stops. Even developers hit this when the chat sits inside a product instead of their dev environment. The interface makes you reverse-engineer the product through conversation.
This is the paradox of chat: it is the easiest AI interface to open and one of the hardest to use well. It lets anyone start, then asks them to discover the product by guessing prompts.
A blank prompt feels like freedom. In many products, it is just the product hiding what it can do.
Use chat while intent is fuzzy. Once the action space is clear, render the interface.
This is why the problem belongs to the whole product team. Engineers decide what tools the model can use. PMs decide which actions matter. Designers decide whether those actions are visible. A blank “Ask AI” box can hide weak thinking from all three groups.
A box can be too empty
A decent button tells you what it does. A form tells you what it needs. A menu tells you what exists. A disabled state tells you what is possible, just not yet. Even a bad settings page gives you a crude map of the product.
A chat box gives you almost nothing. It sits there politely and waits for you to become articulate about a system you have not yet been shown.
That can be great when I truly do not know where to begin. It can also be exhausting when the product already knows the available actions and refuses to show them to me.
You see this in SaaS all the time. Mature products have filters, permissions, saved views, and reports. Then AI arrives as “Ask AI.” The interface goes from specific to vague.
Imagine a personal finance app that opens with a single prompt:
How can I help?
Friendly. Also almost useless.
Can it see my transactions? Can it move money? Can it cancel subscriptions? Does it know which charges are recurring? Can it compare this month to last month? Can it make a budget? Can it talk to my bank or only summarize exported CSVs?
The blank box does not answer any of that. It makes me guess.
In the example below, the prompt box does not disappear. It just stops being the only way to understand the product.
Example 01
The same capability, exposed as a real workspace.
Blank chat
FinanceOps Workspace
3 accounts synced · policy controls activeNo capabilities shown
The model may be capable. The interface is not telling you what is possible.Visible workspace
FinanceOps Workspace
3 accounts synced · policy controls activeAvailable actions
Same model. Different surface. The second one teaches the user what is askable.
Nothing magical happened. The model did not get smarter. The product just stopped hiding itself.
A good interface does not only accept input. It teaches the user what kind of input makes sense.
The chat-shaped horseless carriage
Pete Koomen has a good phrase for a lot of early AI software: AI horseless carriages. Early cars copied horse carriages because that was the shape people already understood. The engine was new, but the design assumptions were old.
A lot of AI products copy the demo.
ChatGPT made the blank box feel native to AI, so teams ship one prompt, one answer, and maybe a few suggested questions. But ChatGPT is general-purpose. Most products are not.
Finance, booking, analytics, support, and coding products already have objects, actions, constraints, states, and permissions. Hiding those behind a prompt does not make the product smarter. It makes the user discover the product the slow way.
It is tempting: cheap to ship, easy to demo, and broad enough for requests the team did not design for. But it can hide missing product thinking. Instead of defining what the system can see, change, confirm, and show, the team hands the user an empty prompt and calls it freedom.
The problem is not natural language input. The problem is treating natural language as the whole interface. A sentence can be a good way to express intent. It is often a bad way to compare options, confirm actions, inspect state, or choose from known alternatives.
The result is a product that feels powerful in theory and vague in practice.
Conversation is not automatically faster
Chat feels fast because typing one sentence is fast. The full task may still be slow.
Take restaurant booking.
If I type:
Book dinner for two tonight.
The assistant probably has to ask follow-up questions. What time? What neighborhood? Any cuisine? Price range? Outdoor seating? How far are you willing to travel? Is 8:30 okay? Do you want this place or that place?
The same known options fit better as controls:
Example 02
Reservation flow: transcript versus controls.
Chat collects one field at a time
- turns
- 6
- words
- 64
- reservation
- not yet
Controls show valid choices together
- taps
- 3
- words typed
- 0
- reservation
- ready to reserve
Chat is useful when intent is fuzzy. Once the fields are known, controls are faster.
At some point this stops feeling like a conversation. It is a form pretending not to be a form.
A normal UI can show cuisine chips, available times, a map, price filters, photos, ratings, distance, and a reserve button in one screen. I can scan that faster than I can answer a sequence of questions.
This is where chat loses. When the options are already known, prose becomes friction.
The same thing happens in support, account settings, cancellation, scheduling, shopping, analytics, and permissions. If there are three valid next steps, show me three buttons. Do not make me negotiate with a paragraph.
Words are a bad interface for some decisions
A user says:
I want to cancel my subscription.
A bad chat response says:
I can help with that. Before you cancel, you may want to know that your current plan includes access to premium features, saved projects, and account history. If you are having trouble, I can also help you troubleshoot billing, switch plans, pause your subscription, or explain what happens after cancellation. What would you like to do?
Sometimes this is a dark pattern. Sometimes it is just too much language. Either way, the product has turned a decision into a negotiation.
A better interface might show:
- Keep plan
- Pause for 30 days
- Switch to cheaper plan
- Cancel subscription
The user can still ask a question. The product can still explain consequences before the final destructive action. But the primary interaction should be shaped like the decision.
If the next step is constrained, use UI.
If the next step is ambiguous, use chat.
Where chat actually wins
The mistake is to turn this into “chat is bad.” It is not. Chat wins when the user has a goal but not a shape.
Good prompts:
- This code is broken and I do not know why.
- I need to write a difficult message but I do not want to sound defensive.
- I want to understand my spending, but I do not know what to look for.
- I need a trip plan, but I only know the vibe, not the destination.
In each case, asking the user to pick from a fixed menu too early is worse. The user is not choosing from known options. They are trying to turn confusion into structure.
Chat is good at that. It can ask a clarifying question, infer missing context, propose a first shape, and help the user notice what matters. That is the job: help the user turn confusion into structure, not keep everything as a conversation forever.
The interface should change shape
The best AI products I can imagine do not choose between chat and UI. They move between them.
A flight assistant should not stay as a wall of messages after I say:
Help me find a flight to Tokyo in June.
It should ask one or two questions if it needs them. Then it should become a flight search product: dates, prices, stops, airlines, departure times, cards, filters, comparisons.
A finance assistant should not answer “help me understand my spending” with a long report and then wait. It should summarize the obvious patterns, then show actions:
- Find subscriptions
- Compare to last month
- Show unusual charges
- Make a budget
- Export CSV
The important move is not adding chat. It is changing the surface once intent becomes clear:
Example 03
Chat turns into an operating surface.
- 1Request
- 2Scope
- 3Summary
- 4Workspace
The chat handles ambiguity first. After scope is clear, the interface becomes tools, results, and decisions.
A coding assistant should not only explain the bug. It should show the failing test, the suspect files, the proposed patch, and a button to apply or reject each change.
The chat is useful at the beginning because the user may not know where to start. Once the system knows the task, the product should become specific.
Use chat until the options are known. Then stop chatting.
A simple rule
| Moment | What to render |
|---|---|
| The user cannot explain the problem yet | Chat |
| The user knows the goal but not the steps | Chat plus suggested actions |
| The valid options are known | Buttons, forms, cards, filters |
| The user needs to compare many things | Tables, grids, charts, maps |
| The system can take action | Scope, permissions, and confirmation |
| The action is risky | Explicit UI with consequences |
| The user needs judgment or wording | Chat |
| The user needs to choose one of three things | Please, just show the three things |
The point is not that one interface wins. The point is timing.
Chat is a great interface for ambiguity. It is a bad interface for obvious choices.
What product teams should build instead
The product team’s job is not to replace every screen with a conversation. The job is to expose what the system can do.
Stop asking, “Where do we put the chat box?” Start asking:
- What can the system see?
- What can it change?
- Which actions need confirmation?
- Which choices are already known?
- Which outputs should be tables, cards, charts, maps, diffs, or forms?
- When should the interface stop talking and render controls?
Give the model tools, but give the user affordances. If the system can take action, show it. If confidence is low, show uncertainty. If it may send, spend, delete, book, or publish, show the draft and ask. If the user needs comparison, render the table.
Most important: let the interface become more specific as the user’s intent becomes more specific.
The blank chat box is seductive because it looks like freedom. But freedom is not always what users want.
Often I want the product to narrow the world for me: show the possible next steps, rule out nonsense, make the tradeoffs visible, and tell me what it can and cannot do. Do not make me discover the product by guessing prompts.
The way out is not to abandon chat. It is to stop asking chat to be the whole interface.
Chat is magical when I do not know what I want yet.
Once I do, give me a button.