Digital design has always worked through representations. Wireframes represent structure, mockups represent visual intent, prototypes represent interaction, and specifications describe expected behavior. These artifacts are useful because building real software is expensive, so they give teams a way to discuss possibilities before committing significant engineering time.But every representation creates distance from the thing itself.
A perfect Figma prototype can still hide a difficult implementation. Static screens cannot show every state. A scripted prototype may demonstrate the ideal path while ignoring what happens when data is missing, a response is slow, or the system is uncertain. The closer design gets to real product behavior, the more of those questions become visible.
Prototypes are becoming working environments
With AI-assisted coding, no-code tools, accessible APIs, and increasingly capable prototyping environments, designers can reach functional behavior much earlier in the process.
A prototype can now use real data, call a model, persist state, expose latency, and show what happens when an output changes from one interaction to the next. Instead of simply demonstrating how an experience is supposed to work, it can reveal where a seemingly simple idea becomes confusing once it meets actual system behavior. In my view, this is a meaningful change because the artifact is no longer just a representation of a solution. It becomes a working environment where the team can test assumptions, encounter limitations, and discover problems that may not be visible in static design.
The purpose shifts as well. When the goal is to persuade, the experience is usually optimized to feel convincing. When the goal is to learn, it becomes more important to expose uncertainty, limitations, and unresolved questions. I think that second mode is often more valuable, particularly when the product depends on complex or unpredictable behavior.
The designer does not need to become the engineer
This shift is sometimes interpreted as a demand for every designer to learn how to code. I think that interpretation is too narrow.
Technical fluency can certainly be useful. The ability to build something independently can create speed and autonomy, especially during early exploration. But the larger change is not really about replacing engineering or turning designers into engineers.
It is about reducing the gap between product thinking and product reality.
When designers can explore real behavior earlier, they can ask better questions. Engineers can challenge assumptions before a design becomes too fixed, and the team can discover sooner that a model is too inconsistent for a proposed interaction, that a data source lacks the necessary granularity, or that an experience described as “instant” actually takes several seconds.
These are not merely implementation details. They directly shape what the user experiences, which makes them product questions.
The goal is not for design to absorb engineering. The more useful outcome is for design and engineering to meet earlier around the actual behavior of the product.
From handoff to shared investigation
Traditional workflows often follow a familiar sequence: design explores, design converges, the work is handed off, engineering discovers constraints, and the team negotiates compromises. Some version of this process will probably always exist because different disciplines have different responsibilities. But working prototypes make another mode of collaboration possible. Instead of presenting a final design and asking engineering to reproduce it, the conversation can begin while the behavior itself is still being explored. The team can discuss what experience it is trying to create, which parts have already been tested, where uncertainty remains, how the system should adapt, and what should happen when an AI system produces a poor result. To me, this changes collaboration from translation into investigation. The interface becomes a shared object that product, design, and engineering can interrogate together. Rather than each discipline working mainly through representations of another discipline’s work, the team can spend more time discussing the actual behavior of the product.
That changes the nature of the handoff. Instead of “Here is the final design; build this,” the conversation becomes closer to: this is the behavior we are trying to create, this is what we already understand, and this is where the product is still uncertain. The difference is subtle, but important.
Shorter learning loops matter more than faster production
The obvious benefit of AI-assisted prototyping is speed. Speed is useful, but I do not think it is the most important part of this shift.
The larger advantage is the shorter learning loop:
Idea → behavior → experience → feedback → revision.
When each loop becomes inexpensive, teams can learn directly from the product rather than only reasoning about it in abstract terms. A designer can see whether an explanation remains useful when it appears next to real data. A team can experience the difference between an AI system that suggests an action and one that performs it. A complex flow can be simplified after observing where people hesitate in a functional version rather than debating the flow in a diagram. The quality improvement comes primarily from iteration, not acceleration. Making the first version twice as fast is useful. Learning twice as fast is more powerful.
Working prototypes change what can be designed
Some product ideas are difficult to understand through static screens because much of their value exists in behavior rather than appearance. Adaptive interfaces are one example. AI systems are another. A mockup can show a generated recommendation, but it cannot fully communicate how frequently that recommendation appears, how it changes with context, how predictable the system feels over time, or how the experience changes when the recommendation is wrong. Those qualities are experiential. They emerge only when the system actually runs. I think this becomes increasingly important as more products become dynamic, probabilistic, and context-aware. Design methods need to engage directly with those characteristics rather than describing them only through static representations. For that reason, the designer’s artifact is moving closer to software. Not because software should become the only valid design output, but because some design questions cannot really be answered outside a functioning system.
Closer to the product also means closer to consequences
There is another side to this shift. As designers get closer to working software, it becomes harder to treat a design decision as an isolated visual choice. Decisions about an interface are connected to performance, data, operations, accessibility, privacy, trust, and maintainability. I think this is useful pressure. It encourages design to engage more deeply with the system rather than treating implementation as something that happens later. It also creates a stronger sense of authorship, because the designer is no longer responsible only for how a product appears in its ideal state. They also participate in shaping how it behaves when reality becomes less predictable.
This matters especially for AI products, where errors, uncertainty, latency, and changing outputs are not always edge cases that can be designed away. In many cases, they are part of the core experience. Designing the happy path is no longer enough.
The role is expanding toward the product, not away from design
The most interesting consequence of these tools is not that designers can produce more screens or deliver them faster. It is that designers can spend more time with the thing they are actually designing. They can move between strategy and execution with less friction, use making as a way to think, collaborate with engineering around real constraints earlier, and explore behavior instead of only documenting intent. I do not think the ideal outcome is a designer who can do everyone else’s job. The more valuable outcome is a product team in which the distance between disciplines becomes smaller and the feedback loop between an idea and reality becomes faster. For design, that feels like a return to something fundamental. Not simply the representation of the product. The product itself.
