Skip to main content

Be a Shepherd, Not a Fence: Why We Need to Stop Gatekeeping "Vibe Coders"

We’ve seen this movie before.

If there’s something I genuinely dislike in our industry, it’s gatekeeping. And the current patronization and disdain towards “vibe coders”—domain experts leveraging AI to build software—is exactly that.

Every time we unlock a new layer of abstraction, the reaction is the same. Think back to C vs. JavaScript: “They’re not real programmers, they don’t even manage memory.” Or the backlash against low-code, or the dismissal of bootcamp graduates.

Underneath that layer of dismissal, there’s often a quiet insecurity: What if these newcomers take my job?

So, we look for reasons to invalidate them. The favorite one right now is Security and Stability. People love pointing out that “vibe coders” ship code with glaring vulnerabilities or unmaintainable spaghetti logic.

And look, I get it. It’s usually the senior engineers who get paged at 2 AM when that hallucinated database query brings down production. The frustration is real. But if you are using “AI writes bad code” as your professional moat, you are playing a losing game. The tools will only get better.

Instead of fearing replacement, we should look at economics—specifically, Jevons Paradox.

Jevons Paradox states that as technology makes a resource more efficient to use, the demand for it increases. By lowering the barrier to entry, we aren’t going to write less software. We are going to write exponentially more.

Until now, because of the high cost of engineering time, only highly profitable or strategic projects were deemed “worthy” of being built. Countless great ideas died in backlogs. Now? The cost of prototyping is plummeting.

Does this mean they will “vibe code” a new distributed database or a core payment gateway? No.

But they absolutely will vibe code the integration layers, custom workflows, and the glue that puts applications together. Tasks that previously required waiting months for a developer can now be done by the domain experts themselves.

So, what does that leave for us? The end of trivial work. Instead of building the 500th basic CRUD dashboard, our focus shifts to building enabling systems. We will be the ones creating the robust APIs, the secure infrastructure, and the rock-solid component libraries that these domain experts can safely snap together.

It might feel counter-intuitive to help the very people who are bypassing traditional development paths, but this is exactly what we must do.

We need to be a shepherd, not a fence.

The skills we’ve spent years honing don’t vanish; they become the map for the newcomers. They will need our guidance to understand:

  • Why their app gets slower by the day (they need database indexes).
  • Why the AI struggles with UI (the component library lacks AI-friendly descriptions).
  • Why their app is vulnerable (they need an experienced partner to explain sanitization and secure auth flows).

Helping others build ultimately benefits us all. When we guide these newcomers, we create parallel streams of value creation.

Embrace the builder spirit. Arm the newcomers. Let’s lower the drawbridge.