Vibe Coding in UX Design – Why Designers and Researchers Remain Indispensable

Development cycles that drag on for months. Prototypes that arrive too late to be truly useful. Budgets that vanish into endless iteration loops. Many companies are familiar with these problems. Vibe coding promises a solution: AI-powered prototypes created in hours that are ready for immediate testing. The term was coined in 2025 by AI researcher Andrej Karpathy and describes a workflow where teams articulate their intent in natural language, and the AI generates functional code from it.

For UX teams, this sounds tempting. But what does vibe coding actually mean for day-to-day design work? When does it make sense, and when does it not? And above all: does it replace designers and researchers, or does it finally make their work truly effective?

‍

What is vibe coding, and what is it not?

Vibe coding is not a tool, but a workflow. UX designers describe an interaction in natural language. An AI tool generates functional code from it. This runs directly in the browser and can be used for usability testing.

The classic UX process looks like this: Research → Wireframes → Mockups → Development → Testing.
With vibe coding, this is shortened to: Research → Prompt → Prototype → Testing.
Iteration happens in the browser, not in Figma. Users interact with real flows, not static screens.

This changes the quality of the insights. A clickable prototype shows whether navigation is intuitive. A static screen only shows whether a layout works visually. Especially with complex workflows, this difference is crucial.

Important: Vibe coding is not a substitute for structured UX work. It accelerates the phase between hypothesis and test. If you don't know what needs to be tested, fast prototypes won't help you.

‍

How vibe coding is changing our daily design work

Vibe coding specifically changes three areas of daily UX work: speed, test quality, and stakeholder communication.

Speed: A prototype that would traditionally take two to three developer weeks can be created with vibe coding in one to two days. This allows for multiple iterations per week instead of per month. Teams can react to feedback faster and validate hypotheses earlier.

Test quality: Usability testing with vibe coding differs from classic testing. The prototype is not a simulated interaction in Figma, but a real web app. Users can fill out forms, enter data, and trigger errors. This increases the validity of the test results.
A vibe coding workflow: Formulate a hypothesis, e.g., "Users don't understand the new filter flow" → Generate a prototype with AI → Have five to ten users test it → Identify problems → Adjust the prototype → Test again.
This cycle can be repeated multiple times a day.

Stakeholder communication: Functional prototypes are more persuasive than mockups. Decision-makers can click through a flow themselves instead of having to imagine how it might work. This reduces late-stage pivots and simplifies internal alignment.

The critical takeaway: Vibe coding tempts you to test too quickly. If the hypothesis is unclear, even a fast prototype is useless. UX research requires strategic thinking. Vibe coding accelerates implementation, but it does not replace analysis.

‍

When vibe coding makes sense and when it doesn't

Vibe coding is no silver bullet. It is suitable for certain phases, not all of them. Its strengths lie in the early conceptual phase and in rapid iterations. Its weaknesses become apparent with complex systems, high security requirements, and scalable architecture.

Where vibe coding helps

Early validation: New features or flows can be tested in hours before large development budgets are committed. This reduces the risk of building features that nobody needs.

UX research prototyping: Real interactions provide better insights than click-through dummies. Users can fill out forms, trigger errors, and complete actual tasks. This reveals where they get stuck and where problems arise.

Stakeholder demos: Functional prototypes convince decision-makers better than static screens. They can experience for themselves how a feature works.

Parallel experimentation: Multiple variations of a feature can be tested simultaneously without blocking developers.

Internal tools: Dashboards, admin panels, or configurators used only internally can be built quickly with vibe coding.

Where vibe coding hits its limits

Production code: AI-generated code is often not scalable, secure, or maintainable. AI-generated code frequently still contains security vulnerabilities. Prototypes should therefore not be operated with real user data.

Accessibility: WCAG standards are not met automatically. Semantic HTML is often missing. ARIA labels are forgotten. Keyboard navigation doesn't work. This is a problem for companies legally required to provide accessible products. The European Accessibility Act has been in effect in the EU since 2025. Anyone who takes usability testing seriously needs accessible prototypes. Currently, Vibe Coding does not provide this automatically.

Regulated systems: In MedTech or FinTech, every line of code must be traceable and validated. Vibe Coding makes this difficult.

Complex architecture: Systems with many dependencies, APIs, and data models overwhelm AI tools.

Performance-critical applications: AI-generated code is rarely optimized.

‍

Why designers and researchers remain indispensable

Vibe Coding accelerates prototyping, but it does not replace design expertise. The idea that product owners could create prototypes themselves and make designers redundant is short-sighted.

Research remains essential. Vibe Coding tests hypotheses. But where do these hypotheses come from? From structured UX research. If you don't know what to test, fast prototypes won't help you. UX researchers explore needs and usage contexts, both qualitatively and quantitatively. They provide the foundation for all design decisions.

Writing prompts requires expertise. A bad prompt leads to bad code. A good prompt clearly describes the goal, provides context, and defines constraints. This is a skill that must be practiced. UX designers who want to use Vibe Coding need a basic understanding of code structure—not to program, but to understand what the AI is generating.

Code quality must be evaluated. Is the prototype accessible? Secure? Usable? Only UX designers and usability engineers can answer these questions. Vibe Coding produces code that is often not production-ready. Security vulnerabilities, lack of accessibility, technical debt—all of this must be fixed later.

The role is shifting, not disappearing. Designers are not becoming mockup creators, but prototype conductors. They formulate requirements, evaluate results, and iterate. This requires more competence, not less.

Those who use tools like Vibe Coding correctly combine them with structured research methodology: Jobs-to-be-Done, user story mapping, and contextual inquiry. The prototype is the means, not the end.

‍

What companies should consider before adopting Vibe Coding

For decision-makers, the question is: Should we use Vibe Coding? The answer depends on three factors: goals, maturity, and governance.

Goals: If the goal is to validate faster and get feedback earlier, Vibe Coding makes sense. If the goal is to cut development costs by pushing AI-generated code directly into production, it is risky.

Maturity: Teams that already have structured UX processes benefit the most. Those without a clear research strategy won't build better products just by using rapid prototypes. Vibe Coding is an accelerator, not a substitute for expertise.

Governance: Companies must clarify how they handle AI-generated code. Is it only used for testing? Or does it go into production? If so, who is liable for security vulnerabilities? Who documents the code? Without clear governance, you end up with Shadow IT 2.0: many small, uncontrolled tools that create more problems than they solve in the long run.

‍

Best practices for implementation

Clear division of roles: Designers create prototypes, developers write production code. No mixing.

Prototype = throwaway code: Every prototype has an expiration date. After testing, it is archived, not developed further.

Structured prompts: Teams should use templates for prompts. Example: "Create a filter flow for B2B customers. Users can filter by industry, region, and company size. Results are displayed as a table. Mobile-first, Tailwind CSS."

Testing with real users: Prototypes should not be evaluated internally, but tested with five to ten real users. Internal opinions do not count.

Documentation: Every prototype must be documented: What was tested? What was the hypothesis? What were the results? This documentation informs the final development process.

Security check: Even if prototypes aren't going into production, a basic security check should be performed. No passwords in the code, no open APIs.

Iteration: Prototypes are iterated multiple times. The first draft is rarely good. Two to three iterations are standard.

These practices ensure that vibe coding adds value without creating long-term risks.

‍

Conclusion

Vibe coding is changing how UX teams create and validate prototypes. The speed at which functional prototypes can be built allows for earlier and more frequent testing. This reduces the risk of building features that nobody needs.

At the same time, vibe coding is no substitute for structured UX work. It accelerates prototyping but does not replace research, analysis, or strategic thinking. Teams that use vibe coding correctly make a clear distinction between validation prototypes and production code. Prototypes are discarded once they have served their purpose.

For decision-makers, this means: vibe coding is a tool, not a silver bullet. It works when there is clear governance, teams are trained, and the purpose is defined. Those who meet these conditions can shorten time-to-market and increase product quality. Those who rely blindly on AI-generated prototypes risk higher long-term costs due to technical debt and security issues.

Designers and researchers remain indispensable. Their role is shifting from mockup creators to prototype conductors. This requires more expertise, not less.

‍