I’ve never been a rails dev, but it popularized opinionated MVC, correct?
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.
I don't personally use Ruby on Rails, but there's a strong benefit from a framework or system that has been pressure tested in the real world with a lot of eyes on it - especially open-source ones that are the result of the accumulated judgement of many users.
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.
>The answer is simple: yes, I do think Ruby on Rails or frameworks in general still make sense. For the same reasons they always have: providing structure, not reinventing the wheel, security updates, free performance improvements and new features on updates to name a few benefits.
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’m not scared of code, but I agree: Rails does a good job at restricting reinventing the week. The Rails blog has been doing a great job giving guidance on getting best results with agents too: https://rubyonrails.org/2026/10/13/agents-on-rails-stage-3
> The implication being of course that writing code is now extremely cheap and you can build anything you like in any language, so why not choose to rewrite everything in Rust?
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.
Why use C when LLMs also write stellar rust? You're not giving up any performance and you gain a modern toolchain and a safer language.
And as a next step you could have the LLM write the code such that you can use it in multiple projects. Making the token spend even more worthwile. And then maybe you can package it for other people to use as well, since the LLM wrote such stellar code that it would be idiotic for anyone to use anything else.
Rails is slow, and it has little tooling. If it was me I would have used Go so that compiler would give the LLM some errors and narrow its error window, is way faster than Ruby and makes way more sense to have a way faster code than a slow one for the same price, everyone can read Go code and it is so narrow in the possible space of decisions that an LLM can never write usual spaghetti that it writes in other languages to save tokens... I think the problem is in looking at Rust as the alternative.
I'm not sure you could of made a worse point if you tried, to be honest.
Modern Rails is plenty quick (Ruby + Falcon is 2X faster than Python Async) and is incredibly ergonomic for LLMs as a codebase.
The tooling is also incredibly strong, with 200k~ Ruby gems in the ecosystem.
But ultimately, none of this matters. You can use any framework/language now and the LLMs can be productive on them all. Tools missing? Astra one shots it.
If you get to the scale where milliseconds result in $MM bills, then you port with another prompt, or just point more tokens at the bottleneck.
No and having strong opinions codified into patterns that an agent can utilize is exactly what we need today so, no not wrong and in fact, more needed than ever.
Only if you have to read the code, something that makes increasingly less sense as it seems like our job is increasingly putting more rails and tests, and reviewing code is just economically unfeasible, especially for 99.99% of projects out there.
No, it does not. The reasons are not technical though - the main reason is the project being led by a person who does not use it or in fact write any code, and on top of that is obviously not quite mentally stable. Depending on such a project brings too much risk.
Using frameworks and libraries in general still makes sense though, as it is chiefly concerned with code reuse.
DHH (somewhat experimentally) used agents to convert one rails app into a rust backend with 6 native frontends. The primary reason was speed on the backend and better UX on the front ends.
But he also said this doesn't make sense for every situation/application.
I think his approach could make sense for an established application with thorough test suite. But it will be interesting to see how maintenance and development goes since there's probably around 7x as much code to maintain now.
But for a new application? Surely just a rails app to start with and gauge popularity (as opposed to making native apps from day one, unless there's really good reason to, e.g. push notifications being absolutely essential).
He also got mad and started yelling at typescript and last time I checked, typescript was still relevant. What dhh built is larger than himself and he alone does not get to decide its relevance anymore. Stop paying attention to people who do this kind of hot takes for the sake of well, attention.
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)
LLMs are computers pretending to be human, even when their intelligence surpasses their originating species, why shouldn't they benefit from the same kind of structure and flexibility that ruby and rails provide?
Rails isn't dead yet or else I'd be surprised considering I write rails enterprise every day with LLMs who seem to do a perfectly fine job at writing the framework code and libraries. They're absolutely atrocious at testing. I'm also not particularly worried yet because my money making machine has no bottlenecks that dropping to a lower language would solve, and the loss of productivity for humans or LLMs by dropping to a lower level language would be staggering. Turns out monkeypatching in ruby is actually a huge benefit in the age of LLMs vs having to rewrite or fork everything if there's a bug or bad behavior by a lib.
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.
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 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.
And you can't duct tape your way into Ruby type checking and hope to beat the likes of C#, Java, Rust, Go. TypeScript.
Rails (and Ruby) made tradeoffs to please humans. Some of those tradeoffs became downsides now with AI.
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.
Especially as LLMs already write stellar C.
And as a next step you could have the LLM write the code such that you can use it in multiple projects. Making the token spend even more worthwile. And then maybe you can package it for other people to use as well, since the LLM wrote such stellar code that it would be idiotic for anyone to use anything else.
Modern Rails is plenty quick (Ruby + Falcon is 2X faster than Python Async) and is incredibly ergonomic for LLMs as a codebase.
The tooling is also incredibly strong, with 200k~ Ruby gems in the ecosystem.
But ultimately, none of this matters. You can use any framework/language now and the LLMs can be productive on them all. Tools missing? Astra one shots it.
If you get to the scale where milliseconds result in $MM bills, then you port with another prompt, or just point more tokens at the bottleneck.
Using frameworks and libraries in general still makes sense though, as it is chiefly concerned with code reuse.
But he also said this doesn't make sense for every situation/application.
I think his approach could make sense for an established application with thorough test suite. But it will be interesting to see how maintenance and development goes since there's probably around 7x as much code to maintain now.
But for a new application? Surely just a rails app to start with and gauge popularity (as opposed to making native apps from day one, unless there's really good reason to, e.g. push notifications being absolutely essential).
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)
Rails isn't dead yet or else I'd be surprised considering I write rails enterprise every day with LLMs who seem to do a perfectly fine job at writing the framework code and libraries. They're absolutely atrocious at testing. I'm also not particularly worried yet because my money making machine has no bottlenecks that dropping to a lower language would solve, and the loss of productivity for humans or LLMs by dropping to a lower level language would be staggering. Turns out monkeypatching in ruby is actually a huge benefit in the age of LLMs vs having to rewrite or fork everything if there's a bug or bad behavior by a lib.