Who's Actually Vibe Coding? The Data Doesn't Match the Hype

The Narrative We All Believe

The vibe coding story goes like this: solo founders who can't afford developers, bootstrappers building MVPs in a weekend. Give a prompt, AI generates an app, test with real users.

It's the democratization of software. Anyone with an idea and $20/month can compete with venture-backed startups.

That's what I assumed we'd find when we looked at who actually wanted that guide.

What We Actually Found

34% of people requesting that guide work at companies with 5,000+ employees.

Another 13% at 1,000-5,000 employees.

That's 47% working at enterprises with over 1,000 people. These aren't garage startups. These are people with engineering teams, IT departments, and software budgets.

Solo founders and tiny startups (0-10 employees)? Only 16%.

The data inverted my assumptions entirely.

Who Are These People?

Here's where it gets interesting. The #1 group isn't engineers. Engineers are only 15%.

The breakdown:

• → Executives and strategists: 22%
• → Design and UX: 16%
• → Engineers: 15%
• → Product managers: 10%
• → People and HR: 9%

These are people who normally wait months for developers to build internal tools. People who submit tickets that never get prioritized. People who've been told "it's on the roadmap" for two years.

Now they build it themselves.

What Are They Actually Building?

Not the next unicorn SaaS. Not consumer apps hitting Product Hunt.

Internal tools. Process automation. Custom dashboards IT said would take six months. Scripts to connect systems that don't talk to each other.

It's shadow IT, but faster.

An executive describes "a tool that pulls data from our CRM and formats it for weekly reports" and gets something working in an afternoon. Messy, probably won't scale, but solves the problem right now.

That's way more disruptive than another todo app.

Why This Matters

The vibe coding revolution isn't happening in garages. It's happening inside corporations, driven by people tired of waiting for their engineering teams.

Is this good? Honestly, I don't know.

It empowers people closest to the problems. The person who knows exactly what they need can now build it without filing a ticket, waiting three months, and getting something that doesn't quite work.

But it creates maintenance nightmares. Security risks. Undocumented tools that break when models update.

Engineers complain that vibe coding doesn't work on real codebases. They're right. But they're missing something important: they're not the primary users. The primary users don't care about maintainability. They care about solving problems today.

What Happens Next

This doesn't reverse. The tools will get better and worse simultaneously.

Better at generating code. Worse at maintainability.

Why worse? Easier generation means more code, more dependencies, more edge cases. And nobody maintains it because nobody fully understands it.

Companies will split into two worlds:

• → Core systems that engineers own, where code quality matters
• → A sprawling ecosystem of internal tools that business users build themselves

IT will fight it. Then they'll give up and try to govern it. We'll see "approved vibe coding platforms" and "citizen developer training programs."

The Real Market

That's the real opportunity here. Not building the next Airbnb with prompts.

Just 10,000 internal tools that nobody wanted to build, but everybody needed yesterday.

The people with the problems now have tools to solve them. Messy tools. Tools that will break. But tools that exist today instead of promises for next quarter.

The data is clear: vibe coding already went mainstream. Just not where anyone expected.