What Designers Should Take From Benedict Evans’ Latest AI Deck
Benedict Evans has a useful habit of standing slightly away from the noise. For years, his big strategy decks have acted as a kind of weather map for the technology industry: mobile, media, ecommerce, platforms, regulation, capital flows, and now AI. They are not predictions in the cheap sense. They are attempts to show the shape of the system: where the money is going, what assumptions people are making, which comparisons are lazy, and where the industry may be fooling itself.
His latest AI deck is long, dense and intentionally wide-ranging. It is not a neat argument so much as a set of lenses. The framing is simple enough: capital, deployment and change. How much money is being poured into AI? How is it actually being used? And what happens when machines can do more of the cognitive work that used to belong to humans?
That last question is the one most designers will jump to, but it is worth starting where Evans starts: with the money.
The numbers are hard to absorb. The big AI labs and hyperscalers are spending extraordinary sums on chips, data centres, energy and infrastructure. This is not the old software model where a small team writes code once and distributes it at near-zero marginal cost. Frontier AI looks much more like a capital-intensive industrial build-out. It needs land, power, cooling, supply chains, GPUs, financing and constant reinvestment.
That creates a strange tension. The companies building large language models want the economics of software, but the cost structure is drifting towards infrastructure. They are spending like telecoms companies or oil majors while hoping to capture value like Google, Microsoft or Apple.
Evans’ implicit question is whether that works.
I think he is right to be sceptical. For most everyday uses, the leading models are starting to feel less differentiated than the companies behind them would like. One might be better at code, another at writing, another at long context, another at multimodal work. But for the average user asking for a summary, a draft email, a spreadsheet formula or a bit of research, the difference is not always obvious enough to create loyalty.
That matters because if the models converge, they risk becoming the mobile carriers of the AI economy: essential, expensive to build, constantly upgraded, but not necessarily where the most attractive margin sits. Nobody doubted that mobile networks mattered. But the real strategic value in mobile went to the operating systems, app stores, devices, payment layers, developer ecosystems and companies that owned the customer relationship.
The same could happen with AI. The model may be necessary without being sufficient.
The model companies clearly understand this. OpenAI does not want to be merely an API provider. Anthropic does not want to be a smarter AWS bill. Google does not want Gemini to sit invisibly beneath someone else’s product. They all want to move up the stack, into the interface, the workflow, the browser, the agent and the place where user intent is captured.
This is where Anthropic is especially interesting. With Claude Code, it is not just selling access to a model. It is building the tool that developers use to do the work. Claude Code can sit inside a codebase, understand the project, make changes, run commands and behave more like a collaborator than a chatbot. That is a different kind of relationship from renting intelligence by the token.
Coding is the obvious beachhead because the output is easier to verify than many other knowledge tasks. The code runs or it does not. The tests pass or they do not. The pull request can be reviewed. The deployment can be rolled back. There is still plenty of judgement involved, but the feedback loops are unusually tight.
The next enterprise question is whether the same pattern extends into design.
That does not mean “make me a pretty homepage” design, although there will be endless amounts of that. It means the broader product work that sits around design: understanding a user need, mapping a workflow, generating interface options, producing prototypes, testing variants, summarising research, writing product specs, and handing the whole thing into code.
If coding becomes cheaper, the bottleneck moves upstream. What should we build? For whom? In what order? With what trade-offs? How should the product behave when the user is confused, impatient, tired, regulated, distracted or trying to do three other things at once?
That is the terrain design and product teams currently occupy. It is also exactly the terrain AI tools are moving into.
Evans is also right that chat is unlikely to be the final interface for most of this. Chat is a useful starting point because it is universal. You can ask anything. You do not need to learn a new interface. It is also a very good replacement for a lot of search behaviour. I already find myself going to ChatGPT or Claude before Google for many questions, especially when I want synthesis rather than a set of links.
In that sense, ChatGPT looks less like a productivity tool and more like a potential Google replacement. It could become the place people land on the internet.
The problem is that search-like behaviour is hard to monetise through subscriptions alone. People did not pay Google to search. They paid with attention, data and a tolerance for advertising. It is not difficult to imagine AI following the same path. Commercial queries get monetised first. Travel, software, shopping, local services, hiring, legal, insurance. The ads may arrive gently, then suddenly feel obvious.
This also explains why browsers have become interesting again. If the assistant becomes the gateway to the internet, the browser is not just a window onto websites. It is the layer that sees what you are reading, what you are trying to do, where you are stuck, what you might need next, and which service should be inserted into the flow. Search was the old command line for the web. The AI browser could become the new one.
But this is also where the strategy gets fragile. If open-source and local models become good enough for a large number of everyday tasks, the general-purpose model layer becomes harder to defend. They do not need to be better than the frontier labs. They only need to be good enough that users and companies stop caring for many common use cases.
That is why the real value may sit elsewhere: in context, proprietary data, distribution, trust, workflow and interface.
This is the part of Evans’ deck I think more founders should sit with. A thin wrapper around a model is not much of a company. It may be a useful feature. It may be a good demo. It may even generate revenue for a while. But unless it owns a workflow, a customer relationship, a data advantage or a behaviour change, it is exposed. The model provider can copy it. The system of record can absorb it. Another startup can rebuild it with the same APIs and a better onboarding flow.
The better opportunity is to understand the work deeply enough that AI becomes part of the work rather than a box next to it.
That means knowing the user’s context. It means having access to the right data. It means understanding the sequence of decisions, exceptions, permissions, anxieties and shortcuts that make up a real workflow. It means designing interfaces that do not simply ask users to prompt better, but help them get the job done.
A lot of the next wave will look familiar. We will get AI-native CRMs, AI-native analytics tools, AI-native customer support systems, AI-native design tools, AI-native research platforms, AI-native legal workflows. Some will be lazy: old software with a magic wand button. Some will genuinely change the unit of work.
That pattern should feel familiar. The mobile revolution did not invent taxis, photography, maps, dating, messaging or hotel rooms. It reorganised existing behaviours around new capabilities: location, cameras, touchscreens, notifications and constant connectivity. AI will do something similar. The interesting products will not simply add generation to an old workflow. They will change what the user thinks the job is.
So far, I am largely with Evans.
Where I start to diverge is around the labour question.
Evans has often taken the historically sensible view that new technology destroys some jobs and creates others. In the middle of the transition, the new jobs are hard to see. This has been true often enough that it deserves to be taken seriously. Mechanisation displaced physical labour. Industrial machines displaced dexterity. Software displaced clerical work. Each time, humans moved up the ladder into planning, judgement, creativity, empathy, coordination and strategy.
The issue is that AI is aimed much closer to the top of the ladder.
Previous waves automated muscle, movement, memory or calculation. AI is starting to automate research, synthesis, writing, planning, coding, interface generation, analysis and decision support. These are not minor tasks for knowledge workers. They are the work itself.
There will be new jobs. Of course there will. We will get AI operations roles, model evaluators, workflow designers, automation auditors, agent supervisors, synthetic data specialists and various new titles that sound faintly ridiculous until suddenly every large company has one. But the real question is not whether new jobs appear. It is whether they appear in anything like the same volume as the jobs being eroded.
I am not sure they will.
This is particularly uncomfortable for designers. I suspect we may have reached peak designer. That does not mean design stops mattering. In some ways, it may matter more. But “design matters more” is not the same as “companies need more designers.”
A lot of design work inside product teams is not the romantic version of the craft. It is assembling flows from a design system, producing variants, documenting states, preparing handoff files, summarising research, creating prototypes, making decks and moving work through a process that exists partly because the tools have historically been too dumb to carry more of the load.
AI weakens that bundle from several directions at once. Product managers will be able to generate credible flows. Engineers will be able to produce acceptable interfaces from existing design systems. Research tools will summarise interviews and customer calls. Experimentation platforms will propose variants and read the results. Design systems will become more generative. The need for a designer on every piece of interface work starts to look less obvious.
The first-order response is that designers move upstream. They own the system, the quality bar, the principles, the interaction patterns and the deeper product choices. I think that is true for the best designers. It is also a smaller job market.
The more uncomfortable version is that some of the system starts to design itself. A product observes behaviour, generates variants, runs tests, analyses outcomes and adapts the interface without waiting for a quarterly planning cycle. The designer does not draw every state. The PM does not imagine every test. The researcher does not manually identify every pattern. The system proposes, tests and adapts.
Humans stay involved, but the loop gets smaller. They set constraints, review exceptions, define brand boundaries, audit for harm and intervene when the system drifts. That might be more interesting work. It may also employ far fewer people.
The same logic applies to product managers. The job contains a lot of synthesis, coordination, prioritisation, documentation, stakeholder management and decision framing. AI can already help with much of that. The best PMs may become much more effective. The average PM may become less necessary.
Engineering may be protected for a while by backlog. Most companies have more software they want built than they have people to build it. AI coding tools will initially look like a pressure valve. Old tickets get cleared. Internal tools finally get made. Integrations that were never worth the effort suddenly become possible.
But once the backlog has been eaten, the labour question returns. If one engineer with AI can do the work of three, do companies build three times as much software forever? Some will. Many will not. At some point, the CFO notices.
This is where the “technology always creates more jobs” argument feels a little too comforting. It may still be true in the long run. But for many existing roles, the practical effect may be a shrinking of the team rather than a flowering of new adjacent careers.
AI may not replace whole professions in one dramatic motion. It is more likely to erode the task bundles that justify headcount. A designer is not replaced by “an AI designer.” A designer is squeezed by a design system, an AI prototyping tool, a PM who can generate flows, an engineer who can produce decent UI, a research synthesis tool, an experimentation platform and a leadership team willing to accept good enough for most surfaces.
That is a less cinematic story than mass replacement, but probably a more realistic one.
This is why Evans’ best question is also the most useful one for product and design leaders: what becomes cheap?
Cheap code changes the economics of software. Cheap content changes marketing. Cheap analysis changes management. Cheap interface generation changes product teams. Cheap research synthesis changes strategy. Cheap experimentation changes decision-making.
The follow-up question is more uncomfortable: which expensive organisational habits survive once those things are cheap?
Large product teams are partly a response to scarcity. Scarce engineering time. Scarce design production. Scarce research capacity. Scarce analytical attention. Scarce coordination bandwidth. AI does not remove all of those constraints, but it attacks enough of them that the old team shape starts to look exposed.
The optimistic version is that teams become smaller and better. Less time spent producing artefacts for each other. More time spent understanding customers, making difficult product choices and building things that previously sat below the economic threshold. The pessimistic version is that companies use AI to thin teams, flood the world with adequate software and mistake automated optimisation for product judgement.
Both will happen.
For designers, the lesson from Evans’ deck is not simply that AI is a platform shift. That much is obvious. The more useful lesson is that platform shifts rearrange where value sits. In mobile, value moved from carriers to operating systems, apps and services. In AI, it may move from models to workflows, context, data and interfaces. Inside companies, it may move from production to judgement.
That should make designers both more confident and more nervous.
More confident because design, in the broadest sense, is exactly what makes AI useful: understanding context, shaping workflows, making systems legible, deciding what good looks like, and preventing technically impressive products from becoming unusable mush.
More nervous because many of the artefacts designers have historically produced are about to become cheap.
If the model layer becomes infrastructure, the product layer matters more. If chat is a transitional interface, workflow design matters more. If generation becomes abundant, taste and judgement matter more. But none of that guarantees the current shape of the design profession survives intact.
The safest place to stand is not inside the artefact. It is closer to the decision.