AI won't replace the UI. It will change what users have to do

// 6 min read //

Whenever AI comes up in a product discussion, someone eventually suggests a chat box. I get why. It’s familiar, easy to demo, and makes the AI obvious.

But I don’t want to chat with every product I use. Most of the time, I just want the product to save me from doing the boring setup myself.

I’ve been thinking about this from a frontend engineer’s point of view. The opportunity isn’t to replace every form, filter, and dashboard with a chatbot. It’s to stop making people repeat work the software can already do.

If the product can read a receipt, understand a search request, or notice a meaningful change in a dashboard, it should prepare the next step. The user can then review it, correct it, and decide what to do.

That sounds simple, but it changes what we need to build.

Start with the work nobody wants to do

Think about submitting an expense after a work trip.

You paid with a company card, and the transaction is already in the system. The receipt arrived by email. The software knows the merchant, date, amount, and currency.

Then it opens an empty form and asks you to enter all of that again.

You match the receipt, choose a category, add the trip, check the tax, write a note, and submit it. Some of those steps require judgment, but most of them are just moving information from one place to another.

A useful AI flow would be boring in the best possible way. The expense opens as a draft:

  • The receipt is already matched to the card transaction.
  • The category is set to ground transportation.
  • The trip is set to the Amsterdam customer visit.
  • The policy check has passed.
  • The project needs a quick review because the system had to guess it.

Now I only need to check the guess and submit the expense.

The form hasn’t disappeared, and it shouldn’t. I still need to see the values and edit them. The difference is that the product has done the repetitive part first.

This also creates new questions for the frontend. Which values came from the receipt? Which came from a company rule? Which ones did the system guess? If I change the trip, should the project change too?

A normal prefilled form doesn’t answer those questions. The screen needs to tell me what happened without making me inspect every field.

Search should understand the question

Search has the same problem, just with more controls.

Imagine that I’m using a cloud security product and want to find the problems my team should fix first. In plain English, my request is simple:

Show me the production workloads that are exposed to the internet, have critical vulnerabilities, and have a fix available.

A traditional search page makes me translate that sentence into the product’s language. I need to know which filters represent production, runtime status, exposure, severity, asset type, and fix availability. I may also need to understand how the product defines a workload.

At that point, I’m spending more time operating the filter panel than investigating the security problem.

Natural-language search can remove some of that setup, but only if the page shows me how it interpreted my request. I would want to see something like this next to the results:

Understood: production, internet-facing, running workloads, critical severity, and fix available.

Assumed: Kubernetes workloads only because this account has no ECS data.

Not applied: owner because some workloads are unassigned.

That explanation is more useful than a fancy input animation. It tells me whether the search understood the important parts and where it made a decision for me.

I would still keep the normal filters nearby. Sometimes it’s easier to change one filter than rewrite a sentence. They’re also a useful fallback when the search is too broad, too slow, or simply wrong.

Natural language doesn’t remove state management either. We still need to handle empty results, partial matches, cancelled requests, and old responses arriving after a newer search. The complexity is still there. It’s just less visible to the user.

A dashboard should tell me where to look

Most people don’t open a dashboard because they want to inspect twenty-four charts. They open it because they have a question:

What changed, and should I care?

A typical dashboard makes the user find the answer. Revenue, conversion, traffic, churn, regions, devices, campaigns, and errors all compete for attention. The user has to scan everything and decide what looks unusual.

AI can help by pointing to the change first:

Mobile checkout completion dropped 18 percent this week. The drop started on Tuesday afternoon and is mostly affecting Safari on iOS. The new payment step is the likely cause.

That’s a useful starting point, but it can’t be the end. I need to open the chart, check the affected segment, compare it with previous weeks, and see why the product thinks the payment change caused the drop.

The charts are still important. They become evidence for the summary instead of a wall I have to search on my own.

The same rule applies to actions. If the product suggests rolling back the payment change, it shouldn’t happen because someone clicked an exciting AI button. That action still needs the right permissions, a confirmation step, clear progress, failure handling, and an audit trail.

The higher the risk, the more careful the interface needs to be.

What this means for frontend engineers

My rule is simple: let AI make the first pass, but always let the user see and correct what it did.

In practice, that means we need to:

  • Show what the system knows and what it guessed. A user doesn’t need a confidence score on every field, but they do need a clear “check this” message when something is uncertain.
  • Make corrections cheap. Fixing one wrong assumption shouldn’t mean starting the whole flow again.
  • Keep a manual path. Forms and filters are still useful when the user knows exactly what they want or the AI gets stuck.
  • Design the waiting and failure states. The model will sometimes be slow, return only part of an answer, or fail completely. Those aren’t edge cases.
  • Add friction when the risk is high. Suggesting a category is different from changing production or rolling back a checkout flow.

This is why I don’t think AI will replace the UI. If anything, it makes the interface more important. Once a product starts making guesses and taking the first step, someone has to explain those decisions and keep the user in control.

The AI interface I want isn’t a chatbot on every page. It’s a product that saves me ten boring clicks, tells me what it assumed, and lets me fix it without a fight.