Your Code Doesn’t Need to Scale. Engineers Are Just Gatekeeping.

You’ve had this conversation. You show someone a tool you built – a quick script, a simple web app, something that works perfectly for your 50-person team. And they lean in and say, coldly: “Yeah, but it won’t scale to 10,000 users.”

That moment isn’t advice. It’s a ritual. It’s a way of reminding you who belongs in the club and who doesn’t. And it’s exactly the kind of thinking that’s about to become irrelevant.

Welcome to the era of vibe coding – where the bottleneck moves from how to write code to what you actually want to build. And the old guard is terrified.

Let me tell you what I saw in a Harvard course on the subject. The top comment under the announcement? A developer sneering that vibe coding is a disaster. And then, right beneath it, someone else wrote something that stopped me cold:

“People will scream their lungs out about how bad vibe coding is, but there is clearly an intersection approaching where vibe coding will be good enough for many purposes. Engineers frequently try to be like ‘bro your site won’t scale to 10000 users’ and guess what? Nobody cares, nobody.”

That’s the truth nobody wants to say out loud: 90% of the problems we solve in software don’t need to scale to 10,000 users. They just need to solve a problem today.

Think about it. How many internal tools, personal projects, niche apps, or small-business websites have died because someone told the builder they weren’t thinking big enough? How many ideas never shipped because the first answer was “use a proper framework” instead of “just make it work”?

Traditional software engineering has built a culture around perfectionism disguised as professionalism. It’s not about making things that work – it’s about making things that are architecturally pure, scalable, maintainable by a team of ten. But most software is never going to need that. It’s going to be used by a handful of people, solve a specific pain, and then either evolve or die. That’s fine.

Vibe coding doesn’t threaten the craft of building robust systems. It threatens the gatekeeping that has kept non-technical people from building at all. When you can describe what you want in plain language and get a working prototype in minutes, the person who spent years learning to architect a microservices backend suddenly has to justify why their solution is better – and often, for the problem at hand, it isn’t.

Engineers use ‘it won’t scale’ as a gatekeeping mechanism, ignoring that 90% of problems don’t need to scale to 10,000 users; they just need to solve a localized problem today.

This is not an argument against quality. It’s an argument against unnecessary quality. The perfect is the enemy of the done. And for years, the software industry has been the enemy of the done.

What vibe coding does is shift the bottleneck. It’s no longer about syntax or architecture. It’s about intent. Do you know what you want to build? Can you articulate it? That’s now the hard part. The rest is just conversation.

I’ve seen it firsthand. A marketing manager built a dashboard to track campaign performance in an afternoon. It’s ugly. It’s duct-taped together. It does exactly what she needs. The engineering team laughed at it. Then they realized it saved them three weeks of backlogged work.

That’s the new rule: good enough for the job is better than perfect for no one.

So the next time someone tells you your code won’t scale, ask them: “Does it need to?” If the answer is no, smile and keep building. The gatekeepers are losing their grip. And the world is better for it.