What the Naysayers of Vibe Coding Are Getting Wrong

7 min read Original article ↗

The brick layers are angry again.

When someone spends two decades learning to write production-grade code by hand and then watches a non-engineer ship a working product in a weekend with English prompts, it’s understandable why the reaction is to lash out. The pushback takes a familiar shape: vibe-coded apps are buggy, insecure, unmaintainable, unscaleable.

We have run this play before. Twice that I can remember, and both times the people in front of the curve got called clowns by the people behind it.

I started my career building web applications in ColdFusion. ColdFusion was a tag-based language. You wrote it like HTML with a few extra verbs. If you could write <table>​, you could write <cfquery>​. Bolt a database to a website without learning CGI or Perl or anything that had a real syntax tree. The learning curve from a static HTML page to a real dynamic application was measured in days.

The CS-trained developers hated it. They had spent years on pointers, memory, threading models, build systems... ColdFusion let laypeople who hadn’t done any of that ship working web apps. The criticism was identical to today’s vibe-coding pile-on: the code is sloppy, the apps don’t scale, the security model is whatever the developer happened to think about that morning.

And some of that was on point. ColdFusion apps did get hacked. They didn’t always scale. There were sloppy ones because the bar had been lowered for who could write applications.

But net net the pie exploded. A whole generation of people with deep domain expertise and zero CS background suddenly had a way to build the application their job needed. Real estate agents, lawyers, school administrators, small-business owners. Software that never would have been written before now existed, served real people, and eventually needed real engineers to harden it once it mattered. The “bad apps” complaint was the visible cost. The invisible win was a much bigger software ecosystem.

Then we ran the playbook again.

Twitter launched on Ruby on Rails because Rails was what let two guys ship a working SMS-to-web service in two weeks. SXSW 2007 took it from 20,000 daily messages to 60,000 overnight. By 2008 the Fail Whale was a weekly regular occurrance. Eighty-four hours of downtime were logged that year. TechCrunch ran a piece literally titled “Twitter Said to Be Abandoning Ruby on Rails.” A Hacker News thread from May 2008 called the dev team “the biggest jackasses in history” for not having written it in Java or C++ from day one.

The critics weren’t altogether wrong in their criticism that Rails wasn’t ideal at Twitter’s eventual scale. But they were also completely missing the point.

If Twitter had been written in C++ from the start, there would have been no Twitter. The team would never have iterated fast enough to find product-market fit. The scaling problems happened because they shipped fast and people loved the thing. That’s the good problem. We should all be so lucky as to build something that generates such incredible demand that it has the fortunate problem of encountering scaling issues.

DHH put it best on Lex Friedman: Twitter was “the best advertisement ever for Rails... because nothing happened for 10 years after they switched over.” The eventual rewrite to Scala didn’t unlock new product innovation. It just shored up what Rails had enabled them to unearth and establish product-wise.

A single Twitter dev ported the message queue to Scala in his spare time and turned a 2.5-hour processing backlog into 20 seconds. That’s the punchline. The “wrong tool” was right enough to keep Twitter alive long enough for one engineer’s spare-time project to become the fix.

Both times, the priesthood got angry that someone had moved their cheese.

Both times, the bar lowered because a new tool let people who weren’t in the priesthood ship working software. Both times, the early output had real flaws. And both times, those flaws were the visible, narratable cost. The invisible benefit was a permanent expansion of who got to build.

Vibe coding is the third turn of this same wheel. People with deep domain expertise but no CS background can now build the application their work needs. Some of those apps will be buggy. Some will leak data. Some will fail. None of that contradicts the bigger point. The surface area of buildable software just got dramatically bigger. The amount of useful software in the world goes up. And with all this new surface area the amount of work for actual engineers (to harden, refactor, architect, secure) goes up too, not down.

Software engineering was never just code. It was code-writing plus architecture, taste, customer-extraction, judgment, the ability to look at a half-formed business idea and know which technical decisions you’ll regret in two years.

The code-writing piece is what got commoditized. A model can do bricklaying better than I can now. It cannot, yet, sit across from a customer and figure out what they truly need and translate that into a system that won’t fall over in eighteen months.

The profession of software engineering is evolving, not disappearing.

It’s just decoupling the brick-laying (science) from the architectural aspects (the art). Brick-laying is commoditized and solved at this point. But if anything the artful aspects are ever more in demand.

The engineers who are mad about this decoupling are mad because part of their job got easier and they’re worried their craft is now on the chopping block and will be valued less. The reverse is true. The architects, the taste-havers, the customer-whisperers, their work just became more leveraged. One good engineer can now own decisions that used to require five.

Adapt or cling to what once was. We’re witnessing a Darwinian transition in progress. The people who embrace the evolution of the craft are positioning themselves to capitalize on this disruption. The ones who spend the next year writing angry comments under HN threads are going to be replaced by the people they’re calling clowns.

The real risk isn’t building something that doesn’t scale.

It’s building nothing at all.

If a non-engineer vibe-codes an app that gets traction, generates revenue, creates real value for real people, then yes, they will eventually need to hire engineers to harden it. That is the good problem. That is the problem every founder I know would trade their morning coffee for. The gatekeeping impulse (you shouldn’t build software unless you can do it “properly”) is the same impulse that told Twitter to use Java in 2007 and ColdFusion users to learn Perl in 1996. Both times it was wrong. This time is no different.

This is the work, by the way. Vibecode Lisboa, Build School, Confabulator. This is exactly what we help people do. Take an idea, get it to a working prototype, ship it to real users, find out if it matters. The next great applications are going to come from people who weren’t supposed to be in the room.

The bricklayers can keep grumbling. The pie keeps growing.

Discussion about this post

Ready for more?