Concerns with his politics aside, I do think there's a truth to what he's talking about here, and that he is just spelling out the reality that developers are, or shortly will be, facing. For many this will be deeply uncomfortable to hear.
It is notable that his perspective in this talk is very much from a developer-user side rather than someone who is responsible for the framework itself. That surprises me, and I suspect it is not a good omen for Rails.
For all of this embrace of agentic development, there is nothing here on how they are adapting the framework for this new agentic development reality. Agents do currently work well with Rails, but there's nothing here pushing things forward as best as I can see.
I know for my own projects I've largely moved to Elixir/Phoenix, for similar reasons to his use of Rust... I didn't want to have to learn it, but now I don't have to and I get to benefit from its strengths.
Nothing that he said is just him espousing the truth. It is the world as he and all the other AI-pilled people wish it to be. It is a world they want to convince everyone is inevitable. There are still a lot of people outside of tech bubbles that don't like the direction AI is going and don't want to embrace what these companies are doing or how the government is handling it.
And honestly, do people really think everyone is just going to become an "energized creator"?
I think a lot of people haven't actually watched his talk and don't understand what he is saying. If you watch the talk, he is not anti-rails. He is just very pro- agentic coding.
What he was saying in his talk was that his customers (people using Hey for email and calendar) never really wanted hybrid web-native apps, they want native apps (like most people prefer on mobile). His business could never afford to have a dev team that built and supported six different native apps, so they always built using hybrid web-native stuff using Turbo Native.
Now that his development team has access to agentic coding, they can build and maintain six mobile native apps. For his app, the back end part then becomes small and simple and they can reimplement it in rust to reduce server cost.
His point wasn't that rust is better than ruby, or anything like that. His point was that agentic coding allows smaller teams to do bigger things. For most people building on rails, their customers don't need native mobile apps (I know mine don't) and for them Rails is a fantastic choice for agentic coding.
Rails is so into agentic coding that they publish benchmarks of how effective different models are for building with rails:
TLDR: DHH isn't anti-rails, he is pro-agentic coding. Rails is great with agentic coding. AI doesn't mean layoffs, it means your teams can do much more than they could do before.
> Rails is so into agentic coding that they publish benchmarks of how effective different models are for building with rails
To each their own, but I think using Rails in the era of agents is probably a mistake. It has 2 big problems IMO.
(a) A ton of footguns that an agent can and will miss on occasion, and as we manually review less and less code, we will also miss it, and
(b) security on the web has become increasingly important due to hostile AI agents, and while rails has great secure conventions (see (a)), it's still easier to screw up something and not catch it until after it's deployed because there are simply less guardrails in place (dynamic types, no compile, slow tests, generally bad performance profile).
> That surprises me, and I suspect it is not a good omen for Rails.
I had a fairly opposite reaction: Knowing what you can't be and how much less important your past work is going to be is good. If there are good reasons for more people doing less in Rails, then the creator is probably the person you want to be most level headed about that.
But he himself promotes such a future too. This is a conflict of interest.
You can say "ride the wave", but this is more - this is helping the wave become huge. And cashing in too. Sorry, but I no longer buy any of what these guys do. To me they seem like BigBro ad-clowns.
> Agents do currently work well with Rails
According to whom? And not everyone wants to become dependent on corporate-agents sucking them dry financially. We all know the increase-in-cost will come with regards to tokens, after the get-hook addiction phase is over.
I literally just patched an AI-generated API endpoint on a new service at work that shipped without any auth whatsoever, because AI was re-implementing the auth token check method individually in each child controller instead of implementing once in a before_action hook. That's Rails 101 stuff and the app is small. It was so obvious that I saw it right away just reading the code, I didn't even set an agent loose to do an initial inspection. It was a real "yeah I still got it" moment for me.
I'm on board with the idea that agents are going to write most of the code, but not checking it is just insane to me, based on some of the things I've seen committed in commercial codebases recently.
One of the strengths of Rails was that it helped developers who maybe didn't always know the "best way" to build things to build in a standards compliant way – not that you couldn't do things like return a 200 for Not Found if you really wanted to etc.
I'm always pleased when working with a dev who has Rails experience even if they've since moved stack, as often they have picked up and learned the value of these good behaviours. Perhaps it's as much a community thing as a framework thing, or combination of both.
Agentic development definitely still has room to improve, but I suspect that there is some future framework (maybe even language) designed to help minimise these types of mistakes.
Interesting that all the patterns Rails adopted for humans to write better code can't easily be funneled into the LLM doing the job now. Seems like it should be.
Types are great. No nulls are great. Exhaustive switches are great. Derive macros and Serde are great. Detailed errors are great.
However Rust has one serious problem, BUILDS. It’s slow and it takes up a ton of space and memory. You will be working around this on any sizeable codebase. Using cargo check to ration your compiles, a dedicated build box, etc. Now imagine you're using it for a web application with compiled maud templates... you're potentially waiting minutes to see your changes.
If we accept that over half of the people building with rust are using agents (I'm sure this is much higher in reality), then you should also accept that there is a ton of time and resources spent on building / compiling. Optimizing this should probably be a top priority. They need someone who will be fanatical about shaving time and memory use from the build process.
I think the issue with Rails, as a long time developer in that ecosystem, is that much of the default assumptions are a) not common (not so far off-piste that a human can't get used to them, but outside the center of the bell curve), and b) not explicit. So it's very common to do things like install a plugin that has across-the-repo effects but that is only documented in e.g. the config directory and the bundle. Unlike, say, NPM, when you install a new package where you explicitly have to e.g. import it everywhere you want to use it.
As time has gone on Rails has gotten better about this, but it still means that "your rails" and "my rails" are different enough that AI could easily get confused.
As you say, the other aspect is the intense dynamism which works against AI, which again prefers to have everything explicit and reasonable about from the text.
So I ended up going back to Javascript after a brief 12 year digression into Ruby. I still love Ruby but it's just not the right language for the current environment and team structures - typescript is "worse is better" in the right ways that it's a much better choice for both frontend/backend being the same and better type systems.
> Agentic development definitely still has room to improve, but I suspect that there is some future framework (maybe even language) designed to help minimise these types of mistakes.
Maybe there will be one day, but what are the odds that it will meaningfully move the needle for existing platforms such that manual code review is unnecessary? "Blindly trust the output" is not a feasible security posture today.
I sat front row for David's talk yesterday morning. Having talked with him the day before, I’ll admit… I wasn’t particularly surprised (nor unprepared).
A bit of a field report from #RailsWorld: the vibe here is far from doom and gloom. Quite the contrary. Wherever our industry is headed, most of us are still employed as menders… tending to systems that customers rely on and businesses are quite happy to keep paying for.
Most of us aren’t waking up to a blank canvas and designing the architecture of the future. We’re inheriting decisions made years ago, updating old patterns, working around constraints, and keeping this shit running reliably.
I think these newer tools give us an opportunity to wonder a little more about the systems we’ve inherited. To unpack why things work the way they do. To tinker with assumptions we haven’t had the time, confidence, or permission to revisit… and share what we learn so the next person, or agent, has an easier time.
That deployment model we picked eight years ago? Worth another look. Some of our web apps probably wish they were native apps. And there are plenty of architectural decisions we’ve been living with mostly because… well, we’ve been busy living with them.
There’s plenty of understandable anxiety about what these tools mean for our work. I’m increasingly curious about what they give us permission to revisit.
Once my keynote is published, I’ll share more about a little programming-language-adjacent framework I’ve been working on for approaching exactly this kind of curiosity.
How can Rails live long if no one creates new things with it? Our web applications aren't like the Pyramids at Giza. DHH literally said that even without a blank canvas (Hey's backend) they were still able to re-write the backend in Rust and are not looking back.
That sure sounds like any savvy business should pivot away from Rails and Ruby in general as fast as they can, assuming they have tokens to burn. Personally, I built my career on Python, but any new thing I build is almost always in Go or Rust. Why mess with an interpreter if you don't have to?
To be fair, this is true of most of AFK world. Things start seeing a lot less doomy and gloomy when you're actually outside talking with other humans. Seems to mostly be online and various darker corners where they're dooming and glooming.
the algorithm is programmed to deliver it. Better engagement metrics with misery and anger than joy and hopefulness. (yes I know that you will reply 'but I prefer the joy and hope', but that's not the case across the wider population)
Serious question: Is there a framework that is better suited for agents? There must be something out there that makes agents fly through development with minimal token expense.
I was hoping there will be news on Rails 9.0. Feels like this is the end of Ruby Rails.
Hey is not even a Ruby Rails App anymore. And indirectly admitting Ruby is slow considering they manage to cut 99.9% of CPU with their rewrite in Rust.
Unfortunately yes because Rails has always been a framework of extraction. Now they are not even coding anymore there is nothing to extract. No one is a programmer but everyone is a maker.
Those performance numbers mean nothing considering they went from rendering every single view of a highly interactive app solely on their servers to moving all rendering to the clients. It’s possible the backend logic of the app could have run on 10 hosts running Ruby as well.
I agree it seems like the end of Ruby on Rails. I personally hope a fork will come along as a spiritual successor, because I still love building web apps this way.
I hadn't connected the dots until you mentioned it, but yeah this keynote indirectly says it's the end of Ruby and Rails. Ruby was designed to be coded by humans, and DHH says it's the end of coding by hand.
I don't understand what is supposed to come next. So its not Ruby on Rails anymore. What is it? Are agents going to magically convert all the RoR ecosystem to Rust or Whatever?
But yes, I think RoR's selling feature was developer ergonomics, which suddenly seems less of a benefit if developers aren't the ones writing the code. Readability and conciseness still has benefit, but the trade-off of worse performance (and less static checking) is suddenly more questionable.
Shit, I'm also hosting with them. Somehow I missed that post. I've been watching Kurt's AI-pillness advancing over time, but I didn't expect it to metastasize so quickly.
What a strange time. Kurt himself writes that they've had the best quarter ever, and yet he feels confident enough to steer the ship in a completely new direction.
Where did he say that? I listened to it yesterday and AFAIK he only said "I don't know where the line between native vs web will end up in the future" (now that we can generate native apps easier)
Keep in mind DHH is working on an email app, it makes sense he sees native as the default option for that over pushing everything through the web.
Hotwire is not explicitly a cross-platform concept. It's primarily a way to build web apps in the browser which is not going away any time soon. The only difference is in 2026 you're just more likely to vibecode a native mobile app than build a web/React Native version. Likewise you may build a native Desktop version instead of an Electron wrapper.
DHH is a Spotify board member. Spotify is run by a snowboarder and sells the illusion that shops can be vibe coded by merchants.
DHH was against AI before 2024/2025 and is a gigantic sellout, just like the Ruby core people employed by Spotify.
DHH has only written web software and knows nothing about serious software development. He is a blowhard who even sells out his own framework for monetary gains.
I'm not here to defend DHH --- but I think "AI" has materially changed since 2024. I think that it's entirely reasonable to have shifted perspective on the technology and its applications since 2024.
>DHH has only written web software and knows nothing about serious software development.
I don't particularly like DHH either but web software is definitely serious. Shopify (which you seem to have confused with Spotify) runs on Rails. So does GitHub.
Those are both huge platforms handling a ton of traffic. If GitHub isn't "serious software" then what is?
Oh c'mon, there were three million ways you could express this feeling with some class... And you went for "can't even get the company names straight" ?
Reddit would have about 15 comments alluding without never revealing, all of them smart, classy and funny. The rest would be complete trash probably.
This keynote is from David Heinemeier Hansson (DHH) of 37Signals and the Rails core team, but it's actually more about AI coding than Rails and how 37Signals is adapting to this new technology. DHH and 37Signals are pretty famously anti-Venture Capitalist and Silicon Valley hype so they give an interesting unique perspective on tech trends. In the keynote, DHH believes the age of "hand coding" is over and what that means for our industry.
It is notable that his perspective in this talk is very much from a developer-user side rather than someone who is responsible for the framework itself. That surprises me, and I suspect it is not a good omen for Rails.
For all of this embrace of agentic development, there is nothing here on how they are adapting the framework for this new agentic development reality. Agents do currently work well with Rails, but there's nothing here pushing things forward as best as I can see.
I know for my own projects I've largely moved to Elixir/Phoenix, for similar reasons to his use of Rust... I didn't want to have to learn it, but now I don't have to and I get to benefit from its strengths.
And honestly, do people really think everyone is just going to become an "energized creator"?
What he was saying in his talk was that his customers (people using Hey for email and calendar) never really wanted hybrid web-native apps, they want native apps (like most people prefer on mobile). His business could never afford to have a dev team that built and supported six different native apps, so they always built using hybrid web-native stuff using Turbo Native.
Now that his development team has access to agentic coding, they can build and maintain six mobile native apps. For his app, the back end part then becomes small and simple and they can reimplement it in rust to reduce server cost.
His point wasn't that rust is better than ruby, or anything like that. His point was that agentic coding allows smaller teams to do bigger things. For most people building on rails, their customers don't need native mobile apps (I know mine don't) and for them Rails is a fantastic choice for agentic coding.
Rails is so into agentic coding that they publish benchmarks of how effective different models are for building with rails:
https://rubyonrails.org/ai
TLDR: DHH isn't anti-rails, he is pro-agentic coding. Rails is great with agentic coding. AI doesn't mean layoffs, it means your teams can do much more than they could do before.
To each their own, but I think using Rails in the era of agents is probably a mistake. It has 2 big problems IMO.
(a) A ton of footguns that an agent can and will miss on occasion, and as we manually review less and less code, we will also miss it, and
(b) security on the web has become increasingly important due to hostile AI agents, and while rails has great secure conventions (see (a)), it's still easier to screw up something and not catch it until after it's deployed because there are simply less guardrails in place (dynamic types, no compile, slow tests, generally bad performance profile).
He explicitly said he still loves ruby as a language and thinks Rails is well suited for a future with AI coding.
It's interesting how this stuff gets spun on social media by people who don't watch the content.
I had a fairly opposite reaction: Knowing what you can't be and how much less important your past work is going to be is good. If there are good reasons for more people doing less in Rails, then the creator is probably the person you want to be most level headed about that.
(They can, of course, still be wrong)
You can say "ride the wave", but this is more - this is helping the wave become huge. And cashing in too. Sorry, but I no longer buy any of what these guys do. To me they seem like BigBro ad-clowns.
> Agents do currently work well with Rails
According to whom? And not everyone wants to become dependent on corporate-agents sucking them dry financially. We all know the increase-in-cost will come with regards to tokens, after the get-hook addiction phase is over.
I'm on board with the idea that agents are going to write most of the code, but not checking it is just insane to me, based on some of the things I've seen committed in commercial codebases recently.
When designing systems, you want the important details to be right. Especially with authentication and authorization.
From an architecture level, you can know which classes are important to review and which ones are not.
I'm always pleased when working with a dev who has Rails experience even if they've since moved stack, as often they have picked up and learned the value of these good behaviours. Perhaps it's as much a community thing as a framework thing, or combination of both.
Agentic development definitely still has room to improve, but I suspect that there is some future framework (maybe even language) designed to help minimise these types of mistakes.
Is it types? Are types the answer? Is it rust?
However Rust has one serious problem, BUILDS. It’s slow and it takes up a ton of space and memory. You will be working around this on any sizeable codebase. Using cargo check to ration your compiles, a dedicated build box, etc. Now imagine you're using it for a web application with compiled maud templates... you're potentially waiting minutes to see your changes.
If we accept that over half of the people building with rust are using agents (I'm sure this is much higher in reality), then you should also accept that there is a ton of time and resources spent on building / compiling. Optimizing this should probably be a top priority. They need someone who will be fanatical about shaving time and memory use from the build process.
As time has gone on Rails has gotten better about this, but it still means that "your rails" and "my rails" are different enough that AI could easily get confused.
As you say, the other aspect is the intense dynamism which works against AI, which again prefers to have everything explicit and reasonable about from the text.
So I ended up going back to Javascript after a brief 12 year digression into Ruby. I still love Ruby but it's just not the right language for the current environment and team structures - typescript is "worse is better" in the right ways that it's a much better choice for both frontend/backend being the same and better type systems.
Maybe there will be one day, but what are the odds that it will meaningfully move the needle for existing platforms such that manual code review is unnecessary? "Blindly trust the output" is not a feasible security posture today.
A bit of a field report from #RailsWorld: the vibe here is far from doom and gloom. Quite the contrary. Wherever our industry is headed, most of us are still employed as menders… tending to systems that customers rely on and businesses are quite happy to keep paying for.
Most of us aren’t waking up to a blank canvas and designing the architecture of the future. We’re inheriting decisions made years ago, updating old patterns, working around constraints, and keeping this shit running reliably.
I think these newer tools give us an opportunity to wonder a little more about the systems we’ve inherited. To unpack why things work the way they do. To tinker with assumptions we haven’t had the time, confidence, or permission to revisit… and share what we learn so the next person, or agent, has an easier time.
That deployment model we picked eight years ago? Worth another look. Some of our web apps probably wish they were native apps. And there are plenty of architectural decisions we’ve been living with mostly because… well, we’ve been busy living with them.
There’s plenty of understandable anxiety about what these tools mean for our work. I’m increasingly curious about what they give us permission to revisit.
Once my keynote is published, I’ll share more about a little programming-language-adjacent framework I’ve been working on for approaching exactly this kind of curiosity.
In the meantime… keep showing up. Keep wondering.
Long live Ruby. Long live Rails.
p(bloom)
That sure sounds like any savvy business should pivot away from Rails and Ruby in general as fast as they can, assuming they have tokens to burn. Personally, I built my career on Python, but any new thing I build is almost always in Go or Rust. Why mess with an interpreter if you don't have to?
To be fair, this is true of most of AFK world. Things start seeing a lot less doomy and gloomy when you're actually outside talking with other humans. Seems to mostly be online and various darker corners where they're dooming and glooming.
Hey is not even a Ruby Rails App anymore. And indirectly admitting Ruby is slow considering they manage to cut 99.9% of CPU with their rewrite in Rust.
I agree it seems like the end of Ruby on Rails. I personally hope a fork will come along as a spiritual successor, because I still love building web apps this way.
But yes, I think RoR's selling feature was developer ergonomics, which suddenly seems less of a benefit if developers aren't the ones writing the code. Readability and conciseness still has benefit, but the trade-off of worse performance (and less static checking) is suddenly more questionable.
Have a look at fly.io facing similar issues, another platform whose value prop was dev ergonomics: https://fly.io/blog/kurt-scott-money-sprites/
What a strange time. Kurt himself writes that they've had the best quarter ever, and yet he feels confident enough to steer the ship in a completely new direction.
(I also smell the wild racism wafting off DHH. Really, don't give this man your attention. Don't break cordon.)
https://world.hey.com/dhh/as-i-remember-london-e7d38e64
dhh says 37signal's apps for Hey (their email platform moving to native)
backend for their email platform is now Rust - written by agents
says Rust produces small binaries - cutting number of servers needed from 110 to 10. hell they could serve peak traffic on a Raspberry Pi
says now that agents write all the code - use faster / native languages.
rails or ruby hardly get a mention besides that they might be well placed to capture web apps written by agents.
Keep in mind DHH is working on an email app, it makes sense he sees native as the default option for that over pushing everything through the web.
Hotwire is not explicitly a cross-platform concept. It's primarily a way to build web apps in the browser which is not going away any time soon. The only difference is in 2026 you're just more likely to vibecode a native mobile app than build a web/React Native version. Likewise you may build a native Desktop version instead of an Electron wrapper.
DHH was against AI before 2024/2025 and is a gigantic sellout, just like the Ruby core people employed by Spotify.
DHH has only written web software and knows nothing about serious software development. He is a blowhard who even sells out his own framework for monetary gains.
I don't particularly like DHH either but web software is definitely serious. Shopify (which you seem to have confused with Spotify) runs on Rails. So does GitHub.
Those are both huge platforms handling a ton of traffic. If GitHub isn't "serious software" then what is?
Reddit would have about 15 comments alluding without never revealing, all of them smart, classy and funny. The rest would be complete trash probably.