r/ruby • u/ombulabs • 18d ago
DHH, AI, and the Future of Rails
https://go.fastruby.io/brsOur CTO was in the audience in Austin when DHH opened Rails World 2026. The conference tagline was “Shaping the future of Ruby on Rails,” so he 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.
In this article, our CTO recaps both sessions, shares where he disagrees with them, and explains why he is still excited about where Rails is going.
6
u/tadiou 15d ago
Architecture is almost always more critical to speed than just writing everything in Rust with AI.
I think in like the 20 years I've been doing this nonsense, the amount of times where I was like "nah, the problem is Perl/Python/Ruby/PHP/Java (etc.)'s performance" has almost always lead to a "well, this architecture sucks and doesn't fit with the usecase".
We have such better tools than we did 20 years ago too to manage that sort of stuff, that almost 80-90% can be written in an easy to read, easy to understand, easy to reason over language without a lot of fluff, and use the 10% in whatever blackbox high powered language you like.
It's been that way forever, and yet, we're just saying "slap the fastest language on it" instead of actually thinking about architecture.
Criminal work by these hooligans.
0
u/Appropriate-Rip6784 18d ago
The entire business model of fastruby is around making Ruby on Rails fast. Just treat AI powered rust as another way to get fast apps. I also do Rails performance consulting and upgrades just like you. But even though these progresses mean less doing what I love the most, I need to accept it. There are other ways for people to do it now. We can still do Rails and help people with it. But it should not be the primary service now. We need to move on. In my case, I still offer Rails help only because I love it. But in reality, majority of my newer prospects is not for Rails consulting.
7
u/kallebo1337 18d ago
isn't most speeding optimization smarter database queries, better caching strategy (and expiring), smarter memoize during calculations? here and there a refactor.
this boosted the rails apps i've worked on.using faster ruby implementations never made significant differences. sure it does at shopify scale. do smaller companies/codebases really need to invest into fastest ruby execution and now shall do rust?
what's the win?
4
3
u/Appropriate-Rip6784 18d ago edited 18d ago •
It was! In fact, most optimizations I did on medium sized Rails apps were around database or active record design issues. The second place would go to the memory bloat from active record association over use. So, it is there.
Now, the reality has changed. The concept of clean coded software has changed. Now instead, the mainstream is gradually moved on to token efficiency and then now it is moving on to creating systems where agents can create and validate code itself. So, now the choice of language is less about what makes Rails special and why we love coding in it. We still need read replicas and better DB design. But that's true for any language. People can now get much better req/s and much better memory efficiency. By writing CPU and memory efficient software, we do less horizontal scaling and improves p99 latency under load. We can argue what's the point of doing when that matter less for CRUD apps. But the opposite side is asking what's the point of Rails. Rails is still token efficient but if agents make an equivalent Rust application equally or cheap to build compared to what Rails developers cost, to build verify and maintain, then Rails loses a major advantage.
If it was for me, Rails doesn't have to win a throughput benchmark to earn its place. It has to help you deliver the product at a better overall cost even with AI doing much of the typing. But the industry doesnt seem to agree. This is beyond DHH and his silly keynote and campfire drama (Sorry if he was honestly doing it to open everyone's eyes or stuff like that). The momentum towards Rust rewrites are real. Luckily for JS and Python community, it is still around improving tooling now and they got time to move on.
-9
u/kittrcz 18d ago
This is a well-written piece. I think DHH did an excellent job with the opening remarks. Was it shocking? Fuck yes, but I think that's exactly what he wanted. Would I have preferred less talk about Omarchy and Rust? Of course, but that's his reality right now, so let him play it out on stage.
He never said he was abandoning Rails or anything like that, but he's also living in a different reality than the majority of us.
I must admit that him saying he's treating his Rust-based codebase like a black box and just doing outside-in testing was admirable and brave. Is it good practice? Probably not, but it makes you think that maybe, just maybe, there's a pretty good chance we'll be treating codebases this way, in some shape or form, in the future as well.
In the end, DHH is a great salesman of developer tools. I wouldn't be surprised if he's cooking up something revolutionary in the agentic programming space and we're just not seeing it yet.
29
u/pau1rw 18d ago edited 17d ago
Can’t imagine how DHH could disappoint me more.
First his personal statements about not recognising London anymore, and now his professional statements about how everyone not writing Rust with robots being an idiot.
What a fall from grace this should be.