Why Software Is Starting to Work Like a Restaurant

For most of the history of software, using a computer meant cooking the task yourself.

You didn’t ask for results. You executed the recipe.

You selected the ingredients.
Combined the steps.
Adjusted the seasoning.

Menus exposed the pantry. Sliders revealed the recipe. Dialog boxes walked you through the method.

If you wanted a result, you performed the procedure.

The graphical interface turned users into cooks - executing the system’s logic step by step.

That model is starting to dissolve.

Increasingly, software asks for something much simpler.

Summarise this report.
Make this image warmer.
Turn these notes into a presentation.

The steps disappear. The kitchen moves behind the wall. The system decides how the dish is prepared.

Software begins to behave less like a kitchen and more like a restaurant.

You don’t cook the task anymore.

You order it.

When The Kitchen Was The Interface

Graphical interfaces were designed around visible procedure.

If you wanted to analyse data, you wrote formulas.
If you wanted to edit an image, you adjusted layers.
If you wanted to format a document, you applied styles.

The system exposed its capabilities as tools and parameters. The user combined them.

This model had an important property.

You could see the reasoning.

Select → filter → transform → export.

Even when the process was complex, the logic remained legible. The user wasn’t simply requesting an outcome. They were executing the system’s thinking through the interface.

Cooking the dish meant understanding the recipe.

Why Ordering Never Worked Before

Designers have tried restaurant-style interfaces for decades.

Chatbots.
Voice assistants.
Natural language systems.

The idea was always appealing: just ask the computer for what you want.

But these systems rarely worked well.

Not because the idea was wrong.

Because the design problem was impossible.

The Permutation Problem

To build a conversational interface, designers had to anticipate every meaningful way a person might ask for something.

Not just the task, the phrasing.

“Move my flight to tomorrow.”
“Can I change my booking?”
“I need to reschedule.”
“Is it possible to leave a day later?”

Each variation had to map to the same intent.

Then come the variables.

Dates.
Locations.
Preferences.
Partial information.

Every additional dimension multiplies the number of possible interactions.

Conversation design quickly becomes an exercise in enumerating language. Designers are no longer designing the system. They are maintaining a growing library of sentences.

The permutations expand faster than anyone can manage.

Which is why conversational systems repeatedly collapsed back into menus and buttons.

Cooking the task remained easier than interpreting the order.

What Changed

Large language models change the economics of this problem.

Instead of matching phrases to predefined intents, they interpret meaning across thousands of possible expressions.

The system no longer needs designers to anticipate every variation.

It recognises the concept behind the request.

Earlier conversational systems relied on intent libraries.

Modern systems operate inside conceptual domains.

A writing tool understands documents.
A design tool understands images.
A research tool understands questions.

The permutations still exist.

The model absorbs them.

The kitchen learns how to interpret the order.

A Quiet Shift In Design

This changes the nature of interface design.

Traditional design focused on interactions.

Menus.
Commands.
Controls.
Workflows.

The designer determined exactly how the user would perform each task.

Restaurant-style systems change the question.

Designers define capability rather than procedure.

Instead of scripting every interaction, they define what the system understands, where its authority begins and ends, and how it behaves inside that territory.

The interface stops being a recipe book.

It becomes a place where intent is interpreted.

The Kitchen Disappears

One consequence of this shift is that procedure becomes invisible.

In traditional software, the steps were exposed.

If you wanted a summary, you might select text, run analysis tools, refine the output.

Now the instruction collapses into a single request.

Summarise this.

The system still performs a sequence of operations.

But the user no longer sees them.

The kitchen is still there.

It is simply behind the wall.

The Chef–Critic Shift

At first glance this looks like a change in interface.

It is actually a change in where skill lives.

When software behaved like a kitchen, the user was the chef.

Skill meant knowing the steps.

Which tool to use.
Which parameter to adjust.
Which step came next.

Restaurant-style systems change that relationship.

The system cooks, the user judges.

The role shifts from chef to critic.

A critic does not prepare the dish.

They decide whether it is good.

The Harder Skill

Cooking requires knowledge of the method.

Critique requires something more subtle.

Taste.
Experience.
Context.

Recognising when something is slightly wrong is often harder than producing it in the first place.

This is the quiet trade-off behind intent interfaces.

They reduce the effort required to produce results.

But they increase the importance of recognising when those results are flawed.

Simplicity At The Surface

Restaurant interfaces feel simpler.

Fewer controls.
Fewer steps.
Less visible structure.

But the simplicity is deceptive.

Behind the wall, the kitchen is far more complex than the one the user once operated themselves.

Large models. Retrieval systems. Safety layers. Ranking mechanisms.

The complexity has not disappeared.

It has moved.

When The Signals Disappear

Cooking exposes the process.

You see the ingredients.
You taste as you go.
You adjust the seasoning.

Restaurants work differently. The diner never sees the kitchen. They judge the finished dish.

Intent interfaces create the same condition.

When procedure disappears, many of the small signals that help people recognise mistakes disappear with it.

The steps that once slowed interaction down also helped users understand what was happening.

Remove the steps, and the system feels simpler.

But judging the result becomes harder.

When Everyone Gets Seated

Restaurants do not ask whether the diner has a good palate.

They simply serve the meal.

Intent interfaces work the same way.

They make sophisticated outputs available to people who may have little ability to judge them well.

That is part of their appeal. It is also part of their risk.

The old interface demanded procedural competence. The new one can create the impression that competence is no longer necessary.

But the need for judgement has not gone away.

It has become easier to produce something plausible, and easier to mistake plausibility for quality.

A confident diner is not the same thing as a good critic.

That is the uncomfortable trade-off hidden inside the simplicity.

The Critic’s Table

For decades, learning software meant learning the recipe.

Which tools to use. Which steps to perform. Which parameters mattered.

Increasingly, the system performs the recipe itself.

The user sits somewhere different now, at the table rather than in the kitchen.

When software becomes a restaurant, users stop cooking the task.

They judge the dish that arrives.

The problem is that software does not only turn experts into critics.

It turns everyone into critics.

And recognising when the meal is not good enough turns out to be the harder skill.