DHH, AI, and the Future of Rails
I was in the audience in Austin when DHH opened Rails World 2026. The conference tagline was “Shaping the future of Ruby on Rails,” so I walked in expecting to hear about the future of Rails.
That’s not quite what happened.
The opening keynote was almost entirely about AI agents. DHH told the room that 37signals has gone “pencils down” on writing code by hand, that HEY is moving to native apps with a Rust backend, and that he has retired as a professional programmer.
The next day, he sat down with Matz and Jeremy Daer for Ruby, Rails, and the future of programming , which went even further down the same path.
I’ll recap both sessions, share where I disagree with them, and explain why I’m still excited about where Rails is going. There is a lot going on behind the scenes to make Rails faster and more secure, and to give the view layer some much-needed attention.
The opening keynote
DHH’s biggest example of how 37signals works now was HEY. 37signals is rebuilding it as native apps, and rewriting the backend in Rust, a language DHH says he hates and is happy to never look at. According to him, the Rust backend needs 99% less CPU and 95% less memory.
Rails did get a few minutes.
DHH argued that convention over configuration and the “one person framework” idea are a great fit for agents, and that the web is still the right platform for applications that people won’t bother to install.
He also mentioned the agent evals that the Rails Foundation has been running (Henrique wrote about how to run the Rails agent benchmark yourself ).
The rest of the keynote was about Omarchy, his Linux distribution, plus two lines that got a lot of attention afterwards: that English is now a better programming language than Ruby, and that he has retired as a professional programmer.
Matz and DHH on stage
The panel was a more relaxed conversation, and it was the first time I heard Matz talk about how he works with agents. He said he has been coding with Claude Code since last November, and that he couldn’t have imagined that two years ago.
He also mentioned Spinel , an ahead-of-time compiler he started in March 2026 that turns Ruby into native binaries. He said that in their tests, a real-world program used about one twentieth of the memory.
Both of them made the case that Ruby still matters, even if humans write less of it. DHH called Ruby the best language for explaining concepts, so you could ask an agent to explain your Rust code to you in Ruby.
Matz mentioned that a colleague of his compared a set of languages and found Ruby, Python, and JavaScript to be among the most token-efficient, with static typing not helping much.
As we rely more on agents, the components underneath our apps (the Ruby interpreter, Rails, Linux, PostgreSQL) become invisible.
When people stop seeing them, they stop caring about who maintains them. He called that his biggest concern.
Where I disagree
I’m not going to start writing my backends in Rust because it’s more performant.
I understand the appeal of 99% less CPU, but for most Rails applications, raw performance is not the problem that justifies a rewrite. DHH said as much himself the next day, when he talked about most Rails applications fitting on a Raspberry Pi .
I still care deeply about programmer happiness. It’s one of the reasons Ruby and Rails exist, and I don’t think it stops mattering because an agent is writing most of the code. Someone still has to read that code, review it, and decide whether it’s good. I’d much rather that someone be reading Ruby.
I also want humans to understand what they ship to production. In his keynote, DHH said he treats his Rust code as a black box and judges it from the outside, the way a business owner judges software built by a team they hired. That might work for him, but it’s a big bet for a team that doesn’t have 37signals’ resources.
When things go wrong in production, I want a human there who understands the system, the programming language, and the framework.
At FastRuby.io, we have spent more than 60,000 hours upgrading Rails applications, and a big part of that work is understanding code that nobody on the current team remembers writing. Agents can help with that. But if nobody ever reads what they produce, we’re just creating more of that code, faster.
Mike Dalessio’s talk at Rails World made the same point. It took someone who deeply understood
Active Storage, libvips, and the attack surface to design Hot Cell .
That lines up with Matz’s concern: If nobody understands the components underneath our apps, nobody is going to maintain them either. AI can surely maintain these applications, but I don’t want it to be making judgment calls based on business needs.
Humans already have a hard time understanding the businesses and industries they work in. An agent only knows what you put in the prompt.
Rails 8.2 and who’s next
The Rails World tagline this year was “Shaping the future of Ruby on Rails.” For a lot of people, me included, that meant hearing about Rails itself.
Many of us expected Rails 8.2 to be released during Rails World, or soon after it. That didn’t happen, and as I write this, Rails 8.2 still isn’t out.
That’s not a complaint about the work going into it. There is a lot of it: Herb has already been merged into Rails core , and Hot Cell’s Active Storage gems are waiting on Rails 8.2 to ship.
But the opening keynote is the one moment each year when the creator of Rails has the whole community’s attention, and this year it went mostly to agents, Rust, and Omarchy.
Some people read that as DHH taking a step away from Rails to focus most of his time on Omarchy. He didn’t say that, and the next day he said he’ll keep starting his new web applications in Rails.
Still, it raises a question I’ve been thinking about since Austin:
If DHH were to pass the baton, who would pick it up?
The obvious candidates are already on Rails Core. Aaron Patterson closed the conference with an uplifting keynote on the as-if rule, Ractors, and AI , and has spent years working on the internals of both Ruby and Rails.
Eileen Alayce led a lot of the work that made Rails work for very large applications, like multiple database support. Rafael França has been one of the most active maintainers of Rails for years, doing much of the day-to-day work of reviewing and releasing it.
There are two clear developer experiences when using Rails: One where you’re building a new application with it, and another one where you’ve been running Rails in production for years.
Maybe Rails needs two leaders: One who cares deeply about DX for beginners and one for advanced users?
I don’t know who they would be, and maybe it wouldn’t be one person at all. But I’d love to hear more about the future of Rails from the people building it.
Why I’m still excited about Rails
The opening keynote was not about Rails, but a lot of the rest of the conference was, and that’s what I keep coming back to.
On the frontend, Jorge Manrubia introduced Lexxy , the new Lexical-based editor for Action Text. Marco Roth showed how Herb and ReActionView bring HTML-aware, reactive templates to Action View, with Herb on its way into Rails 8.2.
On security, Jenny Shen walked through the RubyGems Compact Index ,
the API behind every bundle install, and what features like cooldowns mean for the gems we depend on. Mike Dalessio showed
how Hot Cell sandboxes Active Storage after a critical CVE
that AI rediscovered in under an hour.
On performance, Aaron Patterson’s closing keynote on the as-if rule explained what Ractors change about thread safety in Ruby 4.1, and it also covered a real security incident on RubyGems.org. Andrew Novoselac used his experience at Shopify and AI to automate the path to Ractor-safety in Rails .
All of these talks were about making Rails apps easier to build, safer to run, and faster in production. That’s the future of Rails I’m excited about, and most of it is being built by people who still read the code their tools produce.
Conclusion
AI is changing how we build Rails applications (I’m using it every day too!), I just don’t think that means we stop caring about the language, the framework, or the people who maintain them.
Someone on your team still needs to understand your application when production breaks, and Ruby is still one of the most pleasant languages for doing that. ❤️
Is your team sitting on Rails code that nobody fully understands anymore, with more arriving every day? Talk to us.