When I was at Z company (anonymized) my team built a working prototype of an LLM interaction that leadership loved. Other teams did riffs on our work and also showed it to leadership. But the work wasn’t received well. In that meeting, the lead of the team said: “we just need to show this in code.”

So they turned to vibecoding with Claude. Some designers changed their roles to focus almost entirely on vibecoding prototypes. The prototypes were impressive, but they never left the demo meeting. I spent time thinking about why.

The floating prototype problem

Perhaps you’ve also seen prototypes like this:

It’s in code. It has very smooth transitions and little loading spinners and everything. Cool! But when you start asking questions the illusion falls apart: Where does this live in the product? How do you get to this screen? How do you get out of it? What comes before and after? Where does the data come from and where is it going?

It’s a prototype floating in space detached from any context. I call this “the floating prototype problem”.

This happens when you don’t have a clear vision of what you’re trying to prototype before you start writing code. It happens often because when you try to design in code, you can’t see different variations or states at once. Seeing different states at once and comparing multiple variations quickly are two important processes of doing good design work. The best tool to do this is a canvas-based design tool, not a tab in an IDE.

The dopamine trap

But it’s an easy trap to fall into, because vibecoding is addictive.

Every time you generate code, it either works or breaks something. You type a prompt, hit generate, and wait to see what happens. When it generates something that works, you get a hit of satisfaction. It has the psychological profile of a slot machine: variable rewards on a fixed action. The progress is visible and the feedback is instant.

When you’re typing prompts and watching hot reload, you notice you’re not thinking very much. Your brain chases the dopamine hit and the fake sense of productivity. You keep adding more to your prototype and using more and more tokens. You feel like you’re on fire—but have you actually designed much? Can you put words into the choices you’ve made?

Now when others see your prototype, it’s hard to understand what was intentional and what was incidental. In Figma, what's there is assumed to be intentional because you put it there. So people asked you for clarifications on what they couldn’t see. But now they have to ask you about both what’s there and what’s not there—did you add that bouncy spring animation, or was that just what Claude generated? Was that card layout a conscious choice or a default from a component library? Teammates waste time trying to decipher the decisions you never actually made. The prototype never leaves the demo meeting.

If you’re not using a tool consciously, you’re not in control of it. When you lose control over your design tool, you stop being the designer. The most transformative tool available to designers can become detrimental to the quality of your work.

When to prototype with code

Vibecoding unlocks real capabilities for designers to make their vision come to life. But as with all tools, it should be used with intention and purpose.

I have two reasons for prototyping with code:

1. To prove that something is possible.
   When there’s uncertainty about feasibility, a code prototype can validate that an interaction is possible. Even if some parts have to be faked, you can have a sense of what it would feel like if the constraints weren’t there. It can be a guiding light to the whole team for what the product can be.

2. To test what can’t be designed statically.
   Some interactions—especially those involving timing, physics, gestural input, responsiveness—can only be truly evaluated when they’re real. Usability tests can be a thousand times more accurate with real data and real input methods. Especially with AI products where the LLM response is crucial to the experience, using real APIs in your design reveals how your design will actually feel.

Back to the Z company story: we showed our design as a code prototype, but that was only part of our intention. We were proposing a new interaction model, so we needed to prove that 1) it could be done with existing technology and 2) it would feel good to use. Code served those goals but was never the goal itself. Because every decision was intentional, engineers could use the prototype as interactive design specs.

Code does not make design better

Filmmaker Kurosawa Akira said: “With a bad script even a good director can’t possibly make a good film.” Steven Spielberg said it more concisely: If it ain’t on the page, it ain’t on the stage.

If it’s not good on script, it won’t be good on screen. When you turn a bad script into a movie, you just add more dimensions to a bad story.

Code will not make your design better. If it’s bad in Figma, it’ll be bad in code. You still have to do good design work before putting it into code. This used to be less obvious because prototyping was hard—if you could get something working at all, it felt like an achievement. Now everyone can create a working prototype, which means the difference between good and bad design is more visible than ever.

Vibecoding brings your design to life. But whether the result is good depends entirely on your design. If you’re Pygmalion who wanted his beloved sculpture to come alive, you’ll get the love of your life. If you’re Dr. Frankenstein who wanted to animate a corpse, you’ll get an animated corpse.

Use it intentionally, as with anything else

Vibecoding is powerful, but power without direction always poses danger. Depending on how you use it, what comes alive could be great craft and intentional design or weak craft with an unclear purpose.

Know what you’re trying to build. Do good design first. Have an idea of what “feeling right” means for the interaction. Set boundaries on what should be made real and what doesn’t matter.

Then add the tool. Learn how to use it, as you would with any other tool—read and understand what’s being generated. Know what the parameters mean and how to adjust them to make it feel right. The better you understand it, the better you can shape it.

Tools serve the vision, not the other way around.