Ruby on Rails Lost Its Superpower
Disclaimer: This post reflects my own opinions, not those of the company that pays me to write Ruby.
I have written Ruby for about 13 years, and I am grateful for every single one of them. Rails gave me a career. It taught me how to build products, not just write code, which is exactly why this argument is uncomfortable to make.
In 2005, Rails felt like cheating. I think that feeling is what is actually dying. Not because Rails stopped working (it didn’t), but because two foundational assumptions changed: first the user, and then the programmer.
The title is a provocation; the actual claim is narrower and much harder to dismiss. To understand why, we have to go back to the beginning.
The Cheat Code
In the early 2000s, the web development landscape looked very different. PHP made it possible to start quickly, but larger applications quickly became improvised. On the enterprise side, Java offered structure, but burdened you with application servers, XML files, configuration boilerplate, and a painful barrier to entry.
Spring Boot was almost a decade away. Showing a single page could easily take around 200 lines of configuration before a single user saw anything. You had to understand how half a dozen distinct layers fit together before rendering one useful screen.
Then Rails arrived with rails generate scaffold.
One command generated a model, a controller, views, database migrations, and routing. Refresh the browser, and there was your page. It appeared out of thin air. Crucially, Rails had been extracted from a real product: Basecamp. It felt as though someone had already built the plumbing of the software you wanted to create, stripped away the repetitive agony, and handed you the result.
Then came the famous 15-minute blog demonstration. That demo was not just documentation; it was product-led marketing before most of us had even heard the phrase. The product itself made the argument. You watched it and immediately thought: I can build something now. I have leverage.
Rails represented a different archetype of programmer. The culture around David Heinemeier Hansson (DHH) was opinionated, cinematic, and ambitious. He didn't sell the image of an academic disappearing into an enterprise architecture diagram; he framed programming as an expressive, creative endeavor. Later, he was literally racing sports cars. Rails felt like that personality turned into software.
You didn't need to be a mathematical genius. You could be a solo developer or two friends in an apartment, and your idea could compete with a corporate team. Rails gave you a technical edge, but more importantly, a productivity edge. Ruby was expressive. Rails compressed decisions. Convention over configuration meant you never had to rebuild the same plumbing twice.
That promise sold me too. In my early twenties, I studied sociology. I was a nerd about computers, but my early attempts with C++, PHP, and JavaScript stalled. Then I stumbled onto Rails. In three days, I worked through the entire tutorial building a Twitter clone from scratch. It introduced me to building web applications, set off my dream of building a startup, and ultimately launched my career as a software engineer.
Rails was never the king of raw efficiency. It wasn't the most performant framework, it could be heavy on memory, and running it on Windows was an adventure of its own. But Rails made a deliberate trade: human time over machine time, every time.
It prioritized beautiful Ruby, strong conventions, generators, ActiveRecord, and an integrated stack. You might spend more on servers later, but first you had to ship something worth scaling. When Twitter grew and ran into scaling bottlenecks, the early 2010s spawned the meme that "Rails doesn't scale." But the arrangement worked as intended: ship first, pay later. Twitter wouldn't have survived long enough to have scaling problems without Rails.
The deal made sense because developer attention was the scarce resource. Rails eliminated friction from that exact bottleneck.
Shift 1: The User (From Pages to Workspaces)
Rails and Gmail both debuted in 2004. They were solving different problems, but only one of those problems remains difficult today.
Rails made server-side application development dramatically simpler. Gmail showed that the browser could behave like a desktop application. It wasn't the first single-page application, but it proved at scale that web interfaces could feel fast, snappy, and continuous.
Over the following years, software evolved:
- Google Docs introduced real-time multi-user editing.
- Figma put multiple user cursors on a shared canvas.
- Linear built an issue tracker where every interaction responds with zero perceptible latency.
Try building any of those as a collection of server-rendered views. The web stopped being a network of pages stitched together with forms; the interface became a workspace.
A blog or a CMS is somewhere you visit, read, update, and leave. A workspace is an environment where you spend eight hours a day creating value. If you work inside an application all day, every small latency spike and disjointed state change grates on your focus.
Programmers often miss this because we live in the codebase. We inspect our clean models, hit an endpoint on localhost, click around for thirty seconds, and conclude the UX is fine. But users don't care about the elegance of a controller or our database abstractions. They care that their cognitive flow is never interrupted.
How an app felt to use started to matter more than how pleasant it was to build. Client-side frameworks grew because their architecture suited these applications. State moved into the interface, interactions became instantaneous, and components became modular. The UI was no longer a projection of the application; the UI was the application.
Rails did not ignore this shift. Over the years, we saw UJS, Turbolinks, and eventually Hotwire.
Hotwire is an ingenious design. It attempts to deliver snappy, application-like behavior without forcing teams to rewrite their systems into monolithic JavaScript codebases. The server continues rendering HTML, the browser swaps out only the mutated DOM fragments, and you retain a single domain model and language.
Hotwire works well for many applications. Keeping most of the logic on the server makes the client simpler. But offline support, complex drag-and-drop with local state, and optimistic updates (where the interface reacts before the server acknowledges) are still harder to build this way.
Shift 2: The Programmer (When the Machine Writes the Code)
The rise of AI changed both ends of the wire. The user is no longer solely a human navigating a browser; software is increasingly consumed via APIs by autonomous agents. And the programmer is no longer writing every line by hand.
Rails was designed under a reasonable 2004 premise: human beings would write the code. Humans would declare classes, memorize conventions, connect the pieces, and suffer the friction of boilerplate. Rails optimized around human fatigue:
- Ruby provided an expressive, flexible syntax.
- Metaprogramming compressed hundreds of repetitive lines.
- The integrated stack minimized setup overhead.
- Dynamic typing and implicit behaviors kept the code lightweight.
Look at how Rails positions itself today. In 2005, the headline pitch was "Programmer Happiness." Today, the official documentation argues that strong conventions prevent coding agents from generating an unmaintainable mess. Same framework, same conventions, entirely different customer.
When an AI agent writes the code, you no longer have to write the boilerplate yourself. A verbose language or rigid framework no longer slows you down when the agent is doing the typing. Static types, compiler errors, and explicit interfaces help agents catch their own mistakes.
The Rails community often argues that strong conventions make Rails an ideal target for agents, pointing to its identity as the "one-person framework." That is true, but it is an argument that Rails is a workable target for machines, not that it retains a unique advantage for humans.
Rails promised to make the developer's job easier. AI now does that across nearly every modern stack.
A solo engineer using an AI agent can build a full-stack application in TypeScript, Go, Elixir, or Rust just as quickly. Generating a scaffold in seconds used to be a superpower unique to Rails; today, any developer can prompt an agent and receive identical infrastructure in twenty seconds across any language.
The bottleneck has moved:
- From typing to specification
- From boilerplate to system architecture
- From memorizing syntax to checking correctness
Knowing what makes a good product, checking security, and understanding how the system works now matter far more than how few characters a framework requires to define an HTTP handler.
Intellectual Honesty
The trade-offs Rails made in 2004 made complete sense when developers had to write all that code themselves. But if humans are no longer writing every line manually, we no longer need to accept the same compromises.
Runtime performance, memory efficiency, and machine-verifiable static correctness matter. If the primary interface for instructing computers is becoming natural language, admitting this reality isn't a betrayal of Rails; it's intellectual honesty.
DHH himself once likened writing Ruby to the pleasure of riding a horse for leisure, even when you have a modern car parked in the garage. Ruby remains an expressive, delightful language, and I will continue to write it for the pure joy of it.
Loving a tool doesn't mean believing it must be the best choice forever. Rails taught an entire generation how to build products. But the advantage it gave us is now available in other stacks too.