Why Vibe Coding Is Both Useful and Uncomfortable for Designers

Pros and cons of introducing vibe coding into the design process

I worked as a product designer at a large enterprise organization. Like many teams right now, we’re navigating a wave of AI tools that promise speed, leverage, and new ways of working. One of the practices that keeps coming up in conversations is vibe coding — loosely defined as using AI to explore, prototype, and shape ideas without writing production-grade code.

Vibe coding is surfacing now not because designers suddenly want to be engineers, but because the nature of design work is changing. We’re being asked to operate earlier in ambiguity, respond faster to shifting requirements, and collaborate more tightly with engineering and product. Traditional deliverables alone — static mocks, flows, and specs — often aren’t enough to carry intent through that complexity.

That said, bringing vibe coding into an enterprise design environment is not frictionless. I’ve experienced real pushback, confusion, and skepticism. I’ve also seen real value when it’s used carefully and with clear intent.

This is my honest take on the pros and cons.

‍

Cons & Friction (The Parts We Don’t Talk About Enough)

1. Pushback from designers who prefer the old process

Some designers are understandably uncomfortable with vibe coding. Established processes — research, wireframes, visual design, specs — are familiar and safe. Vibe coding can feel messy, premature, or like it undermines craft.

I’ve heard concerns like:

• “This feels like skipping steps.”
• “Are we designing, or just generating things?”
• “Is this going to lower the bar for quality?”

These concerns aren’t wrong. Without intention, vibe coding can lead to shallow thinking or premature solutions.

2. Uncertainty about where it fits in the design process

One of the biggest challenges is simply not knowing when to use it. Is vibe coding ideation? Prototyping? Validation? Documentation?

In a mature design organization, ambiguity about process creates risk. If vibe coding shows up randomly, it feels like a rogue activity rather than a legitimate design method.

3. Engineering skepticism

This is real. Some engineers worry that designers vibe coding blurs boundaries or creates unrealistic expectations.

Common concerns include:

• “Is this meant to be production-ready?”
• “Who owns the output?”
• “Are designers now designing systems without technical constraints?”

Without clear framing, vibe coding can feel like designers overstepping into build territory instead of collaborating toward shared understanding.

‍

Pros & Leverage (Where It Actually Shines)

Despite the friction, I’ve found several areas where vibe coding is genuinely valuable.

1. Motion design and interaction refinement

Vibe coding is incredibly effective for exploring motion and interaction details that are hard to express in static tools. Instead of explaining how something should feel, I can show it.

This has led to better conversations with engineers because we’re reacting to the same artifact, not interpreting specs differently.

2. Turning ambiguity into visual hypotheses

In enterprise work, requirements are often incomplete or abstract. I’ve used vibe coding to turn vague ideas into visual hypotheses — for example, building a simple impact simulator to explore “what if” scenarios.

These aren’t final solutions. They’re thinking tools that make ambiguity visible and debatable.

3. Synthesizing call transcripts into action

Uploading call transcripts and using AI to extract themes, next steps, and task breakdowns has saved significant time. More importantly, it helps translate raw input into something the team can act on quickly.

This supports design work rather than replacing it.

4. Clickable competitive analysis

Instead of static slides, I’ve used vibe coding to create quick, clickable competitive walkthroughs. Stakeholders engage more deeply when they can interact with patterns instead of just reading about them.

Again, these are not production artifacts — they’re conversation starters.

‍

How I’m Using This Responsibly

I don’t treat vibe coding as a replacement for design fundamentals. I treat it as a thinking accelerator.

Here’s how I keep it grounded:

• I use vibe coding early, when clarity is low and exploration is valuable.
• I’m explicit that outputs are prototypes, not solutions.
• I involve engineering early, framing these artifacts as shared learning tools.
• I still rely on traditional design methods for validation, polish, and production handoff.

Most importantly, I apply judgment. Just because something can be generated doesn’t mean it should be.

‍

What This Means for the Design Process

Vibe coding doesn’t eliminate the design process — it adds a new lane.

Used well, it helps:

• Accelerate thinking
• Make ambiguity tangible — Ever wonder what an impact simulator looks like? I have.
• Improve collaboration through shared artifacts

Used poorly, it creates noise, confusion, and mistrust.

The difference is intent.

‍

Practical Takeaways

Designers should use vibe coding when:

• Requirements are ambiguous
• Interaction or motion is hard to describe
• You need a fast, tangible way to explore ideas
• The goal is learning, not shipping

Designers should not use vibe coding when:

• The problem is already well-defined
• Quality and accessibility need deep attention
• Outputs might be mistaken for production-ready work

To introduce it safely in a mature organization:

• Be explicit about purpose and limitations
• Position it as exploratory, not authoritative
• Share outputs early with engineering
• Anchor everything in design judgment, not novelty

‍

Vibe coding isn’t the future of design. Designers are. Tools will keep changing. Our responsibility — to think clearly, make good decisions, and collaborate well — doesn’t.

That’s where the real value still lives.

‍

Hey! I'm on Substack https://substack.com/@anastasiawalia

‍