The Designer's Decision in the Age of AI

For years, we understood design and development as two parallel paths.

Designers researched problems, defined flows, organized information, and created interfaces. Developers transformed those decisions into functional systems, connected data, managed states, and handled the technical complexity required to bring the product into production.

Between those two worlds stood the handoff.

It was not simply a stage in the process. It was a professional boundary. On one side, teams defined how the product should work and look. On the other, they decided how to make it real.

We built teams, tools, methodologies, and entire careers around that separation. Figma ended where the repository began. The prototype demonstrated an intention; the code assumed responsibility for turning that intention into behavior.

For a long time, that division made sense. Technical complexity required specialization, and specialization allowed each discipline to go deeper into its own domain.

But that paradigm is changing.

The question is no longer simply whether designers should learn how to code. The question is far more profound: what does it mean to be a designer when the barrier between imagining a product and building it begins to disappear?

Artificial intelligence has brought together two paths that we treated as independent for decades. For the first time, a designer can move from an idea to a functional experience within the same working session. They can describe an interaction, generate an implementation, test it, modify it, and observe its behavior without waiting for another team to translate every decision.

This does not mean development has stopped being complex. It means access to that complexity has changed.

The separation was never natural: it was a consequence of complexity

Design and development were never completely independent activities. They have always been two ways of working on the same product.

The designer defines relationships, hierarchies, behaviors, and expectations. The developer turns those relationships into structures capable of responding to data, users, and real conditions. Both work on the same system, even when they observe it from different levels.

The separation emerged because technical tools required knowledge that was difficult to acquire, and because building software was too expensive for one person to move through the entire process.

That is why specializations appeared. Not as a limitation of design, but as a logical response to the complexity of building digital products.

Artificial intelligence, however, is introducing a new layer of abstraction. In the same way graphical interfaces made previously complex computing tasks accessible, AI agents are making software construction more approachable for people who did not follow a traditional engineering path.

Today, a designer can work inside a codebase using natural language, existing components, and rules provided by a Design System. They can request a variation, correct an interaction, connect information, or build an entire flow without manually writing every line.

But accessibility does not eliminate responsibility.

AI does not eliminate technical complexity. It changes who can interact with it.

A generated interface can look correct and still be fragile. It can work in the ideal scenario and fail when the data is incomplete. It can use the right components while ignoring accessibility, security, performance, permissions, or maintainability.

The barrier to entry has fallen. The quality bar has not.

That distinction is essential because it prevents us from confusing the ability to produce software with the ability to build good products.

The design file is no longer the final destination

For years, the most visible result of design work was a file.

Inside that file, we could control the content, select the perfect state, and represent the most orderly version of the experience. The data was predictable, connections always worked, and users followed the path we had prepared.

A design file allows us to represent how a product should behave. A functional product forces us to discover how it actually behaves.

When a designer begins to build, questions that a static composition can keep hidden start to appear:

• What happens when the user has no data?
• What happens when a request takes too long?
• How does the system respond to a partial failure?
• What can each role see?
• Which actions require confirmation?
• How does the user recover an interrupted task?
• What happens when an operation cannot be undone?
• How does the flow work with a keyboard or assistive technology?
• What changes between a new user, an active user, and someone who has lost access?
• How does the product behave across different tenants, plans, or configurations?

These are not exclusively technical questions. They are product questions.

Yet many of them remained outside the design process because the tool did not force us to resolve them. We could represent a happy path and consider the flow finished, even when most of the real experience had not been defined.

Building exposes those omissions.

The product stops being a sequence of screens and begins to reveal its true nature: a network of states, rules, dependencies, permissions, and consequences.

A screen can look finished while the product remains conceptually incomplete.

The ability to build does not automatically make someone a better designer. But it brings them face-to-face with the reality of the product much earlier, and that confrontation improves the quality of their decisions.

Behavior is the new unit of design

An interface has always been more than appearance. Yet our tools encouraged the industry to treat the screen as the primary unit of design.

We designed pages, frames, components, and variants. Then we connected screens to simulate behavior.

Artificial intelligence is changing that unit.

When designers can work directly on a functional experience, they no longer design only how an action looks. They design how the system responds when that action occurs.

They can observe the real transition, test latency, evaluate whether feedback arrives at the right moment, and discover whether the information architecture continues to work when the content changes. They can test the interaction with variable data, not only with the most convenient example.

This transforms the process.

The prototype stops being an anticipated representation of the product and becomes an environment where decisions can be validated through real behavior.

The difference is profound.

In a visual design tool, a form may appear clear. In practice, it may feel slow, lose information, respond ambiguously, or produce errors that were never designed. A table may look balanced with five records and become unusable with five thousand. An onboarding flow may appear short until it has to handle permissions, pending invitations, and incomplete configurations.

Building forces us to design the invisible relationships that hold the experience together.

When behavior can be designed directly, building stops being an activity that follows design. It becomes a way of designing.

The false refuge of specialization

Specialization will remain necessary.

Complex products need researchers, interaction designers, content specialists, accessibility experts, visual designers, Design System practitioners, and engineers capable of building robust architectures.

The problem is not specialization.

The problem is using specialization as an argument for not understanding what happens outside our own tool.

For years, many designers could protect themselves inside a niche. It was possible to focus exclusively on producing interfaces and depend on others to evaluate feasibility, behavior, implementation, or technical quality.

That refuge is becoming smaller.

If a designer's value is limited to arranging elements on a canvas, generating visual variations, or documenting screens, an increasing portion of that work can be accelerated, automated, or absorbed by intelligent tools.

This does not mean AI possesses design judgment.

It means visual production, isolated from product reasoning, is losing value as a professional differentiator.

The difficult part was never drawing the screen. The difficult part was understanding what needed to exist, why it needed to exist, how it should behave, and what consequences it would produce within the system.

AI can generate many solutions. But it does not automatically know which one responds best to the context, protects the user, can be maintained, reinforces the product strategy, or introduces debt that will surface six months later.

That is where the real work of design continues to live.

But to exercise that judgment, designers need to move closer to the real product. They need to see how it is built, understand its constraints, and participate in the decisions that determine its behavior.

Perishing, in this context, does not mean designers will disappear tomorrow. It means risking becoming increasingly dependent professionals, limited to producing deliverables that someone else—human or agent—must interpret, complete, and carry to the final outcome.

The designer who builds is not an engineer in disguise

Becoming a designer who builds does not mean abandoning design or transforming into a full-stack engineer.

Nor does it mean one person should assume responsibility for research, strategy, design, development, security, infrastructure, and maintenance.

Convergence does not eliminate disciplines. It removes some of the rigid boundaries between them.

A designer who builds can translate an intention into a functional experience. They can use agents to implement components, connect flows, and explore alternatives. More importantly, they can evaluate the result and recognize when something works only on the surface.

They understand enough about structure, state, data, APIs, accessibility, and behavior to make better decisions. They can enter a codebase, identify where a component lives, modify it with the help of AI, and verify that the change respects the system.

They also understand where their competence ends.

They can build a functional experiment and collaborate with engineering to transform it into a robust solution. They can validate a hypothesis without compromising the production architecture. They can use the speed of AI without confusing speed with maturity.

This new professional identity is not defined by how many lines of code someone can write. It is defined by their ability to travel further along the path between the problem and the product.

A generated prototype is still not a product

There is an obvious risk in this new paradigm: believing that if something can be generated quickly, it can also be released quickly.

AI can produce a convincing interface in minutes. It can create components, routes, forms, and connections that appear finished. That speed creates a powerful sense of progress.

But a functional demonstration and a sustainable product are not the same thing.

A product must handle security, privacy, accessibility, performance, observability, error recovery, data evolution, compatibility, and maintenance. It must survive users who do not behave as expected and conditions that never appeared in the initial demonstration.

The easier software becomes to produce, the more important it becomes to know how to evaluate it.

Designers who move into construction will need to develop a new discipline: reviewing not only visible quality, but also the integrity of the system supporting the experience.

This requires Design Systems prepared to be consumed by both humans and agents. It requires accessible components, tokens connected to code, composition rules, real examples, testing, and verifiable quality criteria.

It also requires governance.

When anyone can generate a solution, consistency no longer depends on who knows how to build. It depends on which rules guide the construction.

AI reduces the cost of creating. Without a shared architecture, it also reduces the cost of fragmentation.

Judgment becomes more important, not less

One of the most repeated ideas about artificial intelligence is that it will reduce the importance of human creativity.

In design, the opposite is likely to happen.

When generating options is no longer expensive, value shifts toward the ability to choose. When producing an interface is fast, understanding which interface should be produced becomes more important. When anyone can generate a visually convincing solution, the difference lies in the judgment that determines whether the solution is coherent, accessible, ethical, and appropriate for the product.

AI multiplies production. It does not automatically multiply understanding.

Designers remain responsible for interpreting context, detecting contradictions, protecting the experience, and deciding what should not be built. They remain responsible for understanding the human needs behind a request and challenging solutions that optimize a metric at the user's expense.

But now that judgment can extend further.

Designers no longer have to limit themselves to describing the solution and waiting for someone else to translate it. They can shape it, test it, and observe its consequences. They can use construction as an instrument for thinking.

AI can generate possibilities. Design judgment turns a possibility into a product.

What this changes for product teams

This convergence does not affect individual careers alone. It changes the structure of the work itself.

Handoff processes become shorter cycles of building, reviewing, and learning. Prototypes can incorporate real behavior from the earliest stages. Conversations between design and engineering begin around something that works, not only around a representation.

New responsibilities also emerge:

• Design Systems must expose components, tokens, patterns, and rules in formats agents can interpret.
• Designers need to validate behavior, accessibility, and system states, not only visual composition.
• Engineers move from translating every detail toward strengthening architecture, quality, and scalability.
• Teams must clearly distinguish exploratory code from production-ready code.
• Human review becomes critical for decisions involving security, privacy, permissions, and irreversible consequences.
• Design career frameworks need to value functional outcomes and product learning, not only the quality of deliverables.

The goal is not to eliminate collaboration. It is to elevate it.

When designers can build and engineers can participate earlier in product definition, the two disciplines stop meeting only at the boundary of the handoff. They begin working inside a shared space.

The decision ahead

Designers are facing an uncomfortable decision.

They can preserve the old boundary, perfect their deliverables, and trust that producing representations of the product will continue to be enough.

Or they can cross it.

Crossing it means learning new tools, understanding systems, and accepting the discomfort of working with materials that do not always respond visually or predictably. It means moving closer to code, data, rules, and the real consequences of every decision.

Not every designer will build complete products. Nor do they need to.

But it will become increasingly difficult to design relevant products without understanding how they are built.

The future will not necessarily belong to the designers who write the most code. Nor will it belong to those who generate the most screens with artificial intelligence.

It will belong to those who can transform ambiguity into a functional, coherent, and sustainable experience. To those who can move between intention and behavior. To those who use AI to expand their capacity to think, not merely their speed of production.

For a long time, designers could stop before the product existed. We could deliver a vision and leave others to resolve the distance between that vision and reality.

Artificial intelligence is reducing that distance.

And in doing so, it forces us to remember something we may have forgotten:

We were never hired to design files. We were hired to design products. Now we can help build them too.

The two paths have converged. The only decision left is whether we are willing to move forward along them.