What happens when designing and building become the same activity?

The org chart still separates UX designers, UI designers, product designers and front-end engineers. But the boundaries between the work those titles describe have been getting thinner for a while.

For a large class of products, one person can now participate much further across the chain: understand the problem, decide what to build, design it, implement it, and ship it. Not because they suddenly became exceptional at five different professions, but because the cost of moving between those activities has fallen.

I'll use Product Builder as shorthand for that kind of work. Not as a new job title, but as a description of someone who can carry intent from the problem through to production.

What actually changed#

The change is not simply that AI can write UI code.

The more consequential shift is that the handoffs between framing a problem, designing a solution and implementing it have become cheaper. When moving between those activities required separate specialists, specifications, meetings and calendars, the boundaries between roles served an obvious purpose. When much of that translation can happen immediately, those boundaries become less rigid.

I wrote about the single-person version of this workflow in one person, the whole loop. This is the same observation applied to the roles themselves.

A role often exists because it absorbs a cost. When implementation was expensive, dedicated implementation capacity makes sense. When translating a design into a specification is expensive, a person coordinating that translation can make sense. As those costs fall, some of the boundaries built around them become less necessary.

This does not mean one person is now equally good at everything. It means more of the work can happen as one continuous chain of judgement.

A design decision can flow directly into a component, a data model, a test, a pull request and a deployment without repeatedly being translated between people. The value is not that one person does more tasks. It is that less intent is lost between them.

Much of interaction design has converged on known patterns#

We have been building software interfaces for decades. Over that time, the industry has converged on recognisable patterns for a large share of common product problems.

A table with filtering and bulk actions. A multi-step form with validation and save-and-resume. An empty state that explains what to do next. Roles and permissions. A command palette. Settings grouped into sections. Notifications with read states and preferences. Onboarding with a checklist.

For many of these problems, the challenge is no longer inventing an interaction from scratch. It is selecting an appropriate pattern and adapting it to the product.

Models are particularly useful at retrieving familiar patterns and adapting them to a new data model, product and visual system. For a large amount of everyday product work, that is the task: recognise the problem, start from a known interaction and adapt it.

The amount of genuinely novel interaction design in most products is relatively small. A product may contain a handful of interactions that need to be invented, surrounded by many more that benefit from established conventions.

What research still protects#

UX research is not one activity. It is useful to separate at least two kinds of work:

• Solution research: Which layout works better? Does this label make sense? Is the flow discoverable? Where do people drop off? Much of this can become cheaper as established patterns provide stronger starting points and experimentation becomes easier.
• Discovery research: Understanding a person's situation before deciding on a solution. Watching them use a spreadsheet instead of the official system. Hearing about a workaround they barely think to mention. Noticing the part of the job they don't describe because, to them, it is simply how the work gets done.

A model can help produce a competent form from a familiar pattern. It cannot tell you that the user does not need a form at all because, at 4pm on a Friday, they solve the actual problem by calling the warehouse.

Discovery remains different because the raw material is a specific person in a specific context. The useful signal is often in what people do rather than what they say.

That is where the time saved elsewhere should go: understanding the problem before optimising the solution.

That may change too

There is a complication worth considering.

As agents increasingly become the interface between people and software, they may accumulate signals that previously only emerged during research sessions. An agent can ask clarifying questions, notice repeated requests, reformulate vague goals and infer patterns across interactions.

That does not eliminate the need to talk to people. But it may change the material researchers work with.

Instead of every insight beginning with an interview, some requirements may increasingly arrive with a history of clarifications and failed attempts already attached. The researcher may spend less time extracting basic intent and more time validating whether the patterns inferred by the system reflect reality.

That is a meaningful shift, even if the human conversation remains important.

The back office is where this may change first#

Internal tools make the shift particularly easy to picture.

Look at a typical admin console. It is usually a collection of tables, forms, filters and actions. To complete a routine operation, someone navigates a sequence of screens, selects records, applies filters and finds the action that corresponds to what they are trying to do.

The interface is often shaped more by the underlying database and available operations than by the way a person naturally describes their goal. Every new operation adds another control, screen or workflow that someone has to learn.

The person describes what they want, and the system produces a concrete plan against real data. They can review the plan, adjust it if necessary and approve it.

The difference is important. The task is no longer expressed primarily as a path through a predefined interface. It starts with intent and produces a reviewable operation against real data.

This does not mean traditional interfaces disappear. Dashboards, analytics and exploratory tools still make sense because the person is looking for patterns in information rather than executing a known operation.

But routine data-entry and operational workflows are a particularly strong candidate for a different model. There is little reason to permanently design a dedicated click path for every possible operation if the system can construct and explain the operation when it is needed.

The interface moves away from helping someone find the right button and towards helping them understand the consequences of what the system is about to do. That is still interface design. It is just solving a different problem.

What becomes the bottleneck instead#

For certain kinds of products, implementation capacity is becoming less of the constraint than it used to be.

The harder problem is giving the system enough context to make correct decisions.

That context usually has a few components:

1. A documented domain model. The entities, their states, legal transitions and invariants, expressed clearly enough to be used.
2. Workflow definitions. The operations people actually perform, described in terms of preconditions and outcomes rather than screens.
3. Worked examples. Concrete inputs and expected outputs for ambiguous or difficult cases.
4. Guardrails and evaluations. Things that must never happen, along with cases that can be checked repeatedly.

With those things in place, implementation becomes substantially more repeatable. Without them, the system can produce software that looks plausible while being subtly wrong.

The leverage from these tools is real, but it does not remove the need for judgement. Better tools make good context more valuable and bad assumptions easier to scale.

Hiring is still testing for the old job#

The work has changed faster than many interview processes.

Companies still commonly test candidates with algorithm exercises, pixel-perfect implementation tasks, framework trivia and portfolio reviews focused primarily on finished artefacts.

Those tests can still reveal useful skills. The question is whether they reflect the work increasingly required in practice.

A growing part of the job is being able to take an ambiguous problem, establish the right context, choose an appropriate pattern, work effectively with AI tools and review the result with enough technical judgement to know when it is wrong.

A more representative interview might look like this: give someone a partially described internal problem, a design system and a data model. Let them use the tools they would actually use at work. Ask them to move from ambiguity towards something that could plausibly ship.

That exercise reveals problem framing, design judgement, technical understanding and tool use at the same time.

What doesn't get cheaper#

This way of working is strongest in early products, smaller surface areas, internal tools and situations with a clear owner and relatively low regulatory complexity.

It is much less convincing for large systems with many stakeholders, deep dependencies and significant consequences for getting things wrong.

The point is not that every product team should collapse into one person. It is that the old boundaries are no longer equally useful everywhere.