Does Ruby on Rails still make sense?

He left, my time freed up because claude, and I gave claude the directive of making an API to use with a Vite frontend so we can rebuild the UX carefully with user input along the way, and the end result will be running the monolith in parallel while users migrate to the new platform, monitoring, then phasing out the rails app. I'm skipping over a lot of the details, but so far so good, there's a light at the end of the tunnel.

If I was rebuilding the same app today, I'd still probably use rails as the API layer. The conventions are great, it's readable for when you need to read it... before AI the JS community was forever hunting for the "rails for node" and never got it. I think that says something.

Many solutions that seem obvious are less than so after a bit of prodding - but without that sort of discussion or pressure both humans and agents will often land on the thing that works first.

Where it tends to really matter these days are on the opinionated decisions... i.e. the trade-offs, things that can't be clearly validated etc.

So in the end I think we'll find that these sorts of frameworks etc. will continue to be, and possibly become more important - when your use case matches the intent and goals of the tool. This opinion differentiator is likely also the thing that combats the current issue of proliferation of quickly-built tools that more or less do the same thing.

I converted 3 of 4 apps running on a 4GB VPS to Loco (short for Locomotive: a Rust framework using the Rails conventions).

I am really happy with the switch.

Heaviest app went from 700MB of RAM usage at peak to 60MB and can handle 30x traffic before it hits an I/O wall.

I save 20$ a month because I downgraded my VPS to 2GB and am now able to fit new projects that sat underplayed on my personal machine because I couldn't fathom paying for a larger VPS. I could easily run 4x the amount of projects on half the system I used before.

As a Rails developer for 20 years this is a bittersweet moment. Rails was truly wonderful in its heyday and I could run circles around larger teams and do in a day what could take months for them. This advantage was eroded as people opted for Javascript frontends and then accelerated with graphql.

The advantages were then nullified with LLMs taking over code generation. With RAM prices tripling in 18 months I think the web framework that is hungriest just won't make any financial sense over other systems. The only reason I stayed with Rails was because of the conventions and my love for Ruby. I'm sad to being reading Rust instead of Ruby now but it's a drop in the bucket of my considerations.

I think the author pulls a bit of a bait and switch arguing for 'frameworks in general' rather than ruby or rails themselves.

The 'rust rewrite' approach is a non starter strawman, mostly because if you have a running company or project there's probably a shitton of dev experience you're inmediately burning, you introduce a ton of risk, etc.

But for new projects, I think the ruby (and rails) tradeoffs are looking a lot worse than 5 years ago. Placing developer experience at the forefront, arguably at the cost of other stuff, looks a lot worse as manual coding disappears. And conversely, automatic guarantees (type checking, etc) start looking a lot better when you don't need to manually add boilerplate.

I've been out of web dev for a while now and forgot these people exist. Why would you even compare framework with a language? Why would you want an AI to build a custom web framework around Rust? Why would you want to never read the code AI writes? It's infinitely easier for me to have a conversation with AI about something I know and understand.

The article barely has anything to do with RoR.

I realize (having been back and forth on this) that the answer is a very strong yes.

LLMs are based on language. The concepts/"nodes" LLMs tie together are useful because humans have created these nodes over the entire history of language, culture, and science. Humans naturally over millennia have been filtering out useful concepts from useless ones, refining language to efficiently carry meaning.

If we broke down all abstractions to fundamentals, there would be billions of things that would need to be tied together to make any useful product, almost impossible. Abstractions are required for solving problems efficiently. A high level abstraction that fits well in many solutions is insanely powerful.

LLMs are not immune to this effect, they need abstractions so that they don't have to prove every single thing they do from first principles, they can instead lean on language to shortcut a ton of thinking.

So when a framework gives you useful high level structure, patterns, and abstractions, you can do a lot less reasoning, and work a lot more efficiently, to solve a lot more problems. You could have one word (e.g. controller) mean a whole ton of useful things that you otherwise would've had to describe with multiple words. You could have references to existing concepts (e.g. `String#camelize`) that you no longer need to expand and define each time.

Bottom line, abstractions let LLMs solve problems faster, more correctly, with less reasoning.

P.S. Language is all abstractions, and we can solve problems well because we created these effective abstractions. The question I have about LLMs going forward is whether they can create new useful abstractions (new words, concepts, categories) that are actually time-tested and proven to contribute to good problem solving, without human input/verification.

Using frameworks and libraries in general still makes sense though, as it is chiefly concerned with code reuse.

I think the frameworks with strong batteries-included conventions also offer unique guardrails for agents building more ambitious apps. Those conventions allow for highly opinionated linters and well-worn migration paths, which become an eval advantage.

Eventually we will develop new languages and frameworks that are tailored to agents maintaining projects on epic time horizons. Until then, we can squeeze free evals out of these existing convention-laden technologies.

Instead of discussions about "my language/framework is better than your language/framework, see my TrustMeBro benchmark" - why not figure out what's next? Could we be working on the next set of patterns that are a level higher than OO design patterns like MVC, AR, etc.?

It's battle-tested, there are millions of lines of existing code using common patterns and libraries. It's still the gold standard for testability, with RSpec and factory_bot you'll have the nicest test setup with concise, human-friendly specs (especially if you're in the camp of verifying LLM work). Solid queue, cache, Active Storage with Turbo Frames give you all the benefits of single-page interactivity without the JS slop. Code size is a fraction of an equivalent JS setup, which is always nice for LLMs, went from close to 80k lines of JS to ~10k of Rails just recently on an internal project.

Historically, the main complaint was always "it's hard to hire for Rails" or "I don't know Ruby". But looking at the last 10 years of JS, I'm not sure the vast majority of JS slingers knew anything about Javascript either. And since everybody's vibing now anyway, why venture to the minefield that is the JS ecosystem.

Unrealted: As others have pointed out, the contents of the article are scoped broader than Rails. If we pursue that derail: Rust is still, in my opinion, not a better choice for web programming than Ruby nor Python. It's fine for small HTTP services, where there's a proliferation of (often-Tokio-based) Flask-like Frameworks. There is still a dearth of Django or Rails like ones, which I prefer for websites.

Why don't we have the AI output machine code binaries. Surely that's even better!

To be clear, I think this is ridiculous and I'll still use Ruby/Rails for web apps because it's tested, it works and I can read it without relying on a paid black box translator.

Once/if the paid black box becomes so good we no longer care, then it'd be stupid to force it to use an inefficient language just for the sake of it.

I stopped writing Ruby and Rails code in anger ~6 years ago. Change in jobs, roles, etc. and for my side projects I'm mostly tinkering in python and C, and zig appeals to me, but then so does PHP which was the most productive environment I ever encountered before Rails (and DHH has talked about this inspiring him too).

Things I think make sense for Rails in the LLM era:

- Convention over configuration. If somebody asks me to add some new business logic for the User object, even if I have never seen the code base before, I'm heading straight to `app/models/user.rb` and starting to read there. That's useful for an LLM, as much as it is for a user. And that's just the start of where conventions kick in. This aids explainability, and also allows us to easily check when an LLM is heading off into the weeds - "Why is all this logic in app/controllers?"

- It felt weird to me the first time somebody said "legacy Rails app" to me, because I got into it years before it was the new hot - I have to accept I'm just old now, fine. However, what that actually means is there is a lot of good battle-hardened code and documentation on how to get things done in Ruby on Rails, and that's going to help an LLM that's seen it all, and a lot of it can be distilled into specs and agents. Awesome.

- There's a decent ecosystem of people trying to make the entire space a little better all the time, both in Ruby, and in Rails. Frameworks do that - they attract people who care about developer experience, and making the picks and shovels better, and it's great to build on top of that.

- Ruby is beautiful to read, and reading is half of what an LLM does. Ruby has semantic denseness, but... see caveats below.

In the other column:

- While Ruby is easy to read to the human eye, some cause of that beauty is shared by the English language and what makes poetry possible: semantic ambiguity. Yes, I know there's optional static typing, I know that there are things to make this better, but an LLM will make mistakes, and I shouldn't have to explain why whatever has primary key of id "4" in that table is going to have unusual pressures, and why "no such X found with id 4" has a very specific and obvious route cause to me, that's going to confuse LLMs to know end (TLDR: when you cast `nil` to an integer in Ruby, it resolves to object_id of 4... yeah...)

- I'm not sure if the future isn't in unikernels where we take our logic and ship it without dependencies - without an OS - into kernels. That doesn't fit the Ruby/Rails mindset well. It could, but right now you're looking at a pretty standard 3-tier web app architecture that may or may not be the thing we want ever 2 years from now. Architectural innovation is likely going to be the big impact thing LLMs give us, not auto-completed code.

- I personally have a really serious problem with some of the community characters. Most of them, great. It went downhill a bit in 2010s - a sort of eternal September for a lot of us who pre-dated it - but I think it's fair to say DHH's politics are very, very far removed from my own, and I find comparing people of a specific ethnic origin to wolves who should be shot for the public good to be abhorrent and repugnant behaviour. I don't want to bring politics into technology choices, but he's already done that, and I don't like his politics - especially his misguided and ignorant views of the politics of my own country.

I'd write Ruby for money and fun again. I'd think twice about writing Rails for any purpose again. I think in 10 years it'll fizzle out, or I'll be doing the circuit propping stuff up LLMs haven't been able to replace yet like the COBOL guys do now.

But I think whatever replaces it as the force it was in the 2005-2015 era is going to be very exciting, and I'm not convinced it'll be entirely AI-based, no matter how optimistic the outlook is in that space.

Yes, the initial claim that good software still has value, even if written by humans, is true - high quality is always nice to have.

But the author then states this:

"The fact that an LLM now writes the code does not mean any abstractions we made before are suddenly less important or less useful."

Now - here the author makes a mistake that assumingly LLMs would lend benefit to the important of HUMAN written high quality software. But this makes no sense. If AI is really viable and useful then it SHOULD NOT NEED humans anywhere. Nor SHOULD it matter how much OTHER software that is good, exists - if AI works well. Perhaps current AI depends on existing data but I would not be surprised if AI becomes good, eventually, that it really does not need humans in order to write high quality code. Perhaps AI is not there yet, perhaps it will take a while - but there is no practical reason as to why LLMs would need human-written code. That just does not compute here.

"When we build a product for people we should be focused on solving their actual problems rather than writing job queues and ORMs and I believe that still holds true for a situation where an LLM writes 100 percent of the code."

But ... why? If a LLM can write the software well, humans are not needed. LLMs write for the people already. AI skynet replaced the human.

"To get back to the decision of whether to let LLMs rewrite everything in Rust: in the end a person is responsible for the software and will have to explain the decisions being made."

DHH was exposed on twitter when he had AI write software and then he crisitized alternatives to what he autogenerated, e. g. "elixir sucks". Well, now everyone knows that DHH is not a good programmer; and even not a good businessman either. If you let AI write code you yourself can not write because of lack of skills, yet then use this to praise AI and critisize e. g. Elixir, without being able to refute the counter-arguments made by José and others then sorry - that's just a promo campaign DHH and the AI tech bros run here. Besides, it is also interesting how the author does not mention DHH at all - DHH literally announced the death of rails when he did his AI-Rust promo. That is a post-mortem on Rails - if I were to use rails, which thankfully I don't (yet ruby powers all my web-needs and has so for +21 years), I would be very worried, since rails is literally dead. People just don't want to admit to it. (Ruby also is sinking, which is unfortunate, but looking at the mistakes made by the ruby core team in the last +2 years, I am no longer surprised: see https://po-ru.com/2026/10/18/why-im-no-longer-updating-this-... and then look at the ruby core team, which is now officially called Mr. Claude)

For that reason I would avoid it these days. MVC helps coordinated teams of people move faster on small to medium sized projects. It does this at the price of heavily coupling your front and backend. I believe rails couples the DB as well, or can? (Showing my ignorance of the Ruby world here)

We’re all developing with AI now. When things are coupled, AI breaks them. More than this though, with AI you want a completely decoupled frontend that knows nothing about the structure of the backend for maximum iteration speed. You want formal DTOs and other isolation abstractions small teams hate because they provide the decoupling that only large teams (or AI) benefit from.

Fully decoupled, you can build your frontend out on fake (AI generated) data, reworking the whole UI 12 times without thinking about the backend and database at all.

Rails (I’m speculating) makes small talented teams more effective. One person can do more. But if the price is coupling, and you have unlimited AI labor that will never be intimately familiar with the code, then you still pay that price without getting the human oriented benefits.