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.
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.
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.
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.
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 when the barrier to entry lowered dramatically.
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.
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)
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.
(I also smell the wild racism wafting off DHH. Really, don't give this man your attention. Don't break cordon.)
Is it types? Are types the answer? Is it rust?
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.
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.
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.
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 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)
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.
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.
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).
Also, I hate native apps. FWIW most devs I know actively try to avoid them.
(1) https://www.uclawjournal.org/how-ai-destroys-institutions/
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.
And honestly, do people really think everyone is just going to become an "energized creator"?
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?
ksec•1d ago
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.
rramon•1d ago
an0malous•1d ago
fantasizr•19h ago
ksec•15h ago
stefanlindbohm•10h ago
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.