Back to Writing

AI is an interface

Every system makes you learn its menus and its query language before it will help you. The useful thing AI does is remove that step: you say what you want, and it works out which buttons to press.

3 min read

For most of computing history, you paid to use a system by learning it. Its menus, its fields, its query language, its API. The software held some model of the world and using it meant translating what you wanted into that model by hand. People who were fluent in that translation made a career out of it.

The most durable thing AI does is remove that step, and it’s a narrower claim than the hype around it. AI is the interface. You say what you want in your own words and the system does the translation that used to be your job. It works out what task you meant, and which operations across which tools will carry it out.

“AI” gets stretched to cover everything, so here’s the narrow version that holds up. AI is the layer that takes “which segment is churning, and why” and turns it into the joins, the queries, the significance tests and the calls to the four systems that actually hold the answer. The intelligence can sit wherever it sits. The interface is the part that just got rewritten, and that’s where most of the value is.

You can see why by looking at what the old interface kept people out of. Analytics lived behind SQL and a BI tool, so the only people who could ask the warehouse a question were the ones who’d learned its dialect. The analyst was a human interface sitting between a manager’s question and the database. Nearly every system worth using had a toll like that: a language, a console, a certification. Once the interface is plain language, the toll comes off, and the person with the question and the person who can phrase it properly become the same person.

If you’re building, that moves where the hard part is. If AI is the interface, then the product is the mapping: intent to task to systems, done reliably, against real data and real tools that are messy in all the usual ways. The model is the half that’s commoditising. The half that earns its keep is the binding between a sentence and the operations it sets off, done well enough that the result can be trusted. That gets serious the moment a wrong mapping means an action was taken rather than a paragraph was written.

Design feels this hardest, because design used to be the interface. The job used to be drawing the screens: every state, every control, every path someone might take, all rendered as something to click. When language carries that range instead, the surface shrinks. You stop drawing a screen for each of the thousand things someone might ask, because the model handles the input you never anticipated. The pixel-level part of the role is exactly the part that flattens, into the same conversation the PM and the engineer are already having, because the four modes were always one feedback loop and the interface was the seam holding them apart.

What’s left for design is the harder half it always was. Working out where language is the right interface and where a direct control still wins. Shaping the tools the model composes so the pieces stay legible. Designing how the system shows its confidence, shows its working, and recovers when it’s wrong, which is where trust gets won or lost. Then the judgement under all of it: what good output looks like, what the defaults should be, which few surfaces still deserve to be built by hand. That’s a bigger job than drawing screens, and it gets measured in whether the thing can be trusted and understood.

None of this happened because the machine got clever. It happened because you stopped having to think like the machine in order to use it, and that was always the expensive part.