Vibe coding is not software engineering. And some execs can't tell the difference
Vibe coders aren't the problem. Excitable execs are.
Every old Western you've ever watched used the same trick. Walk onto the set and the saloon has swinging doors, a bar, bottles on the shelf. Walk around the back and it's scaffolding holding up a painted wall. Nothing behind it.
The Front Holds Up
A vibe-coded demo is the movie set I described. Build the front convincingly enough, and the untrained eye can’t tell what’s missing behind it. From the pitch to the click-through to the words “I built this in a weekend,” it can look indistinguishable from software built at genuine speed. Buttons work. Data flows. It feels finished.
Indeed, according to this June 2026 report, 63% of vibe coding users identify as non-developers: product managers, marketing directors, startup founders, and designers. Forrester estimates 16.2 million active citizen developers worldwide. Gartner predicts they will outnumber professional engineers 4:1 by 2028. The distance between "idea" and "the clickable thing that looks like software" has effectively collapsed.
And that's not a bad thing! It's the biggest gift product teams have gotten in a decade. A prototype that used to take three sprints now takes an afternoon, or gets built overnight with agents working together. And, it gets faster every day. All good so far. So why do some software engineers have an issue with vibe coders?
The Real Issue Isn’t Vibe Coders
The problem starts the moment a business executive tries to monetize the saloon movie set facade as a working fully stocked wet bar to serve real customers, take real money, and survive a real Saturday night.
The problem isn’t software engineers looking down on vibe coders. It’s non-technical leaders and sales teams licking their chops after the ultra quick vibe coded demo, imagining they’re so much closer to releasing this to the customer. That should concern everyone, not just people who understand software engineering.
Software engineers know the difference and worry about what would happen if, to the untrained eye, this prototype was mistaken for having the same quality and craftsmanship as their own work. Someone who can’t tell a vibe coded prototype from real world applications also can’t tell whose work is whose.
Engineers haven't made this easier on themselves either. Calling it all AI slop from the sidelines doesn't teach anyone in the room what's actually missing behind the front. It just guarantees the exec tunes out the warning and keeps nodding.
And I get it. I wrote software for a decade myself, and now I sit in meetings when some demo looks so finished the leader being shown the demo didn’t ask or care how real the capability is, or how far it is from being operationally useful. It can be frustrating to engineers but the exec’s ignorance is not the vibe coder’s fault.
Eventually Someone Pays Up
Not knowing that difference has real consequences that some teams will suffer. What happens when the database drops mid-transaction. What happens when someone deliberately tries to break in. That’s not a prompting skill; it’s a discipline built by learning from your own failures and everyone else’s for years, and learning to see a failure coming before it arrives. The Moltbook hack that exposed 1.5 million API keys, built by someone who’d proudly claimed it was completely vibe-coded, wasn’t caused by trained engineers using AI-assisted coding. It was caused by the absence of engineering, the design and verification work that never happened, with or without AI in the loop. Moltbook was notified directly and addressed all identified vulnerabilities. But not all hackers or enemy regimes will be kind to vibe coded live software holding valuable information.
A movie set saloon propped up by two-by-fours, nail heads sticking out the back, is not a liquor bar built for customers. No amount of enthusiasm changes what's actually holding up that wall. Execs who skip the design review, the test suite, the static analysis, and think the vibe coded demo is close to deployment aren't saving time. They're finding out the hard way what a customer finds out first: that the wall wasn't load-bearing.
Until they understand that difference keenly, they'll keep antagonizing the engineers trying to warn them, and making mistakes far more expensive than the money the vibe coded demo ever saved.