Over the last few years, I have started to feel that prototypes have lost much of their original meaning and purpose for designers.

For a long time, one of the biggest limitations in software design was that we could not truly experiment with end-user experiences before release. Iteration cycles were slow, and many decisions had to be made with limited certainty because there was no realistic way to test interaction ideas before they reached production. Tools like InVision helped change that by giving designers a way to move beyond static screens and present something that felt closer to a real experience. At the time, that was a meaningful step forward.

But looking back, I think that was also the moment when the meaning of prototyping started to shift. These tools improved communication, but they did not really close the gap between design and development. As Sketch, Figma, and similar platforms evolved, they added more interactive features, but most of these prototypes still worked better as presentation tools than as true design artifacts. They became useful for alignment, handoff, and stakeholder reviews, but not always for deeper experimentation. And that raises an uncomfortable question: how often do we actually use prototypes to learn something meaningful about the experience itself? How often do they lead to better product decisions, instead of simply helping us explain an idea that was already decided?

That, to me, is where the meaning of prototyping became distorted. Prototyping has always been a core part of building technology. We imagine a solution, test it, learn from the results, and improve it. That process has remained relevant throughout history because it works. But real prototyping has never been just about simulating interactions. It depends on something deeper: understanding the technology behind the experience, understanding the people using it, and knowing how to interpret feedback in a way that leads to meaningful improvement.

That is not simple work. It requires balance between technical knowledge, product thinking, and human understanding. It requires teams that can move across disciplines instead of staying trapped in silos. And because that kind of balance is rare, truly good products are also rare.

This is why I think AI could have one of its most important impacts in prototyping, especially in software design. For me, the opportunity is not automation for its own sake. It is not about generating more screens faster, or producing code just because we can. The real shift is that we now have the possibility to build working prototypes that are much closer to real product behavior. That changes the value of prototyping completely, because it gives us a way to reduce the gap between what we design, what we test, and what eventually gets built.

If used well, that could dramatically improve iteration cycles. Teams could test ideas earlier, explore riskier directions in safer environments, and get better signals before committing to production. That is a much more meaningful use of AI in design than the idea of designers simply pushing changes directly to live products. In many cases, that would be a mistake. Sending AI-generated work straight into production without the right engineering standards could easily damage code quality, architecture, and scalability. That is not where the real value is. The real value is in giving teams a better way to think, test, and learn earlier in the process.

That is why I do not see AI as a magical solution, but as a reason to rethink how design is practiced. If prototyping becomes more technically real, then the designer’s role also has to evolve. It may require a stronger understanding of systems, logic, constraints, and even engineering itself. Not because designers need to replace developers, but because better experimentation depends on being closer to the material of the product.

In that sense, AI does not just give us better tools. It pushes us to redefine the role of design within software development. Maybe that is what prototyping needed all along: not more polished simulations, but a way to return to its original purpose. Not just to communicate ideas, but to truly test them and make meaningful Wizard of Oz experiments easier to apply.