you can't sit with us

It spins up a working application out of almost nothing. A handful of keystrokes and you have models, controllers, endpoints, a running app. The people using it can't tell you what it generated. The real machinery sits behind a wall of magic they never have to look behind, and couldn't if they tried. The code is throwaway. It won't scale. It'll fall over the moment it meets real traffic. It lets people who never learned the fundamentals ship things that look like real software.

If you read that as the case against vibe coding, it's not. It's the case against Ruby on Rails in 2005. A framework whose killer feature was generating a functioning, database-backed app from a single command, and which spent its first few years ignoring a moral panic that it would manufacture amateurs, toys, and code that would collapse under the first real load.

Every tool that drops the barrier to building gets met the same way. "The code is bad, and the people are frauds, real engineers don't use that." It was said about Visual Basic. It was said about the bootcamp grads who skipped the CS degree, and the self-taught kids before them who learned off a forum and Demonoid (RIP Demonoid 😢). Today it's vibe-coders.

The critics are usually right about there being mess. Being right about the mess doesn't help you be right about what to do about it, or what it means.

what actually happened to rails

Rails won by moving the abstraction boundary. Convention over configuration meant you stopped thinking about wiring, boilerplate, and the SQL underneath, and thought about domain models and resources instead. Attention relocated one level up along with the abstraction. The canonical papercut is the N+1 query. ActiveRecord turns a database association into a property access, so user.posts inside a loop over a hundred users quietly fires a hundred and one separate database queries.

The response was never go back to hand-writing SQL. It was a decade of new craft built around the new failure. includes to eager-load, then runtime detectors to flag it, then strict_loading, which flips the default so an un-preloaded association raises. The judgment got encoded into a tool, and absorbed into the framework as a loud default. It migrated into the guardrail. The safe path became the path of least resistance. Nobody reasons about the assembly the compiler emits or the packets under an HTTP call. Most software rides on a wall of dependencies no one has read, and the system holds because the reasoning lives in the tools, not in a person.

everyone starts here

Anytime a technology is created to lower the barrier to entry, we have a swarm of new people discover software engineering, using the technology naively to leapfrog the milestones of everyone who came before.

A vibe coder has been writing software for a few hours and is already shipping things that (mostly) work. Strip away the tooling and you have the person software has always loved. The self-taught builder who doesn't know what they're doing, produces a tangle of shit at about the size of their competence, ignores architecture and scale, runs the thing hot until it breaks, scrambles to patch it, and makes enough money to hire someone who does know or just keeps figuring it out.

Everyone produces tangled shit at the start. Your code at two years is a mess. Libraries you couldn't explain, patterns you cargo-culted, a payments flow held together by a Stack Overflow answer from 2014 with a comment that says not sure why this works but it does. You become an engineer by creating the tangle and working through it. If you're lucky, you do it with help.

"Ships code they can't fully reason about" describes every engineer who ever lived, at the start. Frankly, it describes almost every engineer at the end. "Seems to work, don't fully get it, ship it" is not a new degenerate form of software engineering. It's a description of how software engineering is generally done. The whole craft of abstractions is the craft of enabling people to do things without needing them to know everything.

what's actually new

Something new did happen. It's not that the code is bad, or that its author can't explain it. We've handled both for decades. The new thing is volume. Every company just hired a hundred thousand interns. Tireless, fast, confident and wrong, with zero institutional context. The volume of output now flowing into codebases exceeds our ability to review it inefficiently.

This problem has been solved before. The big platform companies hired interns by the thousand straight out of university, kids who were confident and wrong about most things, loose, grabbing the first solution that occurred to them, with a limited understanding of security and architecture. They shipped anyway. They did it with internal frameworks, tooling, and libraries that made it hard to veer off-course. The decision space wasn't the entire universe of possible solutions. It was collapsed into a few generally-ok ones. That is why people could move between teams, and why those orgs could absorb new hires at scale. Everyone was moving in a harness.

You didn't need to care about everything. You end up reviewing a lot less than every single line. You can pattern-match quickly, because the number of decisions has been reduced to a few core paths. A senior engineer's real job was always this. Not to teach fifty thousand people a thing, but to make the thing not need teaching.

Libraries and frameworks are only part of the answer with LLMs. The solutions don't map one-to-one. But it's the same shape of problem. Guardrails that let you scale output without scaling effort.

what's not new

The pearl-clutching. The hand-wringing over the great unwashed masses doing "our thing." The catty insisting that they're not part of The Plastics and can't sit with us because on Wednesdays we wear pink. Very concerned about people confusing what they're doing as real engineering. Demanding people new to creating software front-load scary-sounding decisions like security, scale and architecture at a phase in their exploration and journey where it frankly just doesn't make sense, presumably to frighten them and put them in their place.

Some of it is legitimate, productive description of a new technology that has not had the time to develop best practices. Most of it is about making sure only the right sort of people, who go about it the right sort of way, wearing the right sort of clothes, with the right sort of hobbies, and the right sort of manner, feel welcome.

The vibe coder discourse is the bootcamp discourse is the Rails discourse. Instead of building guardrails, the energy goes into elaborate revenge fantasies of the AI-generated slop code getting haxxed, exploding and killing its authors because they weren't consulted for sign-off. Written by the quartile that always has an existential interest in the barrier to entry staying where it is.

Happily, the field's giants (Martin Fowler, Kent Beck, the usual crew) are building the guardrails, by anticipating the new challenges of a new technology and getting started, as they always have. Creation and gatekeeping pull on different temperaments. These are and have always been disjoint sets.

I am so excited for their work to settle and harden into the tools, and for more people to be able to build.