We have a an aging rails monolith that gets cast aside whenever there's more important work to do, which is most of the last 8 years or so. The maintainer (my old boss) stopped deploying properly and there was code drift on prod.
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.
Off Topic: My crackpot theory is that Zero Interest Rate Policy (ZIRP) created an environment that allowed a lot of Not-Invented-Here programming to occur. (Sarcastically: “We here at Ackman shoes have realized a significant competitive advantage from developing our own in-house logging library.”)
Hah, good shout on the JS community side of things. Felt the same coming from Laravel land, and even the inverse problem - I started using Livewire for my frontends so I wouldn't have to manage JS frontend frameworks, but now that Claude can do it, the value prop of Livewire is much less to me.
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.
> 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
I agree I'd rather trust a project that execute 90% of community reviewed and tested code, and 10% LLM output, rather than 100% LLMs output. But at the same time, LLMs have a strong tendency to code as if frameworks are constraints rather than tools. They will pretend they use them, and then rewrite the entire handling of a get request to check the length of a user input rather than using your framework validation tools, giving you a false sense of confidence.
Framework and language upgrades are super annoying in ruby and rails. LLMs obviously make it easier, but a rails project can’t be “done” or you risk being so far back in versions that it becomes impossible to leap forward to the latest when you wanna fix a bug or add a feature.
This has been less and less true for a while now. The jump from 5-6 and forward have been pretty smooth for big projects I maintained. From 2-5 was quite painful... especially from 2 to 3.
I have a typescript app that launched February. It's regularly updated when there are bug reports, but I'm doing a big cleanup in prep for new marketing efforts.
I don't know how folks stayed on top of this ecosystem before LLMs. Rails was at least on a schedule.
If you’re not upgrading your deps and rebuilding your rust project this morning, you’re pretty likely exposed to eMudhra. If your project was “done” a few years ago that’s likely not going to be easy.
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.
>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.
On the other side I as the one checking the messy code my AI produces still prefer a highly readable code over something more "complicated" I would argue it's easier to catch bullshit even.
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
I don’t think dynamic languages like python/ruby/php (I know there have been improvements regarding type checking, still) should be used anymore in the face of ai-generated code. The advantages of these kind of languages are not as relevant as before
As long as frameworks and languages offer some novel eval to the agents, they’ll remain advantageous for certain projects. Rust is the most obvious case, giving the agent a borrow checker.
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.
> 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 would you want an AI to build a custom web framework around Rust?
Because it is blazingly and predictably fast with tiny memory footprint.
> Why would you want to never read the code AI writes?
Because it's Rust.
> It's infinitely easier for me to have a conversation with AI about something I know and understand.
That's why you tell the AI to build (or translate) a framework, rather than the app. Frameworks have shapes you know so it's easier to talk about them with AI.
> Because it is blazingly and predictably fast with tiny memory footprint.
My CRUD project management SaaS app that serves 100 clients doesn't need to be "blazingly, predictably fast with a tiny memory footprint", it just needs to work.
For like 95% of web applications, they probably could be ported to nearly any other web application tech stack with the tools we have now. We've been using HTTP GET|POST|PUT|DELETE for almost 30 years with HTML, CSS and JS on the frontend (with interludes of Flash, Java, etc. in clients). I think this AI hype cycle is going to lead to the tech industry spinning their wheels for a few years rewriting a bunch of things "just because I can" much like the industry spawned countless Javascript frameworks for a while (surprised we haven't seen more yet).
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.?
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.
Unless scale or resources are a concern, I see absolutely no reason to use anything else for CRUD apps. I sure as hell won't be writing any `sql` statements in nextjs anytime soon.
"The fact that an LLM now writes the code does not mean any abstractions we made before are suddenly less important or less useful." - I think maybe it does, we just don't know it yet.
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.
Whilst I have personally never had an issue with LLMs writing unsafe rust my comment was meant to be facetious. I dont't mean to disregard the fact that LLMs are easily powerful enough to reduce the need for large frameworks and libraries.
I do question how sensible it is to write everything from scratch for every project instead of relying on existing libraries with greater support.
With LLMs you can let your computer write the code and you no longer have to look at the code to get a working application.
Since you no longer have to look at the code, you no longer have to review the code either.
Since you do not have to review the code anymore, you don't have to look out for memory safety or security problems.
If you don't have to look at memory safety or security problems anymore then it's obvious that there is no difference between Rust and C.
I mean, what does Rust even give you? A type checking and borrow checking compiler that tells the LLM what it did wrong? Pah, I don't have to read compiler errors anymore so obviously that means the LLM doesn't have to do that either.
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.
Never personally liked Rails, but I see folks in my circles now convincing themselves they are 100x productive having Claude write web apps with no frameworks in whatever random combo of tech they chose. The end result looks like they should have just used Rails and done this in a few days instead of weeks or months of tokens.
In the age of AI where people are saying that it hard to understand or maintain the code that AI puts out, conventions are your savor. Rails has always been about any programmer looking at an existing application and getting a grasp on the code right away cause of the conventions. I feel that will become even more important in the future when people need to look at the code that AI is producing and understand or debug it.
This article has revealed my naive interpretation of Betteridge's law to be inaccurate. The law is unbroken here despite my initial reaction to the contrary; its subject isn't the naive boolean value of the question, but the broader intent of if the question disproves the underlying null hypothesis.
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.
I mean, if we're not gonna read any code ever again, who cares?
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'm not the author, but have been playing with it via agents. I like that it gives structure (like any framework), the resulting code is fast, but the compile times are getting on my nerves.
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.
He still runs a company with several services written in Rails with no obvious migration plans. AI psychosis and Linux side quests haven't, so far, changd that.
Background: I started the UK's first dedicated Ruby on Rails consultancy in Manchester, in the Summer of 2006 (called Vagueware - still love that name). I made this decision when Rails was at version 1.1.2. It was a bit of a brave call.
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)
I'm not really sure you understand what I meant with "abstractions" here. I definitely did not mean "human written abstractions". I am talking about all the abstractions in the software stack: application structure, frameworks, libraries, operating systems, programming languages. These are all abstractions that build on top of each other.
The question here is not whether we need human written code, it's whether we need abstractions. Perhaps I could have worded that better.
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.
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.
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.
Decoupling makes the isolated change easier while coordinating the change that affects multiple layers harder.
People used coupled frameworks to make the layer spanning changes easier. AI is not great at such changes either but it can put in the work to properly split the change it is trying to make into separate per-layer changes ahead of time. So I think in general you are right that for AI it's better to have things very decoupled.
It's still worth having things that ensure consistency on layer boundaries, like for example using backend types (dtos) to generate fronend types so incompatibility doesn't go undetected.
We have a an aging rails monolith that gets cast aside whenever there's more important work to do, which is most of the last 8 years or so. The maintainer (my old boss) stopped deploying properly and there was code drift on prod.
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.
Off Topic: My crackpot theory is that Zero Interest Rate Policy (ZIRP) created an environment that allowed a lot of Not-Invented-Here programming to occur. (Sarcastically: “We here at Ackman shoes have realized a significant competitive advantage from developing our own in-house logging library.”)
Hah, good shout on the JS community side of things. Felt the same coming from Laravel land, and even the inverse problem - I started using Livewire for my frontends so I wouldn't have to manage JS frontend frameworks, but now that Claude can do it, the value prop of Livewire is much less to me.
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.
> 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
I agree I'd rather trust a project that execute 90% of community reviewed and tested code, and 10% LLM output, rather than 100% LLMs output. But at the same time, LLMs have a strong tendency to code as if frameworks are constraints rather than tools. They will pretend they use them, and then rewrite the entire handling of a get request to check the length of a user input rather than using your framework validation tools, giving you a false sense of confidence.
I’m ex-ruby on rails dev.
Framework and language upgrades are super annoying in ruby and rails. LLMs obviously make it easier, but a rails project can’t be “done” or you risk being so far back in versions that it becomes impossible to leap forward to the latest when you wanna fix a bug or add a feature.
This has been less and less true for a while now. The jump from 5-6 and forward have been pretty smooth for big projects I maintained. From 2-5 was quite painful... especially from 2 to 3.
I have a typescript app that launched February. It's regularly updated when there are bug reports, but I'm doing a big cleanup in prep for new marketing efforts.
I don't know how folks stayed on top of this ecosystem before LLMs. Rails was at least on a schedule.
Is that really different from anything else?
If you’re not upgrading your deps and rebuilding your rust project this morning, you’re pretty likely exposed to eMudhra. If your project was “done” a few years ago that’s likely not going to be easy.
I went 4.2 -> 6 once and it was horrible. Everything since then has been easy. Upgrade struggl’n are simply no longer an issue.
You could say the same about any language or framework.
I wonder how all the old PHP apps are going to fare today, I hear there's a major security issue.
This hasn't been the case for years.
Rails developer for 20+ years.
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.
>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 agree. type checking is game changing for AI development.
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.
On the other side I as the one checking the messy code my AI produces still prefer a highly readable code over something more "complicated" I would argue it's easier to catch bullshit even.
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
I don’t think dynamic languages like python/ruby/php (I know there have been improvements regarding type checking, still) should be used anymore in the face of ai-generated code. The advantages of these kind of languages are not as relevant as before
One of the guiding principles of Python's design was "code is read much more often than it is written". Today, that's more true than ever.
As long as frameworks and languages offer some novel eval to the agents, they’ll remain advantageous for certain projects. Rust is the most obvious case, giving the agent a borrow checker.
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.
> 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 would you want an AI to build a custom web framework around Rust?
Because it is blazingly and predictably fast with tiny memory footprint.
> Why would you want to never read the code AI writes?
Because it's Rust.
> It's infinitely easier for me to have a conversation with AI about something I know and understand.
That's why you tell the AI to build (or translate) a framework, rather than the app. Frameworks have shapes you know so it's easier to talk about them with AI.
> Because it is blazingly and predictably fast with tiny memory footprint.
My CRUD project management SaaS app that serves 100 clients doesn't need to be "blazingly, predictably fast with a tiny memory footprint", it just needs to work.
This is premature optimization at its finest.
For like 95% of web applications, they probably could be ported to nearly any other web application tech stack with the tools we have now. We've been using HTTP GET|POST|PUT|DELETE for almost 30 years with HTML, CSS and JS on the frontend (with interludes of Flash, Java, etc. in clients). I think this AI hype cycle is going to lead to the tech industry spinning their wheels for a few years rewriting a bunch of things "just because I can" much like the industry spawned countless Javascript frameworks for a while (surprised we haven't seen more yet).
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.?
I feel like a good web framework with an orm - makes sense. Am I wrong here?
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.
Unless scale or resources are a concern, I see absolutely no reason to use anything else for CRUD apps. I sure as hell won't be writing any `sql` statements in nextjs anytime soon.
"The fact that an LLM now writes the code does not mean any abstractions we made before are suddenly less important or less useful." - I think maybe it does, we just don't know it yet.
Correct title: Do (web development) frameworks still make sense despite LLMs?
The article barely has anything to do with RoR.
The more I think about it, the less I can argue against "just have the LLM implement it in C".
Especially as LLMs already write stellar C.
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.
Neither actually, eventually they will achieve the 4 GL vision, and generate code directly.
It is already so that all Web based no code/low code tools have pivoted to LLMs, and agentic workflows.
When doing Web faced applications, it now possible to plug a bunch of SaaS and iPaaS platforms together, with zero traditional coding.
It doesn't seem to me like LLMs write stellar Rust, in fact it seems to be quite questionable and full of unsafes.
At that point, just write it in C and benefit from the faster toolchain and the more comprehensive suite of tools.
Whilst I have personally never had an issue with LLMs writing unsafe rust my comment was meant to be facetious. I dont't mean to disregard the fact that LLMs are easily powerful enough to reduce the need for large frameworks and libraries.
I do question how sensible it is to write everything from scratch for every project instead of relying on existing libraries with greater support.
With LLMs you can let your computer write the code and you no longer have to look at the code to get a working application.
Since you no longer have to look at the code, you no longer have to review the code either.
Since you do not have to review the code anymore, you don't have to look out for memory safety or security problems.
If you don't have to look at memory safety or security problems anymore then it's obvious that there is no difference between Rust and C.
I mean, what does Rust even give you? A type checking and borrow checking compiler that tells the LLM what it did wrong? Pah, I don't have to read compiler errors anymore so obviously that means the LLM doesn't have to do that either.
I'm surprised dhh hasn't vibe coded sometype of "convert Rails into Rust" open source project, given how pro-AI he is and how pro-Rust he is lately.
I just tell ma agents to drop a cgi-bin/ folder on my server and just perl it out. Who cares, I don't wanna look at the code. lol. just kidding :D
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.
Never personally liked Rails, but I see folks in my circles now convincing themselves they are 100x productive having Claude write web apps with no frameworks in whatever random combo of tech they chose. The end result looks like they should have just used Rails and done this in a few days instead of weeks or months of tokens.
Err yes, of course it does.
In the age of AI where people are saying that it hard to understand or maintain the code that AI puts out, conventions are your savor. Rails has always been about any programmer looking at an existing application and getting a grasp on the code right away cause of the conventions. I feel that will become even more important in the future when people need to look at the code that AI is producing and understand or debug it.
This article has revealed my naive interpretation of Betteridge's law to be inaccurate. The law is unbroken here despite my initial reaction to the contrary; its subject isn't the naive boolean value of the question, but the broader intent of if the question disproves the underlying null hypothesis.
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.
I mean, if we're not gonna read any code ever again, who cares?
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.
Did anyone try to rewrite Rails in Rust yet?
Yes actually - https://loco.rs/
I'm not the author, but have been playing with it via agents. I like that it gives structure (like any framework), the resulting code is fast, but the compile times are getting on my nerves.
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.
It's Rails, currently at version 8. I don't think it's going anywhere soon.
> a person who does not use it
He still runs a company with several services written in Rails with no obvious migration plans. AI psychosis and Linux side quests haven't, so far, changd that.
For low bandwidth and personal web sites, aka small and not hacker juicy targets, probabably depends on the user tech tastes more than anything else.
Did it ever?
Background: I started the UK's first dedicated Ruby on Rails consultancy in Manchester, in the Summer of 2006 (called Vagueware - still love that name). I made this decision when Rails was at version 1.1.2. It was a bit of a brave call.
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.
The article is not good in some areas.
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)
I'm not really sure you understand what I meant with "abstractions" here. I definitely did not mean "human written abstractions". I am talking about all the abstractions in the software stack: application structure, frameworks, libraries, operating systems, programming languages. These are all abstractions that build on top of each other.
The question here is not whether we need human written code, it's whether we need abstractions. Perhaps I could have worded that better.
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.
even dhh basically admitted that it was obsolete recently
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.
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.
You make some great points here.
I would say in an API-only context, we're seeing a lot of benefits in using RoR for the back-end and pairing it with Tanstack for the front-end.
Realistically, when/if it matters, we'll just port to a quicker language, which is now effortless.
But when you're in build mode, Rails is wonderfully ergonomic (for humans + AI).
Decoupling makes the isolated change easier while coordinating the change that affects multiple layers harder.
People used coupled frameworks to make the layer spanning changes easier. AI is not great at such changes either but it can put in the work to properly split the change it is trying to make into separate per-layer changes ahead of time. So I think in general you are right that for AI it's better to have things very decoupled.
It's still worth having things that ensure consistency on layer boundaries, like for example using backend types (dtos) to generate fronend types so incompatibility doesn't go undetected.