Why Ruby on Rails Mattered

I almost quit programming, and then Rails happened, and I didn’t. I’ve told that as a personal story, but there’s a bigger one underneath it, about how a tool can change not just how fast you build but who gets to build at all.

To feel why Rails landed the way it did, you have to remember what web development was just before it. Configuration files longer than the programs they configured. Boilerplate to connect a form to a database that took an afternoon and taught you nothing. A stack assembled from a dozen libraries that each had opinions and none of which agreed. The work was mostly plumbing, and the plumbing was where enthusiasm went to die. That’s the state I was in when I nearly walked away, and I don’t think I was unusual. I think the plumbing era quietly cost the industry a generation of people who would have been good at the interesting parts and never got to them.

Rails’ move was convention over configuration, and calling it a productivity feature undersells it. What it really did was delete decisions. Name things this way, put files there, and the framework assumes the rest. Which meant a person could hold a whole application in their head, and get an idea to running software in an evening instead of a fortnight. The felt experience wasn’t “I’m faster.” It was “I can see the whole thing again.”

That’s the same feeling I get now building solo with AI, and it’s not a coincidence. Both are tools that collapsed the distance between intent and working software. Both set off the same explosion of people building things, because the tax on starting fell through the floor. If you want to know what the AI moment feels like from inside and you were there in 2005, you already know. It feels like Rails.

Rails is why Intridea existed. We built a consultancy on it, riding the wave of startups that could suddenly afford to try, and I watched a generation of builders show up who would never have gotten past the plumbing era. That’s the point I care most about, more than the productivity numbers: tools don’t just make existing builders faster. They change the population of who builds. Every argument about whether the new tool makes “real” developers is an argument the incumbents always make and always lose.

Now the honest ledger, because nostalgia makes bad essays. Convention over configuration is a cage as well as a gift. The moment your problem doesn’t match the convention, the magic becomes the enemy, and Rails apps at scale hit walls that the framework’s early productivity had let them ignore. Worse, the very thing that let you skip decisions meant a lot of Rails developers never learned what those decisions were. The framework decided for them, so the understanding never formed, and that bill comes due the first time the framework’s answer is wrong.

That tension, between tools that empower by hiding complexity and the understanding that hiding erodes, is live again right now, at much higher stakes. AI doesn’t just hide the plumbing. It hides the programming. The Rails generation at least typed the code the conventions organized. The question of what the AI generation will have skipped, and what that costs them, is the same question Rails raised, run at a hundred times the scale. Which is the real reason this history is worth retelling rather than just fond.

Every era gets the tool that lowers its barrier, and every such tool is loved for the same reason and criticized for the same reason. Rails let me stay. What it also let me skip is a debt I’m honestly still not sure I fully paid.