What happens to UX when execution is no longer scarce

AI is collapsing the distance between design, code, and learning, changing what UX professionals are valued for.

AI is shrinking the distance between designing, building, and learning. That may change what designers are actually valued for.

A few years ago, I would have described a designer committing changes to GitHub as an exception.

Today, I know a UX professional working for an international company whose workflow sometimes goes exactly that far. He identifies an experience problem, changes parts of the interface or content, works closer to the implementation, creates a commit, and follows that change through a controlled path toward production.

He has not stopped being a designer and become an engineer. What changed is the distance between noticing a problem and being able to act on the product itself.

I felt something similar recently during workshops led by Figma. As new AI-enabled workflows were demonstrated, the boundaries between design, product, and development seemed less rigid than the ones many of us were trained to work within.

Neither observation proves that the entire profession is changing. They are anecdotal signals. But when those signals are placed next to research from Figma, experiments from companies such as Vercel and Anthropic, and changes in how AI-native products are being designed, a broader pattern starts to appear.

For years, UX has been strongly associated with its artifacts: wireframes, flows, research reports, journey maps, prototypes, interfaces, and specifications. AI is making many of those artifacts dramatically cheaper to produce.

That does not necessarily make UX less important.

It may mean that producing artifacts is becoming a weaker explanation of where the value of UX actually comes from.

My hypothesis is that UX is gradually becoming something broader: a product-operating discipline, where designers are valued not only for representing what a product should become, but increasingly for how far they can take a problem, how well they can judge possible solutions, and how responsibly they can influence what actually reaches users.

Job titles were already becoming incomplete

A recent post by Boris Cherny, who leads Claude Code at Anthropic, gave me a useful lens for thinking about this shift.

Instead of describing people only through traditional functions such as engineering, product, design, or data, Cherny proposed five archetypes based on how people operate on a product: the Prototyper, who explores new ideas; the Builder, who turns ideas into working products; the Sweeper, who simplifies and removes complexity; the Grower, who iterates toward stronger product-market fit; and the Maintainer, who keeps mature systems reliable and efficient.

The labels themselves are not the most important part.

What matters is that they do not map cleanly to professions.

A designer can behave like a Prototyper or Sweeper. An engineer can operate as a Builder or Maintainer. A product manager can act like a Prototyper or Grower. The same person may move between several of these modes depending on the problem and the stage of the product.

And there is evidence that traditional role boundaries were already becoming more porous before the latest wave of AI tools.

In Figma’s 2025 research on shifting roles and responsibilities, 64% of respondents identified with two or more roles, while more than a third said their responsibilities spanned at least three. Among product managers, 70% were already creating low-fidelity mockups or wireframes and 59% were participating in interactive prototyping.

Figma’s 2026 AI Report shows the movement accelerating. Based on 8,403 survey responses and 639 qualitative interviews across ten markets, the report found that the share of designers participating in development doubled from 21% to 41% in one year. Developers participating in design activities increased from 44% to 60%.

Forty-one percent of respondents also said AI had significantly changed how their teams work together, compared with only 7% two years earlier.

The interesting part is not simply that everyone is becoming faster.

The work itself is beginning to move across professional boundaries.

That changes the question.

Instead of asking only how AI can help designers perform traditional design tasks faster, we should also ask what happens when designers, product managers, and engineers can increasingly operate on the same materials.

From artifact production to product operation

A simplified product workflow has traditionally been represented as something like:

Problem → Research → Requirements → UX → UI → Prototype → Handoff → Development → Production

Good teams have never worked in such a perfectly linear way, but this sequence still influenced our tools, job descriptions, processes, portfolios, and organizational structures.

Each discipline tended to manipulate a different representation of the product. Research worked with evidence. Product worked with priorities and requirements. Design worked with representations of the experience. Engineering worked with the actual software.

Handoff existed partly because those representations were separated.

AI is reducing the cost of moving between them.

A product manager can explore an interface without waiting for polished design. A designer can turn a hypothesis into a functional prototype much faster. With coding agents, that same designer can potentially inspect an implementation, change content, manipulate components, test real states, or take an idea much closer to working software.

This does not mean that every designer should become a software engineer.

That interpretation is too narrow.

The deeper change is that code is becoming a more accessible design material.

UX has spent decades increasing the visual fidelity of prototypes. Paper sketches became wireframes. Wireframes became interactive interfaces. Those interfaces gained variables, components, motion, conditional flows, and increasingly sophisticated simulations.

AI is making another dimension more accessible: behavioral fidelity, or how closely a prototype can reproduce the way a real system behaves.

A prototype can increasingly include realistic data, conditional states, generated content, permissions, errors, business rules, and consequences that propagate through different parts of an experience.

This matters because some UX problems only become visible when the system actually behaves.

What happens when there is no data? What happens when permission is denied? What happens when an AI response is wrong? What happens when a choice on one screen affects another part of the product? What happens outside the happy path?

The closer prototypes get to real product behavior, the more designers can learn from something that behaves like the product rather than simply representing it.

That also changes the role of handoff.

For years, design and engineering have invested heavily in making handoff better through specifications, inspect modes, tokens, documentation, component libraries, and clearer acceptance criteria. Those things remain valuable.

But there is another way to reduce the problems created by handoff: reduce how often a handoff is necessary.

Some teams may move from a predominantly sequential cycle of research, design, handoff, build, and measurement toward something more continuous: hypothesis, build, test, observe, change, ship, and learn.

Design becomes less of a stage that happens before implementation and more of a capability applied throughout the life of the product.

When execution gets cheaper, judgment becomes more valuable

This shift changes the economics of design work.

According to Figma’s 2026 AI Report, 90% of respondents said design was at least as important as it had been before AI, with almost six in ten saying it had become more important.

At first, that can sound contradictory.

If AI can generate interfaces, copy, variations, and prototypes, shouldn’t design become less valuable?

Only if design is primarily understood as production.

Imagine that a team can generate thirty plausible interface directions in minutes rather than days. Producing option number thirty-one is no longer particularly scarce.

What becomes scarce is knowing which direction deserves to exist.

Which problem is actually worth solving? What should be removed? Which trade-off is acceptable? What behavior will users understand? What should happen outside the happy path? What should a system refuse to do? What creates trust? Which technically impressive feature adds no meaningful value?

AI can make execution abundant without making good decisions abundant.

This is why Cherny’s Sweeper archetype is particularly interesting for UX.

For decades, software organizations have often been rewarded for addition: more features, more settings, more dashboards, more automation, more screens. Generative AI makes addition even cheaper.

The consequence is almost paradoxical.

The easier it becomes to build something, the more valuable it may become to recognize what should not be built.

A strong designer does not simply make a complicated workflow easier to use. They ask whether the workflow should exist. They look for steps that can disappear. They question whether a decision really needs to be exposed to the user. They recognize when another feature is solving an internal organizational problem rather than a user problem.

In an environment where generating more becomes easy, subtraction becomes a form of expertise.

UX is moving from interfaces to behavior

There is another transformation happening at the same time.

Traditional interface design often assumes a relatively predictable relationship between an action and its result. A user does something and the system responds in a predefined way.

AI products complicate that relationship.

The same intention can produce different outcomes depending on context, model behavior, available tools, permissions, previous interactions, and system state.

That changes what designers are designing.

We are not only designing screens. We increasingly need to design behavior, autonomy, limits, recovery, and trust.

Should an agent act automatically or request permission? How should uncertainty be communicated? Which actions need confirmation? Can the user undo what happened? When should the system stop? When should a human take over? How should an experience recover when the model produces something unexpected?

These are UX questions, but drawing another screen is not enough to answer them.

It also brings practices traditionally associated with AI engineering closer to UX. One example is evals, systematic evaluations used to determine whether a model or agent behaves as expected.

The important question for designers is that someone still needs to define what “expected” means from the perspective of the experience.

What constitutes a good response? Which mistakes are acceptable? What creates confusion? When should the system ask for clarification? Which behaviors damage trust? What should remain consistent across thousands of possible outputs?

This is already visible in how some AI-native organizations are approaching product development. Vercel, for example, has documented its work on teaching agents product design, describing a system where product judgment, interface standards, copy guidance, resilience rules, and previous decisions can be accessed by coding agents.

The larger idea is more important than the specific implementation.

A significant amount of senior design knowledge has always been tacit. Experienced designers know when a component should not be used, why a certain term was chosen, why a flow contains a particular constraint, or why an apparently simple interaction required weeks of research and discussion.

Humans can carry that knowledge through conversations, critiques, documentation, and memory.

Agents cannot rely on that informal context in the same way.

If AI becomes an active participant in building products, more design reasoning may need to become explicit, structured, and understandable by machines.

Design Systems could therefore become more important, not less. The question expands from “How do we help designers and developers build consistently?” to “How do we make the principles and judgment behind the product understandable to both people and agents?”

Not every team will work this way

There is an important counterpoint.

Most product organizations do not operate like Anthropic, Vercel, or AI-native startups.

A bank, healthcare company, public institution, global enterprise, or organization with significant technical legacy may have very good reasons to preserve clearer boundaries between disciplines. Regulation, security, governance, accessibility requirements, accountability, and organizational maturity all influence how quickly these models can change.

So this is not a prediction that every Product Designer will soon commit code to production.

It is a claim that the range of ways a designer can operate is expanding.

The market appears to reflect this tension.

In Figma’s 2026 research on design hiring, 47% of hiring managers said demand for designers had increased, 35% said it had remained stable, and 18% reported a decline.

At the same time, 73% reported increasing demand for proficiency with AI tools, while 79% saw increasing demand for people capable of designing AI products.

Design is not simply disappearing. Expectations are shifting.

The same research also points to a more uncomfortable issue: demand appears to be growing faster for senior designers than for junior talent.

That matters because many tasks AI performs well are also tasks that historically helped junior designers learn. Exploring variations, preparing first drafts, adjusting components, organizing documentation, synthesizing research, and writing specifications may look like production work, but they also expose people to feedback, edge cases, mistakes, and hundreds of small decisions.

That is part of how judgment develops.

If organizations automate much of entry-level execution while simultaneously expecting more autonomy, they create a difficult question:

How does someone develop senior judgment without access to the experiences that historically helped build it?

AI may make junior designers productive faster. Productivity and professional development are not the same thing.

A larger definition of UX

The answer to this transformation is probably not that every designer should become an engineer.

Research, accessibility, content, interaction design, visual craft, service design, systems thinking, and domain expertise remain deep disciplines.

What changes is the number of materials designers can potentially manipulate and the distance they can travel with a problem.

For some designers, HTML, CSS, Git, coding agents, and functional prototypes may become natural parts of the toolkit. For others, the expansion may happen through analytics, experimentation, AI evaluation, product strategy, or deeper research.

Specialization does not have to disappear for professional boundaries to become more flexible.

The World Economic Forum’s Future of Jobs Report 2025 estimates that 39% of workers’ existing skill sets will be transformed or become outdated by 2030. AI and big data, technological literacy, and other technical skills are among the fastest-growing areas, but so are analytical thinking, creative thinking, resilience, curiosity, and continuous learning.

That combination is important.

The future does not appear to be asking us to choose between technological capability and human judgment.

It increasingly requires both.

For UX, this may also change what seniority means. A senior designer may become less differentiated by how many artifacts they can produce and more by their ability to identify the right problem, navigate ambiguity, understand systems and consequences, connect user needs with business realities, challenge unnecessary complexity, evaluate imperfect evidence, raise the quality bar, and take responsibility for what happens after something reaches production.

Those capabilities were always valuable.

AI is simply making the difference between production and judgment easier to see.

I do not think UX is disappearing, and I do not think traditional job titles will suddenly vanish. Titles solve real organizational problems around hiring, compensation, management, accountability, and career progression.

But they may explain less and less about how someone actually contributes.

The deeper transformation is happening underneath them.

UX may be becoming less defined by the artifacts we produce and more by the changes we can responsibly create in a product. The shift is from screen to decision, from wireframe to hypothesis, from prototype to learning, from handoff to collaboration, from interface to behavior, and from execution to judgment.

Increasingly, it is also a shift from designing a representation of the product to operating on the product itself.

Boris Cherny’s five archetypes may or may not become a lasting vocabulary for this transformation. That is not the most important part.

The more useful question behind them is this: if designers, engineers, product managers, researchers, and AI agents can increasingly operate on the same materials, what will actually differentiate us?

I suspect the answer lies in the things that have always been hardest to encode in a tool: how we see problems, the questions we ask, the context we understand, the standards we maintain, the decisions we make, the things we choose not to build, and the responsibility we take for what eventually reaches people.

That does not sound like a smaller future for UX.

It sounds like a much larger one.

What happens to UX when execution is no longer scarce was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.