Not everything should be a chat box

Not everything should be a chat box

The teams we work with keep arriving with the same request. They have watched large language models get good in a hurry, they have seen the demos, and now they want a chat box bolted onto the front of their product. Our answer is usually a question. What is the job the chat box is meant to do, and is a conversation actually the fastest way to do it? More often than the excitement suggests, the honest answer is no.

The volume knob was already optimal

Consider the dashboard of a modern car. A decade ago the interior of a mid-range sedan was a field of physical controls: a knob for the volume, a dial for the temperature, a stubby toggle for the hazards. Then the big touchscreen arrived, and one by one the manufacturers swept the buttons away. The screen looks clean in a showroom photograph. It is cheaper to manufacture than a dozen distinct switches. It can be updated over the air. Every incentive on the supply side pointed toward glass.

Every incentive except the one that matters when you are actually driving. Reaching out and turning a volume knob takes no eyes and no aim. Your hand finds it, your fingers close, you turn. A touchscreen demands that you look, locate a target, and hit it while the road moves underneath you. Consumer safety bodies have started penalizing exactly this, and several carmakers have quietly begun putting the physical controls back. The knob was not a relic waiting to be digitized. It was the finished form of a solved problem.

We think chat interfaces are about to teach the software industry the same lesson, only faster.

Follow the incentive, not the fashion

It is worth being clear-eyed about why the chat box is spreading. Part of it is genuine capability. A reasoning model can absorb a vague, messy request and do something useful with it, and for a whole class of tasks that is a real unlock. But part of it is simpler and less flattering. A chat box is the easiest thing to ship. It signals to a board, an investor, or a customer that you are serious about the new technology. It requires almost no interface design, because the text field does all the work and the model absorbs the ambiguity. In other words, the chat box is often optimizing for the vendor's need to look current, not the user's need to get something done.

That is the pattern worth naming. When an interface decision is driven by what is cheap to build and easy to demo rather than what is fast to use, the user pays the tax later, one small friction at a time.

Some things are still better as a click

A conversation is a wonderful tool when the task is genuinely open-ended. Describe the report you want. Ask why a number moved. Draft something in a particular tone and then reshape it. These are jobs where the space of possible requests is enormous and a form with fixed fields could never anticipate them. Here the chat box earns its place.

But a great deal of what people do with software is not open-ended at all. Toggling a setting on. Picking one of four options. Confirming a total and moving on. Nudging a value up by one. For these, a switch, a button, or a slider is not a legacy compromise we are waiting to outgrow. It is the correct answer. It shows the current state at a glance, it responds instantly, and it never misunderstands you. Forcing that interaction through a sentence is slower, more error-prone, and strangely exhausting. Nobody wants to type "please increase the brightness slightly" when a finger on a slider would have done it in a fraction of the time.

The interfaces we have today are not all accidents of a pre-AI era. Some of them evolved into their shape because pointing and tapping was, for that particular job, the best possible fit. Discarding those wholesale in the name of novelty is how you end up with the automotive touchscreen: modern on the spec sheet, worse in the hand.

The interesting work is underneath the chat box

Here is the part the current wave tends to miss. The genuinely valuable thing that reasoning models brought is not the conversation at all. It is the ability to plan, to call tools, and to carry out multi-step work with judgment. The chat box is merely the most obvious wrapper anyone thought to put around that ability. It is not the only one, and it is frequently not the best one.

The same model that can hold a conversation can also sit quietly behind a button and do something clever when it is pressed. It can watch what a user is doing and surface the right option before they ask. It can turn one deliberate click into a chain of actions that used to take twenty. The reasoning happens under the surface, and the interface stays exactly as direct and tactile as the task deserves. The user gets the intelligence without being handed a blank text field and asked to describe their own workflow.

This is the design space we spend most of our time in with the teams we work with. The question is never whether to use these models. It is where to put them. Sometimes the answer is a conversation. Often the answer is a smarter button, a control that anticipates, a workflow that collapses because a model handled the tedious middle. The chat box is one tool in the kit. Treating it as the whole kit is the mistake.

What we build for

The companies that win the next few years will not be the ones that added a chat box first. They will be the ones who worked out, case by case, where a conversation genuinely helps and where a well-designed control still wins, and then blended the two so cleanly that users never think about which is which. That blend is craft, and craft does not come from a template.

So when a client asks us to add a chat box, we treat the request as the start of a conversation rather than the end of one. We map the actual jobs their users are trying to do. We put the model where it multiplies what a person can accomplish, and we leave the volume knob alone where the volume knob was already right. The technology is remarkable. The discipline is knowing when not to point it at everything.