I’ve read every hot take on “vibe coding” so far.

And if you haven’t yet, crawl out from under that rock (but also, see my awesome explanation).

You’re coding from feel. From instinct. From vibes.

Sometimes it works.

Sometimes it really works.

And sometimes, you end up six tabs deep in some fringe GitHub repo wondering how the hell you got there.

But the more I talk to engineering leads and product folks, the more I realize that vibe coding is happening whether we name it or not.

What does that mean for us?

😇 My Optimistic Take: “Let the vibes cook.”

Great software isn’t built on specs alone. It’s built in flow.

Vibe coding makes space for intuition, experimentation, and fast iteration. It’s how you get those moments of brilliance … the magic the brief didn’t ask for but your users will love.

AI copilots are only accelerating this. They're whispering “what if?” to our editors and encouraging devs to color outside the lines.

😈 My Pessimistic Take: “Vibe coding is chaos with better PR.”

It’s how spaghetti code gets shipped.

It’s how tech debt becomes “we’ll figure it out later.”

It’s how teams lose alignment, ship features no one asked for, and burn cycles chasing dopamine instead of value.

Let’s be real: Calling it "vibe coding" is just a meme-ified way to justify skipping process.

Vibe coding can be where innovation starts.

But it can’t be where it ends.

It needs to be captured, reviewed, and validated. You need systems that allow for flow but don’t rely on it to deliver.

So I’m curious—what’s your take?

When has “vibe coding” led your team somewhere incredible?

And when has it absolutely bitten you in the ass?