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 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.
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).
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.
Using frameworks and libraries in general still makes sense though, as it is chiefly concerned with code reuse.
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.
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.
squidi•52m ago