The real value of vibe coding has nothing to do with code, but clarity

Don’t put vibe codes in production. Do this instead.

There’s been a massive trend lately in “vibe coding” — the practice of using AI agents to generate code from natural language prompts. The hype is everywhere, but my favorite definition so far comes from a meme’d exchange between Linus Torvalds and Bill Gates, who essentially summarized it as entertaining, but ultimately inefficient.

And honestly? I kind of agree with him. Just not for the reasons most people think.

A bit of context on where I’m coming from:

I work in data and product — dashboards, pipelines, and product management. Every day, I’m sitting between the people who build things and the people who make decisions, ultimately deciding what is to be built. If you’ve been in that seat, you know how exhausting that translation work can be.

The truth is, here, in this space, communication breakdowns run both ways. Tech teams love to blame business teams for not understanding tech. But technical teams just as often don’t fully grasp what the business actually needs. Nobody’s the villain. It’s just a genuinely hard problem.

Vibe coding, for me, has quietly become one of the best tools I’ve found for closing that gap.

The communication barrier

How I actually use it

My process is three steps:

• I sit with the business stakeholders, listen, and capture the logic behind what they want. The flow. The feeling they’re going for.
• Depending on complexity, I spend some days vibe coding a rough version. Not beautiful, not scalable — just functional enough to run and feel real.
• I go back to the business team, but not to collect more requirements. I present what I built and say, “This is what I understood from our conversation. Does the logic hold? Where does it fall apart?”

That’s it. And what happens next is where it gets interesting.

Why it works, where design prototypes sometimes don’t

Tools like Figma or InVision are useful, but they simulate interaction rather than replicate it. They also require pulling in your design team, consuming valuable time and money to create high-fidelity prototypes before the core business logic is even validated.

Then again, we’ve all sat in design reviews where we spend 20 minutes debating the logo version, completely skipping over the actual features. But when stakeholders click through a vibe-coded app where data actually flows, the feedback changes completely. They stop imagining and start reacting to the real logic.

By vibe coding the initial proof of concept, you bypass the upfront design cost. Better yet, when you finally hand it to the design and dev team, they aren’t starting from a static wireframe but a pressure-tested model. The reduction in back-and-forth alone makes it worth it.

A vibe-coder in one-two

So am I “pro vibe coding”?

For production, at enterprise scale, with real users and compliance requirements? Not yet. The code that comes out of these sessions isn’t optimized, isn’t always secure, and isn’t built to last. That’s just where we are with the tools right now.

But as a proof-of-concept engine? As a way to validate what you’re building before a single sprint gets committed? Yes. Fully.

If you’re a PM reading this…

Pick one requirement that keeps shifting shape every meeting. Spend a couple of days building a rough version of it. Then bring it back to the room. You’ll find the conversation changes entirely when people can see the thing instead of imagining it.

It won’t replace your developers. It won’t replace good design. But it will make everything downstream faster, cleaner, and a lot more aligned. ‘Torvalds’ called it inefficient. He’s not wrong about the code. But the clarity it creates? That part’s very efficient indeed.