Writing
4 min read

AI Won't Scale Until the Interface Does

AI productivity won't come from smarter models. It will come from interfaces designed around real work.

AI Won't Scale Until the Interface Does

The models aren't the problem. The interfaces are.

That's the uncomfortable conclusion buried in the productivity data. When Ethan Mollick's team studied financial professionals using AI, they found something counterintuitive: giving knowledge workers access to AI chatbots didn't produce the gains the model's capability suggested it should. The cognitive overhead of figuring out what to say, how to prompt, how to iterate when the output missed the mark - that overhead consumed a significant portion of the gain.

The AI was capable. The interface was wrong for the job.

Look at the tools that are actually working. Claude Code succeeds because it's built for a specific user doing a specific kind of work. It doesn't ask developers to describe their task in natural language and hope the model figures out the rest. It integrates into the workflow, understands the context, and narrows the interaction surface to what actually matters. Cognitive load stays low because the interface was designed around the work - not around access to a model.

The gap isn't between what AI can do and what humans need. The gap is between what AI can do and how it's currently packaged for most people.

And most people aren't developers.

That's the design problem at the center of the AI productivity story. For developers, specialized tools exist: Claude Code, Cursor, GitHub Copilot - each built around a specific workflow, a specific context, and a specific set of decisions. For everyone else, the market has mostly offered one thing: a chat window.

A chat window is not a tool. It's a blank canvas. Blank canvases work well for people who know exactly what they're doing with them. For the financial analyst, the HR manager, the operations lead, the content strategist - a chat window is both the interface and the interaction paradigm. It's too generic for either job to go well.

Early signals of what comes next look like NotebookLM. Look at Stitch. These are AI-native tools that aren't trying to be general-purpose. NotebookLM gives researchers and writers a way to work with large bodies of information without learning how to prompt an LLM. Stitch gives designers a way to generate and iterate on UI without needing to understand the model underneath. The interaction surface fits the task, cognitive load drops, output quality rises.

This is the design pattern the next wave of AI tools needs to follow. Not "give people access to powerful AI." Give people interfaces built around what they're actually trying to do.

That distinction changes what the design problem is. The first-generation AI UX challenge was: how do you make an AI chatbot usable? How do you onboard someone into prompting? How do you make the response legible?

The second-generation challenge is different: how do you build an interface so well-fitted to a specific job that the AI capability inside it almost disappears? Users shouldn't be thinking about the model, they should be thinking about their work.

This is where design thinking is most needed and least visible right now. The companies shipping AI are mostly model companies, platform companies, or software teams bolting on AI features. They're optimizing for technical adoption - not for the cognitive reality of a knowledge worker trying to close a deal, write a report, analyze a market, or plan a project.

Designing the interaction layer between AI capability and human context requires genuine design discipline. It requires understanding the job to be done. It requires knowing where cognitive load spikes and why. It requires deciding which decisions stay with the human and which get delegated to the system. It requires designing for error states, for trust calibration, for the moment when the AI is wrong and the user needs to catch it.

None of that is an engineering problem. It's a design problem.

The productivity gap will not close by itself, and it will not be solved by better models or a longer list of features. It will close when interaction design finally fits the job well enough that cognitive overhead falls away and the AI’s real capability can come through.

For most workers, that moment still has not arrived. That is not a critique of what has been built so far, it is simply a description of the work still in front of us.

Right now, the knowledge worker who could be more capable, more informed, and more effective is still staring at a chat window, trying to figure out what to type next. Building the interfaces people actually need is a design problem, and it remains largely unsolved.

uxaidesignproductivityinterfaces