Vibe coding works. I want to say that first because everything after it will sound like I don't believe it, and I do. I've watched people with zero engineering background stand up functional apps in an afternoon. In fact, just recently, I built a March Madness bracket app in one evening, and my family and friends are now creating bracket pools (shameless plug — bracket-dollogy.com). That was not possible two years ago. If you're one of those people, you should feel good about what you built.

That was in the evening, now let me tell you about my day.

We built an IoT platform for multi-family operators. Three disparate SDKs from multiple hardware vendors, each with its own auth patterns, error handling conventions, and firmware version dependencies, all supporting several versions of similar products, controlled through a single app. All of it unified through a complex GraphQL service layer that has to resolve across those SDKs, normalize the responses, and serve them to mobile endpoints with graceful fallback when one vendor's API decides to misbehave. And all of it has to maintain absolute reliability. That last part matters more than it sounds. Nobody wants to get locked out of their apartment because a vendor SDK threw an unhandled exception at midnight.

Nobody vibed their way through that. Not because vibe coding is bad, but because that is a fundamentally different category of problem.

I keep coming back to the birdhouse analogy. A birdhouse is a legitimate thing. It keeps the rain off a bird. But nobody who finishes thinks that they understand structural engineering or municipal code compliance. The gap isn't a spectrum. It's a phase change, and I think most people intuitively know that about physical construction but somehow lose the thread when it comes to software.

Here's the part that I think trips people up, and honestly, it's the part I find most interesting.

AI has genuinely compressed the first 30% of software development. Scaffolding, boilerplate, CRUD, UI components, even moderately complex business logic. That compression is real.

The mistake is assuming that completing 30% of the work means you're 30% of the way to production. You're not.

That remaining 70% is where 95% of the actual complexity lives. It's where your elegant data model falls apart when two users edit the same record. Where the third-party API returns different error formats depending on which data center handled the request. Where someone in a suit asks about your key rotation strategy, and you need an answer that isn't a blank stare. And since we're using the percentages as a theoretical baseline, we have always said in software engineering that the last 10% can, and often does, take 90% of the time.

I'm not worried about vibe coders themselves. They're mostly building for small audiences. They've never hit multi-tenant isolation problems because they have one tenant. None of that makes them wrong about their experience. It just makes it a narrow basis for claims about software delivery in general.

What I am worried about is the telephone game between a viral demo and a boardroom. Decision-makers who don't know the difference see the birdhouse and assume the high-rise is a few weekends away. If you've ever had to explain to a non-technical stakeholder why "just do what that guy on Twitter did, but bigger" isn't a plan, you know exactly what I'm talking about.

Don't get me wrong, the birdhouse is going to keep getting better. Second story, maybe a garage. I'm paying close attention to that trajectory. But the high-rise doesn't get simpler. Regulatory requirements compound. Integration surfaces multiply. The floor for "enterprise-grade" rises every year, especially with new AI security threats.

If you're building birdhouses, keep building. You're learning real things. But be honest about the altitude. The view from the 40th floor is a different problem, and the engineering required to get there isn't gatekeeping; it's physics.

P.S. One AI was used in the editing of this post. It did not complain.