I did not come to AI-assisted prototyping because I had a strategy. I came to it because I was curious, because my organization was pushing in that direction, and because I have learned enough in my career to know that if you do not adapt, you get left behind. I have seen it happen. People who were good at their craft, who got comfortable, who stopped evolving — and then one day the environment shifted and they were not ready for it.
That is not the place I want to be.
But I want to be clear — staying relevant is only part of it. The other part is that AI genuinely excites me. Not because it does the work for me, but because of what it makes possible. And the more I have worked with it, the more I have realized I do not just want to use it. I want to help shape how designers use it as this transition unfolds. That is why I am writing this.
What Vibe Coding Actually Means in Practice
Vibe coding, if you have not run into the term yet, is essentially AI-assisted prototyping — using large language models to help you build working interfaces faster than you could writing every line yourself. It is not drag and drop. It still requires you to know what you are doing. But it compresses the time between idea and something you can actually put in front of a user.
I build. That context matters here. I have spent years in front-end web development alongside my design work. So when I talk about what AI can and cannot do in a workflow, I am not guessing. I know what the output should look like. And knowing what good looks like is what separates using AI intentionally from just generating noise faster.
Where It Actually Earns Its Keep
Let me give you some context on how my team is structured because it matters. Typical product team — several developers, one designer, a product owner, a PM, and the business. We are doing a mix of enhancements on an existing web app and phased releases of new features.
For enhancements, honestly, the setup cost can outweigh the benefit depending on the scope of the work. You have to ask yourself if replicating parts of the existing app locally and configuring a workspace is worth it for a single page edit. Sometimes it is, especially if you are building toward a longer workflow. Sometimes it is not.
New phase work is where everything clicks. Starting fresh, building a new feature — that is where AI assistance genuinely changes what is possible. You make intentional decisions upfront about where you are building and how your design system fits in. Then you build a full, multi-feature prototype and scale it back to define MVP. Once the environment is set up, iteration becomes editing instead of rebuilding. The time savings are real.
The Thing That Changed How I Think About Prototyping
Here is something I have added to my workflow that I think is underused and undertalked about — powering prototypes with a local database like SQLite instead of static dummy data.
Most prototypes are read only. You click through states, you simulate interactions, but the data is not really doing anything. The moment you introduce a real database into your prototype, everything changes. You can test creation workflows end to end. You can see how data behaves across multiple states. You can put a user through a long, complex workflow and watch what actually happens — not what you assumed would happen. That is a fundamentally different quality of insight than a click-through gives you.
It also changes the developer conversation. When you can show what a workflow actually does with real data moving through it, you are not describing an interaction anymore. You are demonstrating it. A lot of the questions that would have come up in handoff get answered before anyone has to ask them.
The Struggles Are Real
AI-generated artifacts land differently depending on who receives them. Personas, journey maps, process maps — AI can produce solid drafts of all of these and save you hours of documentation work. But validation is not optional. You still have to go back to users. The transcript helps you build better artifacts. The artifacts still have to be tested against reality.
Handoff is still a conversation. A prototype is a starting point, not a finished answer. The questions about how interactions translate to code, what logic a flow implies, what edge cases exist — those still need to happen between you and the developers building it. AI helps you get to that conversation better prepared. It does not replace the conversation.
And before anything else — know what tools your organization has actually approved. Build your workflow around something that clears your company's security and data requirements. Doing it the other way around is a problem you do not want to solve halfway through a project.
What I Actually Think About Where This Is Going
AI is not going to replace designers. I genuinely believe that. But I do think it raises the bar on what clarity looks like in our work — better documentation, better prototypes, better handoffs. The designers who are going to thrive are the ones who stay in the driver's seat. Who know what good looks like. Who use the time AI saves them to think more carefully about the decisions that actually matter.
Vibe coding is not a shortcut. It is a multiplier. And like any multiplier, what you bring to it determines what you get out of it.
Still figuring this out in real time — just like the rest of you.