Design by numbers: is AI ruining UX or just pouring gasoline on the fire?

Everyone seems to be asking whether AI will replace UX designers. I think that’s the wrong question.

A paint-by-numbers illustration of a smartphone showing a generic app screen — Following the numbers gets you a picture but doesn’t make you an artist | Russell Pinkston

In March 2025, the Computer History Museum and IEEE Spectrum staged a debate on a single question: when a large language model answers you, does it even understand what it’s saying? Does it comprehend what the words mean, or is it only predicting which word comes next?

Emily Bender, a linguist at the University of Washington, argued it’s only predicting. In fact, she has a name for these systems: stochastic parrots, machines that string words together by probability, the way a parrot repeats sounds, with no idea what any of it really means. Sébastien Bubeck, a researcher at OpenAI, took the opposite stance. Understanding, he argued, is in the eye of the beholder, and you judge it by what a system does.

“Let’s say I want to build an app, and I ask one of those models to build the app for me… I just specify in natural language what I want, I come back the next day and, boom, the app is there. Did the model understand on the way of creating this? In a way, I don’t really care. It did something for me.”

Let’s unpack this statement, because I think it’s a fairly common argument and also one that is dangerously misleading. Not only does this misrepresent how designers actually work, but the real danger is in the shrug. It lacks accountability. Once you stop caring whether AI understands what it’s doing, then you shift your measure of success away from outcomes and toward output.

UX design exists to make things work for the people who use them. Can the user complete a task easily and intuitively? That’s the outcome. The things designers produce along the way (journey maps, wireframes, prototypes, etc.) are outputs. They’re evidence of a process; they aren’t proof that anyone’s life got easier.

AI is a bit like a microwave — it will cook your food faster but not as well. Successful products are not ones that get made as quickly as possible but ones that resonate with users. A TV dinner is not fine dining. When we remove empathy and understanding from the deliverable, we risk delivering bad experiences that may not actually solve user pain points. Ignoring that is a treacherous path.

For the past year, I’ve spent eight or more hours a day designing with a range of AI tools. I’ve built everything from Chrome extensions to websites to enterprise-level multi-agent orchestration workflows. What I’ve learned is that, even for an experienced UX designer, this is no small feat. It requires tireless attention to detail over weeks or months to get a usable product from AI. It does not happen overnight, and it takes a hell of a lot of natural language cursing to get there.

What Bubeck is describing is a proof of concept, and a proof of concept is very different from a well-designed product. It shows that something can exist; it doesn’t show that it works for the people who will use it. By Bubeck’s own assertion that we should judge a system by what it does, the overnight app doesn’t pass muster.

Once that first, overnight build is in, what follows is actual UX design: noticing that the flow is wrong, that an error state is missing, that users get hung up in closed-loop modals. When we rush the first iteration, it can take a great deal of time and effort on the back end to repair these issues, especially if we’re trying to explain them to a tool that doesn’t understand what it’s doing.

But, if we’re being honest, this is not a problem that started with AI. Bubeck’s assertion comes from a misunderstanding of design that’s decades old: that the job is about outputs, rather than outcomes. So is AI really what we should be worried about here, or is it just pouring gasoline on a fire that was already burning?

But first: Is AI taking UX jobs?

Every few weeks, someone asks me whether I’m worried about losing my job to AI. All the headlines, the LinkedIn posts, and the steady stream of clickbait declaring that “designers are finished” make this an obvious question to ask, and I think I’m in a decent position to address it. As a design lead, I use AI tools every day — everything from Codex to Claude, IDEs, Mistral, Copilots, n8n, and GitHub Actions. I even developed my own VS Code extension to orchestrate cross-model prompt chaining. When I get spare time, I lecture about the history and impact of human-computer interaction at the university level.

I won’t pretend nothing has changed. Layoffs are real, and I’ve seen them firsthand, but the numbers are anecdotal. The only hard counts are tech-wide, not design-specific.

The best public data I could find for open design jobs comes from two sources: Indeed’s postings index for design and UX, and the job tracker TrueUp, which covers tech companies and startups. Indeed shows postings more than doubling from early 2021 to a peak in early 2022, then dropping roughly 70% by mid-2023. Most of this happened before anyone had ever heard of ChatGPT. TrueUp shows the same drop and what came after. Since autumn of 2023, it has kept mostly stable around 2,200, with a brief spike in spring 2026 before settling back down again.

Line chart of UX design job postings over time, rising to a 2022 peak then declining, with markers for the ChatGPT launch and the start of the AI-in-UX debate. — Design job openings surged in 2021–22, corrected, and then have remained stable ever since. | Data: Indeed, TrueUp

That’s what a correction after a hiring surge looks like, and it doesn’t necessarily correlate with the spread of AI. If AI were driving these numbers, I’d expect the line to keep falling as the tools spread. Yet, Figma’s 2026 State of the Designer report found that 72% of the designers it surveyed are using generative AI. That doesn’t disprove AI is playing a role in the job market; it just means the data doesn’t show AI as a negative catalyst.

But still we feel the squeeze, and part of it may simply be supply and demand: too many new designers chasing the same amount of openings. Nobody publishes how many people are newly entering the UX field, or how many unemployed designers there are at each level, but a quick LinkedIn search for “UX designer” showed that the first 25 postings had already passed LinkedIn’s display cap of “Over 100” applicants. That’s just one search (and these applicants aren’t necessarily all out of work) but it does give you an idea of what looking for a job right now is like.

Put together, these numbers don’t really describe a sea change of job loss. AI doesn’t seem to be changing whether the jobs exist so much as what the jobs are. I’m less afraid of losing my job to AI than I am of the job itself becoming unrecognizable. Design has been misunderstood for decades, and if we’re not careful, AI agents will let that misunderstanding become the job description, leaving the user experience to chance.

Design (without) thinking

I believe true UX designers are a rare breed. The work is a combination of critical thinking, empathy, and taste. These are things you can’t really teach, and they’re also things that AI fundamentally lacks.

I say that as someone who teaches and has seen the limits of what teaching can accomplish. A course can show you how to run a usability test or build a journey map, but it can’t make you care whether the person on the other side struggled. It can’t give you the instinct that something is off before you can say exactly what. What a course can teach is process, and that’s where AI and human designers both get tripped up: it’s hard to empathize when you’re following a prescribed process. Thoughtlessly following processes can imitate outputs, but not outcomes.

The trouble is that process is visible and ability is not, so the two are often conflated. You can see a workshop, journey maps, or wireframes, but you can’t see the judgment that decided what question to ask during a user interview, or when to challenge the obvious solution. When design is reduced to a checklist of methods and deliverables, it’s easier to report what has been delivered, but a team can run a flawless process and still deliver an unusable product.

A comic contrasting letting AI do the legwork with keeping the thinking for yourself. — A team can finish every step and still ship something users can’t use. | Russell Pinkston

This is what I mean by “design by numbers”: the fallacy that if you follow the steps and produce the artifacts, good design is guaranteed at the end.

But where did this misunderstanding come from? In the 1960s, the design methods movement set out to “scientise” design into a linear process that anyone could follow and repeat. Some of its own pioneers later turned against this idea, describing the attempt to make design scientific as a misguided effort to turn dynamic problem solving into a linear, repeatable process. They argued that the problems designers face don’t sit still long enough to be universal. Horst Rittel called these “wicked” problems: ill-formulated, with confusing information, many decision makers with conflicting values, and consequences that ripple through the whole system.

Design is not a linear, repeatable process, and it never was. There is no single path to a solution waiting to be found.

I liken it to IKEA assembly instructions: you can follow the steps and build a perfectly fine shelf, but what if now you need to build a table or paint a wall? Would you use the same instructions? Or even the same tools?

Design thinking, the most widely used methodology in the field, is a genuinely good way to get a team collaborating. In practice, though, it can devolve into a clutter of sticky notes that no one will ever look at again, with designers speculating about what stakeholders actually need, think, and feel. Graphic designer Natasha Jen made this point in her talk Design Thinking Is Bullsh*t. She regretted that design practice had been reduced to a defined sequence of steps, and argued that “real designers surround themselves with evidence.” When we limit ourselves to preconceived processes, we may be the ones preventing ourselves from solving what looks impossible. Writer and designer John Thackara offers a better frame, which he calls sense-and-respond design, where you describe the desired outcomes but not the detailed means of reaching them.

That can be a bitter pill to swallow for stakeholders who need to report quarterly deliverables, but here’s the thing: users don’t care about deliverables — they care whether a product works for them. And that outcome depends on whether designers have the time and ability to understand what they are doing.

Slop is as slop does

If you believe process and output is the job of design, then AI might look like a handy replacement. It produces outputs quickly and confidently: personas, flows, copy — even working prototypes. And designers aren’t resisting that. In the Figma survey, 89% of designers using generative AI said it makes them faster, and I’d say the same about my own work. AI is a genuinely useful tool, but it’s a tool like any other. Generating these artifacts is only part of a designer’s job, and it’s the part that doesn’t require critical thinking, empathy, or taste.

When I talk to my students about how to work with AI, I like to separate tasks into two different categories: thinking and doing.

AI is good at doing. In my experience, that typically includes three things in UX design:

Synthesizing user research. It can take a pile of interview notes or survey responses and group, summarize and surface patterns far faster than I can by hand. That’s the legwork. What the patterns mean for the product is still mine to decide.
Meta-work. Slide decks, readouts, summaries and the other work about the work. It’s necessary and it takes time, but none of it is the design itself.
Translating mockups into prototypes. Once I’ve decided what the experience should be, AI can turn the mockups into something clickable much faster than I could build it myself. But the design work I do at the whiteboard is still the source of truth.

A comic showing an app built overnight that falls apart on use, with the point that a proof of concept isn’t a product. — Let AI do things for you, but don’t let it think for you. | Russell Pinkston

Designers can let AI do things for them. But it should never think for them. There’s a name for this: automation bias, the tendency to trust what an automated system hands us over our own judgment. A hammer is an incredibly useful tool, but would you let a hammer think for you? Deciding what the problem is, what the research means, what to build, and what’s good enough requires critical thinking skills, and that’s where AI stops and the designer’s judgment takes over. When we outsource our thinking to AI, what comes back might look like a solid answer but is really just stochastic parroting from something that doesn’t understand the problem.

AI is a translation tool. It can turn natural language into code very quickly, but it doesn’t understand how to ask the right questions. It can’t properly architect a product, and it frequently misses visual bugs that are glaringly obvious to a real designer.

When anyone can generate a prototype in an afternoon, a prototype stops being evidence of anything important. In a world where AI slop is cheap and fast, the designer’s ability to discern good design from bad and to ask whether we’re solving the right problem becomes more important, not less.

When the enshittification hits the fan

The more I work with AI, the more I see a need to change the way we think about design.

The pressure starts with expectations. If the story is that you can “come back the next day and, boom, the app is there,” then someone down the hall will ask why designing the first MVP has taken two weeks. A proof of concept gets mistaken for the product, timelines compress, and the output gets treated as the outcome.

Figma’s survey lists unrealistic timelines among the things that stand in the way of designers doing their best work. AI puts that into a pressure cooker because the artifacts can be built faster than we can understand them. With an expedited delivery timeline, the first things to go are the parts that are hard to report: talking to the people who will use the product, testing, critiquing, discovering you are wrong and then iterating as you learn. These things look like delays when AI can just cut straight to the end result.

A proof of concept isn’t a product. | Russell Pinkston

But there’s a problem with jumping straight to the end: it’s reckless. Letting AI build products for you creates a kind of house of mirrors that only the AI knows how to navigate. Because of context limits, it builds piecemeal, one function at a time, supplanting holistic architecture for a labyrinth of myopic patches. The result is a product that might work but that nobody really understands. I can’t tell you the number of times I’ve had to prompt AI to refactor an entire codebase because it lacked any architectural spine. Say goodbye to your tokens.

Building products this way also shifts the means of production out of your business and into the hands of a few AI companies (OpenAI and Anthropic, to name a few). Your business ends up relying on agent subscriptions and usage limits to stay in operation, while your own employees become less skilled. That should be a very dubious prospect for any business owner.

We’re already starting to see what this shift looks like day to day. A product manager I worked with recently surprised me one day with designs he’d made using AI. He was visibly excited about what he’d created, but to me they were a jumbled mess: no hierarchy, no clear calls to action, useless icons on every surface… To someone who isn’t a designer, they probably looked fine. That’s the trick with these tools. They sound like they know what they’re talking about, but only to people who don’t know what they’re talking about.

And this is not just a design problem. It’s becoming more and more pervasive across disciplines. Designers using AI can see the flaws in its designs just like developers can see the flaws in its code. So the next time you vibe-code something, understand that what you’re creating is not a finished product that any god-fearing developer would bless.

The key here is to maintain accountability by learning to spot the warning signs. Is a PM asking AI instead of doing market research? Red flag. Is a designer using AI as a beta tester instead of talking to actual users? Red flag. Did a stakeholder say everything looks good on a call, then immediately dump five paragraphs of feedback into Slack? Maybe start to question how much thought actually went into that.

We need to get into the habit of not limiting our focus to artifacts and output and instead ask deeper questions about how we are creating better experiences. If you can answer that, you’ll be fine with or without AI. And if you can’t — or don’t really care — you’re going to have bigger problems than any tool can fix.

AI is a powerful tool, and in the hands of someone who understands its limitations, it can make the work easier. The open question is who gets to decide how it’s used, and whether they understand the difference between producing an output and enabling an outcome.

What businesses need to understand is that design is qualitative, not quantitative. It can’t be reduced to steps and artifacts, and it can’t be measured by how much gets produced. Design is a conversation between the business and its users that says “we’ve thought about this more than you’ll ever have to.” The companies that stand apart will be the ones that invest in that level of thinking. The companies that outsource their thinking to AI will get the same slop as everyone else.