When Rails-way does not work anymore?

Rails hits a midlife crisis as commenters ask: is this really the framework’s fault

TLDR: The article argues that the usual Rails style can become painful as apps and teams get bigger, making change slower and riskier. Commenters pushed back hard, saying these problems happen in every software stack — and some joked the hottest bad take was the article’s casual faith in AI.

A fresh opinion piece arguing that the classic “Rails way” of building web apps starts to crack as companies grow did exactly what the internet loves most: it started a fight. The article says warning signs pile up slowly — new hires take forever to get productive, small updates feel scary, testing becomes a drag, and the business side can’t get simple answers about how the software actually works. In plain English, the author’s message is: what feels fast and fun early on can turn into a maze later.

But the comments? Absolutely not ready to let Rails take the blame quietly. One of the loudest reactions was aimed at the article’s claim that artificial intelligence tools obviously help developers. That line got roasted instantly, with one commenter mocking it as pure “axiomatic/dogma” and calling it a “Wild take ...” Others said the whole piece was pinning universal growing pains on the wrong villain. Their argument: every popular tool looks neat at first and messy once the codebase gets huge, so this is less a Rails scandal and more a software gets complicated scandal.

Then came the spicy counterpunch: some people said they’ve seen these exact disasters mostly in apps that weren’t even following the Rails style in the first place. One commenter basically sighed, isn’t the whole point of Rails… the Rails way? Another offered a peace treaty, saying the framework docs should maybe explain scaling tradeoffs better. So the vibe was less “Rails is doomed” and more “skill issue, architecture issue, or maybe article issue?”

Key Points

  • The article says the Rails-way is effective for many application types early on, but can become less suitable as business and codebase complexity grow.
  • It identifies organizational warning signs such as reduced developer confidence, slower delivery, weak AI adoption, difficult team splitting, long onboarding, and trouble explaining business rules.
  • It identifies technical warning signs including recurring database performance issues, slow and flaky test suites, unpredictable change impact, and duplicated business logic.
  • The article argues that these symptoms build up gradually and reduce a team’s ability to evolve the application as the business expands.
  • It attributes part of the problem to Rails models carrying multiple responsibilities, including database mapping, business logic, validations, and callback-driven lifecycle behavior.

Hottest takes

"The benefits are so obvious that they preclude any supporting evidence or research" — lbrito
"All of the growing pains listed in the article can be observed in pretty much any framework in any language" — goyozi
"The whole point of Ruby on Rails is the rails way?" — 3uler
Made with <3 by @siedrix and @shesho from CDMX. Powered by Forge&Hive.