Vibe coding didn't change who makes good products. It changed what's cheap. A designer can now describe an interface in plain English and have a working, clickable prototype by the end of the afternoon, with real code underneath. For AI prototyping, that's a real leap. But the hype around it gets one thing badly wrong: it assumes the tool is doing the design.
It isn't. A growing share of our client work is repairing products where someone assumed it was: screens that don't match, flows that only work on the happy path, and prototypes that shipped as production code.
[IMAGE: A designer's screen split between a plain-language prompt on one side and a working, interactive app prototype on the other]
What Is Vibe Coding?
Vibe coding is building software by describing what you want to an AI and steering it by reacting to what it produces, rather than writing the code yourself. Andrej Karpathy, an OpenAI co-founder and former head of AI at Tesla, coined the term in early 2025 for a mode of working where you "fully give in to the vibes" and forget the code exists. By November, Collins Dictionary had named it Word of the Year.
For UX designers, the working loop looks like this:
- Describe a screen, flow, or interaction in natural language, or hand the AI a Figma frame.
- The AI generates working front-end code.
- Click through it, notice what's wrong, and describe the fix.
- Repeat until it behaves the way you intended.
That's a different animal from the first wave of AI features in design tools, which mostly generated static layouts. A vibe-coded prototype runs. It holds state, responds to input, and can pull in real data.
The short version: vibe coding turns a description into running software. The description is still the hard part.
AI Prototyping Is the Latest Chapter in an Old Story
Every major design tool shift has done the same thing: made one kind of work cheap and moved the value somewhere else.
Sketch made layouts cheap. Before it, a clean interface mockup took hours in tools built for print and photo editing. Once mockups were easy, the value moved to what went in them: information architecture, interaction logic, the reasoning behind each screen.
Figma made collaboration cheap. Once anyone could open a file and comment in real time, the scarce skill became facilitation: getting a room of stakeholders to a decision, and knowing which feedback to act on and which to let go.
Vibe coding makes working code cheap. Prototyping with AI collapses the distance between an idea and something you can click through from weeks to hours. So the value moves again, this time to knowing what's worth building, what "right" looks like, and when the output is wrong in ways the happy path won't show you.
"AI is a tool, just like Sketch and Figma were. It can get you to the output you want faster, but in the end, the designer controls the final output. Tools don't make the work great. People do." Heather, CEO, SeaLab
The pattern holds because the tools keep getting better at execution and stay exactly as good at judgment as the person using them. AI replaces production volume, not diagnostic judgment.
[IMAGE: Simple three-step timeline showing Sketch, Figma, and vibe coding, each labeled with what it made cheap and where the value moved]
Where Vibe Coding Earns Its Place in UX Work
We don't standardize on one tool at SeaLab. Our team works in Claude Code and Claude Design, our contractors use OpenAI's tools, Codex, and Lovable, and we use Figma's AI features and plugins along with MCP connections that let AI tools read real design files. The tools vary by person and project. The quality bar doesn't.
Here's where vibe coding pays off, in the order it usually shows up on a project.
It starts with exploration. When a working version of an interaction costs an hour instead of a sprint, you can afford to build three and compare them. Designers get to judge a transition, a drag behavior, or an inline edit by using it, instead of arguing about it from a storyboard.
Exploration leads to better testing. A static prototype asks users to imagine. A vibe-coded one lets them do. When a participant can type into a real field, trigger a real error, and try to recover from it, the findings get sharper. You stop hearing "this looks confusing" and start learning exactly where the flow broke their mental model.
Better testing makes alignment faster. Static screens start debates. A working prototype tends to end them. When a PM, an engineer, and a VP can all click through the same flow, the conversation moves from interpreting the design to deciding on it.
And it opens up states static tools can't show. AI features behave in ways a frame can't capture: streaming responses, uncertain loading times, confidence levels, partial failures. You can draw those in Figma, but you can't feel them. Vibe coding lets you prototype variable output and watch how people react to it. We go deeper on designing for that kind of behavior in how we use AI in our UX design process.
Where Vibe Coding Breaks
A meaningful share of our recent work has been repair. Teams come to us with a product that was designed, or mostly designed, by AI, and the seams are showing. The patterns repeat often enough that we can name them.
The prototype gets mistaken for the product. Vibe-coded output looks finished. It has real buttons and real transitions. That polish makes it easy to skip the step where someone asks whether the underlying structure is sound. Throwaway code becomes production code, and every shortcut becomes debt.
It builds the happy path. AI generates what you describe. If you don't describe the empty state, the error state, the permission-denied state, or the user who abandons halfway through, you don't get them. A designer who knows to ask for those gets a far better result than one who doesn't, and knowing to ask is the job. The fix is simple and unglamorous: write the state list before you write the prompt.
Every screen invents its own design system. Without a shared source of truth, each generated screen picks its own spacing, colors, and component variants. Put three people on a team prompting three different tools, and you get a product that feels like three products.
Polish hides weak decisions. This is the one that worries us most. When we looked at how AI changed our own practice, we found it works as a first pass, not a final pass, a finding we wrote up in our take on whether AI will replace UX designers. A beautiful prototype of the wrong solution is still the wrong solution, and it's harder to argue against because it looks so ready to ship.
What it taught us: vibe coding amplifies whatever judgment goes into it. Strong direction gets faster. So does weak direction.
[IMAGE: Side-by-side of three mismatched AI-generated screens from the same product, each with different buttons, spacing, and colors]
Signs your product has vibe-coding debt
None of these show up in a demo. All of them show up in your roadmap. If two or more sound familiar, the problem is structural, not cosmetic:
- The same action looks different on different screens. Two "save" buttons, three date pickers, inconsistent error messages.
- New screens take longer to build, not shorter. Every addition means deciding which of the existing patterns to copy.
- Engineers rebuild prototypes instead of extending them. The handoff artifact gets thrown away and recreated from scratch.
- Nobody can say which component is the real one. Design, engineering, and the AI tools each have their own answer.
- Edge cases surface as support tickets. Users are finding the missing states before your team does.
What a repair engagement usually looks like
- Audit what exists. We inventory every screen and flow, map where patterns diverge, and find where the happy path hides missing states. It's the same diagnostic approach behind what a UX audit actually looks like.
- Consolidate. We pick the patterns worth keeping, retire the rest, and rebuild the product on one shared set of components.
- Make the system readable. We structure and document that system so the team's AI tools generate from it going forward, which keeps the drift from coming back.
The third step is the one teams skip, and it's why the problem returns six months later.
Choosing AI Prototyping Tools: What Matters More Than the Tool
We get asked for the best AI prototyping tools constantly. Our answer is a set of questions, because the right tool depends on the job, and the options change every few months.
- Can it read your design system? A tool that generates from your real components and tokens produces prototypes that look like your product. One that doesn't produces something that looks like every other AI-generated app. MCP connections to Figma files and code repos have made this far more practical than it was a year ago.
- What happens to the code afterward? If the prototype is disposable, export quality barely matters. If engineering might build from it, you need readable, structured code, not something that works by accident.
- How well does it handle iteration? The first generation is rarely the problem. The tenth round of "change this one thing without breaking the rest" is where tools separate.
- Who on your team will use it? Code-native tools like Claude Code and Codex give designers who are comfortable in a terminal precise control. Visual builders like Lovable and Figma's AI features lower the barrier for everyone else.
The tool matters less than the person steering it. Strong designers get excellent results from basic tools, and vague direction gets generic output from the most capable ones.
Do UX Designers Need to Learn to Code Now?
No, but they need to read the output with a critical eye. The bar has moved from "can you build it" to "can you tell when it's wrong."
In practice, that means three kinds of literacy:
- Component literacy. Knowing whether a generated screen used your real button or invented a lookalike.
- State literacy. Spotting what's missing: the loading state nobody prompted for, the error that never got handled.
- Constraint literacy. Knowing which design decisions engineering will push back on, so the prototype doesn't promise something the product can't deliver.
Designers who already think in systems pick this up fast. The ones who struggle are usually the ones who treated the design file as the final product, because vibe coding removes that buffer.
What Vibe Coding Changes About Design to Dev Handoff
Traditional design to dev handoff is a translation exercise. A designer produces static screens and specs, an engineer interprets them, and fidelity leaks out at every step. Vibe coding can shrink that gap, but only under one condition: the prototype has to be built on the same foundation as the product.
That's why one of the most valuable things we do now is help teams set up a design system AI can read. When components, tokens, and usage rules are structured and documented so an AI tool can consume them, often through MCP, a vibe-coded prototype stops being a throwaway and starts working as a living spec. Engineers get something that already uses the real button, the real spacing, and the real patterns. We cover the structure behind this in design system best practices from 10+ real builds.
The check: before anyone treats a vibe-coded prototype as a spec, ask one question. Does it use our components and tokens, or did the AI invent its own? If it's the second, the prototype is a sketch, no matter how real it looks.
Engineering still owns architecture, performance, security, accessibility at scale, and everything that keeps a product running after the demo. A strong handoff in this model is a working prototype built on shared components, plus a short written rationale for the decisions the code can't explain on its own.
Why This Matters (Depending on Who You Are)
For designers and design leaders: vibe coding is worth learning, the same way Figma was worth learning. But what makes you valuable is knowing what good looks like, which edge cases matter, and when the output is wrong. For any AI product designer, that judgment is most of the job. If you lead a team, decide now which tools feed from your design system and which are for throwaway exploration, before everyone picks their own.
For PMs and founders: a working prototype in a day is real. A production-ready product in a day is not. Use vibe coding to test ideas cheaply and align your team faster, then budget for the design and engineering work that turns a convincing demo into something users can rely on.
For engineering leaders: the prototypes coming your way are about to get a lot more functional. That's good news if they're built on your design system and a headache if they're not. Set up the shared foundation before the vibe-coded prototypes pile up, not after.
Good Tools Need Good Hands
Vibe coding is a real shift, and we're glad it's here. It makes our team faster, our tests sharper, and our prototypes more convincing. But every tool shift we've worked through has taught the same lesson: the tool raises the floor, and people still set the ceiling.
If your team is sorting through AI-generated designs that don't fit together, or you want a design system your AI tools can work from, we'd like to help. See how we work on our UX design services page, or book a free 60-minute working session. No pitch, just clarity.