[00:00:02.17] - Robby
Welcome to On Rails, the podcast where we dig into the technical decisions behind building and maintaining production Ruby on Rails apps. I'm your host, Robby Russell, and I run Planet Argon. And for over 21 years, we've helped teams maintain and evolve their long-lived Rails apps. So I tend to approach these conversations through that lens. In this episode, I'm joined by David Heinemeier Hansson, the creator of Ruby on Rails and the co-owner of 37signals. We dig into how modern Rails has influenced the shape of Basecamp 5, whether ideas emerging from the new version of Basecamp might hint at future Rails features, how Agentic and AI-assisted development workflows are changing his own day-to-day development workflows and how their team collaborates, and what Rails might offer the next generation of builders entering software development through these AI-assisted tools. David joins us from Denmark. All right, check for your belongings, all aboard. David Heinemeier Hansen, welcome to On Rails.

[00:00:55.03] - DHH
Thank you. It's, uh, about time I got on the show, so I'm really happy to be here.

[00:00:59.09] - Robby
Welcome aboard. So, David, after all of these years, what still keeps you excited about Rails?

[00:01:06.08] - DHH
Well, at the core is Ruby as a programming language, whether I'm writing it or watching an agent do it, it remains the most beautiful programming language that I've ever laid eyes on. And that remains just a constant delight. It is just so much fun and satisfying to see code come to life, to see ideas come to life in code when that code is as beautiful as it is with Ruby. And then the other flip side of that is the internet. I continue to be a big fan of the internet for all its flaws. It's the best application platform that we've ever had as software developers. It's the one that allows us the most freedom to distribute our applications without gatekeepers as we have it on many other platforms. So that combination of Ruby, and then the internet, and putting those two things together and building great web applications remains just an incredibly compelling mission. And it's really not something I've gotten tired of. I mean, if you would've asked me 23 years ago, or whenever I got started here with Ruby on Rails, whether it was gonna last that long, I probably would've said, "No, I don't think so." But here we are on essentially the eve of another great revolution in computing with the AI.

[00:02:30.18] - DHH
Stuff, and it is as satisfying as it ever was. Again, as I say, whether I'm writing the code or an agent is, Ruby on Rails just remains a bliss to work with.

[00:02:41.05] - Robby
Are there parts of Rails today that feel more aligned with your original vision than you probably would've expected it to?

[00:02:48.21] - DHH
Yes. I have looked a few times at old Rails code through demos or otherwise. And if you look at some of those early videos, including the infamous look at all the things I'm not doing video I did back in 2005, I think it was, the shape of that code is eerily similar. If you look at those controllers, especially after we just made the transition to REST and the 7 actions, they really look quite similar. And even so with the models, I mean, ActiveRecord has maintained the core of its DSL since basically the beginning. And then it's gotten a lot more powerful, and we've added a lot more features, and we've sort of tweaked things and continued to polish it. But anyone looking at a Rails application from 20 years ago and comparing it to what we do today on the backend are gonna find things immensely recognizable. I think it's on the frontend that things have changed a fair bit. Now, I'm a staunch proponent of Hotwire and minimal build pipelines and all of this stuff that minimizes JavaScript. But even if you do all of those things, the frontend does look quite different than it did 20 years ago.

[00:04:01.12] - DHH
The backend, though, I think we got a lot of things really right from the get-go, and not just in Rails, but Ruby as well, that the core package has managed to reward people who invested in learning those DSLs, learning that language that long ago. If you look at the— churn life of most ecosystems, most frameworks, there's not a lot of dividends left over because you spend time with some JavaScript framework in 2009. Now, there are some general principles, and you can learn all those things, but you're not gonna be rewarded in the same way as if you really put in the time to understand ActiveRecord. Like, that was an investment you could amortize over literally 2 decades. And I think that's pretty unique, not just to have had that, longevity as we've had, but for all of those skills still to be extremely relevant, that there are enormous companies building on top of Ruby on Rails and Shopify and others. And then there's a whole host of new startups still being created with Ruby on Rails. There are ecosystems who kind of just, they do a cohort. They do a generational cohort and like that was a thing at that time.

[00:05:14.05] - DHH
And then those applications just move along. And of course, we have some of that too, but we also have a ton of fresh blood entering the veins of the Rails community all the time. And I think, especially again, as I said, now with the AI revolution, it's never been a better time to use Ruby on Rails. It's never been a better time to get the rewards of all that stability and polish that we put into these frameworks for so long. And just get all those benefits of the guardrails, of the conventions, of the insane amount of established code that has been written with these principles and can teach both human and agent developers to write better code.

[00:06:01.14] - Robby
So I'm definitely going to want to dig into the, the agent topic in a moment, but coincidentally, this week also coincides with when we're recording this that you've just released Basecamp 5. So I'm kind of curious, like, and congrats to you and the team on that, but cuz it does feel like a good opportunity to ask, like, what does modern Ruby on Rails make possible, let's say in Basecamp 5, that might have been really difficult to kind of envision doing maybe 7, 10 years ago with Rails?

[00:06:28.01] - DHH
That's a good question. Now Basecamp is of course the original Ruby on Rails application. This was actually the application that existed before Ruby on Rails. And I got started building that back in 2003. 3. And again, as I said, if you look at the backend of Basecamp 5, there are so many similarities to that first version of Basecamp. There's a few fewer SQL fragments. I don't actually know if we have any complete SQL statements in Basecamp 5. I almost don't think that we do. ActiveRecord has simply become so powerful that you no longer need to drop down to that level. But if you look at the overall architecture of it, I'd say it's more specific patterns like recordables, delegated types. That was one of the big shifts in how we build Basecamp, perhaps the biggest shift in terms of the internal organization of the code. But it's not that much of a Rails feature. Now we have delegated types and that, it's basically just there to nudge a certain architectural style. But is not dependent on Ruby on Rails and doesn't require a whole lot of plumbing for it. What is interesting is Rails keeping up with the evolution, not only of the underlying internet platform and making it possible for us to embrace things like passkeys.

[00:07:52.21] - DHH
That is actually a feature that we've been working on getting into Rails in a more proper form where it feels fully native, but also things like taking advantage of these incredibly powerful developer machines we have these days. Now, for a long time, the development machine was the slow bit, and then you'd go into server, and then you'd have the fast computer. And now that's kind of flipped around. The fastest CPUs in terms of single-core performance that you'll find, you'll find in developer machines. And you'll have a lot of those cores. I was actually just before this call doing some benchmarking, running the entire Basecamp 5 test suite on my local AMD 395 machine and contrasting that to one of the quite fast machines we have in the cloud that runs this stuff. And it was about twice as fast running it on the 16 physical cores I have in that AMD locally compared to 20 enterprise-grade, data center-grade cores in the cloud. Like, I could run that entire test suite in 60 seconds. And that's remarkable in its own right. But I think it also just enables a different way of working where so many of these auxiliary processes, whether they're CI, whether they're build pipeline, we've really been able to compress the complexity of it and that you can run an entire test suite for an application as large as Basecamp in 60 seconds on a modern computer, I just found astounding.

[00:09:21.01] - DHH
So a lot of the benefits that modern Rails are deriving today are coming from the fact that the hardware, it's gotten a lot better, it's gotten a lot faster, it's gotten a lot cheaper. The underlying internet platform has really seen a surge in its capability. Now, this is a couple years back, but the switch to no-build, the switch to having real modules in JavaScript that you can load and you can reference was a, was a big change and really changed how the front end of Basecamp was built compared to say the era of Webpacker 2015 to 2019 almost, there was a good number of years where the way we were building the frontend on Basecamp was not as enjoyable as the way we were building the backend. And eyes wide open, I knew at the time this was not the final form this was gonna take, but that was simply just what we had to work with. If you wanted to have a modern application, you simply just had to swallow these uncomfortable, cumbersome pipelines and building technologies. And then the fact that we've now arrived at a place where none of that stuff is necessary is truly a delight.

[00:10:35.18] - DHH
If I was otherwise to pick out any major feature, actually maybe another one, again, this is all future Rails features more so than present Rails features, but we implemented a brand new editor in Basecamp 5 built on top of Meta's lexical framework for building text editors called Lexi. That we're building into ActionText. And the power of that setup is really immense. We've wanted tables in the WYSIWYG editor in Basecamp for literally almost a decade. And we were using something called Trix before that we had built entirely in-house. And it was a wonderful text editor for the size of the box that it could interact with, and then it just couldn't be extended for certain things. The fact that we now have underpinnings that run Facebook, run WhatsApp, run literally platforms that billions of people are using, available with such ease in Basecamp, first of all, but also soon in Rails is another part of the real delight. Now, again, both of those two things, whether it's passkeys, whether it's the general build pipeline, whether it's lexical, a lot of that really is on the front end. And that just goes to what I was talking about earlier, that the backend has remained so delightfully stable that we're really chipping away at it now.

[00:11:58.09] - DHH
If you look at Rails development on GitHub with rails/rails, there are just constant commits going in every week, and you can do This Week in Rails, you can catch up on a lot of it. But so much of it is just polishing the nth degree of the nth edge case or something that people run into. Like, we're down to the 99.999% of coverage. And I think we should embrace that as an incredible achievement that we've managed to accumulate knowledge and implementation that's durable, that's stable, that's still enjoyable to work with. And maybe that more than anything is what I take away from modern development with Rails is when I look at the the entirety of the whole setup and how we work with it. I'm perfectly willing to throw it all out, throw it all in the bin if there was a better way. If I could look at some of this code and go, like, you know what, we're just doing this for legacy reasons. This was just because this was how it was once upon a time, and now we know better, so we should rip it all out. But whenever I know better, whenever I see better, I put it into Rails, and then it's there.

[00:13:07.02] - DHH
And These days, on that backend, there's not a lot of it. And I think that's just, it's glorious. And it's the success of the, what is it at this point, 6,000 or 7,000 contributors that we've had to the codebase of Rails over all these years. I mean, in some ways, it'd actually be weird if this wasn't what was happening, if we weren't accumulating all of this capacity and all of this goodness. It was able to be something we would build upon. But nonetheless, I think it is quite special. There's not a lot of frameworks like this.

[00:13:41.09] - Robby
There are not a lot of ecosystems like this that after 23 years can still say, "Yes, we'd love to build a greenfield application in this setup." I think something that I've always thought has been interesting about Ruby on Rails, and I don't know how to compare this enough to other frameworks out there, but A lot of us developers are working on projects that have been around for like Shopify. Their app's been in development for 20+ years, so they're not rewriting every few years a new version. Like I think in Ruby on Rails land, we get the benefit of 37signals releasing a new version of Basecamp and kind of reimagining the interface and how the application's gonna work for their users and your customers. So we get those gifts from you. I'm using your word gifts there, but we also get from Shopify. The things of just keeping the existing systems running and iterating on it. I would imagine a lot of people listening don't have the luxury of just rebuilding every few years and starting from scratch with the greenfield. Maybe they could, if they could figure out how to make that work for them.

[00:14:39.05] - Robby
But I think that's an interesting tension that we're trying to accommodate both. And I would imagine a lot of other frameworks are just keeping this, the things running that have, you've already made those commitments to keeping the framework kind of work, look and feel the same way for a long time. They can't do any major iteration things, but you can require everybody else to change everything to kind of fit into that. But I feel like Rails has, at least for the last several versions, has done a good job of finding a good way to balance that. Do you feel like that's been an intentional thing or is that just kind of the way things ended up being and that's part of its success so far?

[00:15:12.07] - DHH
I think it's one of the main benefits of our longevity and the, incredible early interest and engagement we got from the communities in those formative first, let's say, what is that gonna be, 5, 6 years of the framework, where we really did rip things out and change quite dramatically. Anyone old enough to remember the transition from Rails 2.3 to 3 will know exactly what I'm talking about. Those were some big open surgery moments on the framework. And it allowed us to get to a place where the foundation was just incredibly solid. Like, you're looking at this fucking tavern in the UK that's from 1284 and it's still standing. Well, it's not just still standing by accident. It's standing because it had a really solid foundation to do so on. There are plenty of things that would and have perished in such a time frame. So I think we got a lot of that high-churn inevitability, I would say, as you're learning what a framework should be and how it should work, out of the way in the early years. And as I talked about, the fact that the backend has been so stable and that we really haven't gotten any brand new paradigms in backend programming for a really long time has just given us this incredible stability where we have not had to give up the insights that could have made greenfield development work.

[00:16:50.16] - DHH
And I know this because we do both. Yeah. We have both codebases. In fact, Basecamp 5 is built on what we like to call the chassis of Basecamp 3. So that's code that got started in 2013, and Basecamp 5 is a major evolution, is quite the revamp of the whole UI and so forth, but it's been able to do that evolution on top of a codebase that's actually from 2013. And we have even older codebases than that. We continue to maintain the original version of Basecamp that was literally written in 2003. We still have thousands of customers using that original codebase even though we stopped selling it to new customers all the way back in 2010. Right. But at the same time, we also just released Fizzy, for example, a greenfield application that was built to the best standards we knew how with all of our best ideas and all our best talents of today. And if you look at that codebase, you look at Fizzy, it's public, so you can. You can't quite look at the Basecamp 5 codebase, but I can. And I get to compare them back and forth. And you know what?

[00:18:04.09] - DHH
They're not that different. So we really have been able to bridge this often very difficult chasm between staying stable for the Basecamps of the world, for the Shopifys of the world, for the literal million-plus other applications that's been built with Ruby on Rails over the many, many years, and then also make it enjoyable for new applications. Now, again, as I say that, it's not true on the frontend. And I don't quite feel like we can absorb the blame for that. The frontend ecosystem, JavaScript in particular, has gone through just an crazy amount of churn from, let's say, 2009, and then React came and peaked and dropped, and we've had a lot of other frameworks coming over those years. So I think if you're gonna carbon date an application, the easiest way to do that with a Rails application is just to look at, like, are they in Webpacker? Are they using esbuild? Are they using no-build? Is there some jQuery in there? What front-end framework did you use when this thing got started? Oftentimes, that's where you can tell. You cannot tell by opening a model file and looking at Active Record. There are little signs, there are little tells, and if you're a real connoisseur of the DSL and its evolution over time, you'll be able to spot it.

[00:19:24.23] - DHH
But I can open today models in the Basecamp codebase that would look absolutely right at home in Fizzy, even though Fizzy was just written 5 minutes ago.

[00:19:35.09] - Robby
Are there any things you think we can anticipate at Rails World, or if you don't wanna give away any teasers yet, things that might get extracted out of Basecamp 5's code base that you think, oh, this might be something we can share with the community?

[00:19:47.22] - DHH
Oh, for sure. I mean, I've already kind of teased 2 of them. Okay. One of them is a major upgrade to ActionText because we're gonna make Lexi, Both the default, also compatible with Trix. I mean, there are people who, including us, in applications still run Trix, and you should be able to run both, and you should be able to migrate and so forth. But leveling up ActionText in a big way because it's gonna ship with Lexi as its default, I think is gonna be huge. Rich text input is just one of those table stakes for almost anyone building a modern web application today. So one way or another, you're gonna have to solve this problem. And if Rails solves it for you in as comprehensive of a way as Lexi is able to do thanks to the Lexical underpinnings, I think that's gonna be a huge level up. Because Trix solved it really well for a subsection of people who were happy with the tools that Trix shipped with. And then there were just some glaring omissions. One of them was Markdown support. Another one was these tables, as we've talked about. And just those two things alone, for certain applications, were just deal breakers.

[00:20:56.09] - DHH
Like, well, I need to support this, Trix doesn't, I'm gonna have to roll my own, right? And that's just a useless time sink. So I think that's gonna be a huge level up. The other one, which there already is an open PR for, is to get Passkey support into Rails in a fully end-to-end way. Passkeys is something I've actually changed my opinion on. Partly because the first take I had on passkeys were that they were going to sort of replace passwords entirely. And I saw a lot of usability issues with that, that if you set up a passkey on, I don't know, your iPhone, and then you went to your Windows PC, suddenly you went like, oh, I can't log in. But the real breakthrough for me in my acceptance of passkeys was like, well, you know what? Standalone. And the technique we used in Fizzi was to pair them with Magic Links that you can always log in through your email. And I think, wow, that was really sort of a breakthrough that meant this is the right shape for most applications when they do authentication. They should simply just have Magic Links and Passkeys.

[00:22:04.14] - DHH
That's it. In fact, if you could get away from the social logins, even better. And I think that combination has a really good shot at doing that for the majority of developers out there. They can get away with something like that. And then we can solve a huge thorn, all of this complicated device stuff and whatever, the intimidation that a lot of developers frankly feel around authentication to the point that to me seems crazy, but that you would outsource authentication, not even the social login, like login with GitHub or login whatever, but you're gonna simply outsource your login to a SaaS provider. That always seemed crazy to me. But I accept that that came from developers looking at having to build it themselves. And for all the affordances we build into Rails, feeling still uncomfortable doing that. And I think passkeys and magic links are going to bring the floor down so low that everyone can play. And especially on passkeys, because passkeys are actually a really simple idea, but kind of subtle and a little bit tricky. To get the entire JavaScript dance done just right. And for the framework to accept the responsibility for doing that little bit delicate dance and tying it up into a really nice and easy to understand API that anyone can plug in on their login page, I think is gonna be a massive step forward.

[00:23:32.11] - DHH
We have a few other tricks up our sleeves for Rails that I'd like to get to, but those are the two that are already out in the open that I can't wait to polish up and wrap up and present as yet another batch of gifts at Rails World in September.

[00:23:50.10] - Robby
Are your logs full of deprecation warnings you've been ignoring since Rails 5? Meet Deprecation Whisperer. It reads your deprecations to you every morning in a soothing voice so you can start the day with just the right amount of guilt. Warning, this will change in the next release. You should update. Not today? Understood. Pick your mode: gentle, slightly concerned, or it's gonna break. And if you try to mute it, Deprecation Whisperer doesn't fight you. It just waits quietly until the warnings stop being warnings and become production. Deprecation Whisperer will nag you gently until something breaks.

[00:24:27.05] - DHH
May cause upgrading, sighing, and saying, "We should really tackle this," for 6 straight months.

[00:24:31.22] - Robby
And I don't know if this might be part of that TBD list that you might have there, but there have been a lot of conversations around providing access to agents in your application. So how does that then potentially work with passkeys and things like that if you're trying to have these agents that are going to spin up and have their own user accounts of some sort? Do you feel like there's an interesting thing we need to figure out from an architecture perspective right now?

[00:24:54.06] - DHH
I think there's definitely some interesting stuff to figure out. And I think it's not figured out at all. For a hot moment, everyone was all in on MCPs. That was how everything was going to be. And then— The puck kind of skated to CLIs for a variety of reasons. Now there's talk of having both in some regards. And I think a lot of this agent stuff is not only hugely exciting and hugely important, but also moving at a rate where we should be careful about pouring foundational framework concrete around certain applications until we have a clearer vision of what the final shape is going to be like. So I'm not in a rush in that field to really go like, oh, Rails has this. For example, if we had tried to bake in a default agents.md file and we had shipped that in the last version of Rails, holy crap, would that have been outdated now? I mean, we are what, 3 model jumps on since then? And any agents.md file that was written 3 model jumps ago is not only gonna be outdated, but it's literally gonna be harmful. To your agent's ability to do work at the best of its ability.

[00:26:02.23] - DHH
This is one of the curious revelations we've seen on some of the studies on Agents-MDFiles and other kinds of agent steering is that if you try to tell an agent to do something in a certain way that it already kind of knew how to get right, you actually make it dumber. You fill up the context window with distractions, and you get worse code. It really is one of those areas where it's just moving at lightning speed. It's a little bit like what was going on in JavaScript land, just on turbo steroids, right? That it's not about, like, getting a new JavaScript framework every 6 months. No, it's about getting a complete revelation of how we work with these things every 6 weeks, maybe even. I mean, a lot of people will pin even just last December as the pivotal inflection point where folks started giving agents the responsibility for writing the first code rather than doing autocomplete and cursor or Copilot or something like that. And then you've had even just these latest jumps I've been on about GPT-5.5, where I feel like it's a massive step forward. It feels like it's one of those Opus 4.5 moments where suddenly you just go like, my mind is blown.

[00:27:15.00] - DHH
The scope of the tasks I can delegate to the agents is much larger. The quality of the code I'm getting back is much better. I would not want to try to pin that down. I mean, it doesn't even work on a conference schedule. We have all the submissions now for Rails, and a lot of people are going to be talking about things where I don't know exactly what I'm going to be talking about. I have some of these things I want to be talking about, but I also want to make sure that what I'm addressing is timely to the moment. And at the moment, this industry is moving faster than it literally ever has since inception. And some of that is terribly exciting, some of it is also a little frightening, some a little intimidating, uh, hard to keep up with. And I think we have to find a way to be in both of those things, like both kind of, um, a little anxious, to be frank, about what does our industry look like 5 minutes from now.

[00:28:05.13] - Robby
Sure.

[00:28:05.21] - DHH
And what does the world look like 5 minutes from now? But also super excited that we're making computers do this. If you told me Even just when ChatGPT came out, oh, it was gonna write Rails code really well. It was gonna do super good on stimulus. It was just gonna be able to explain my own code to me that I hadn't looked at in a while in such fidelity that I would be left speechless, to be honest. I mean, about a handful of those experiences just in the last 2 weeks as we were working on wrapping up Basecamp 5. Where I go into some delicate, intricate part of especially the JavaScript setup. And we did a bunch of work, especially in the last sprint here to get keyboard accessibility really good. Oh, you can jump back and forth between the sidebar. I wanted to get this almost NeoVim-like interaction with Basecamp. And it actually requires a lot to get all those focuses just right. And I spend a lot of time with GPT-5.5 on this problem. And I kept just being like, How? And the big how was not even just that it could write a good implementation, though it could, still needed steering, it still produced a bunch of things I wasn't happy about in the first go.

[00:29:17.19] - DHH
But the fact that it could do something, and I could then ask it, "Why is this necessary? Why do you need that?" I mean, I would often approach it with a high degree of skepticism. This looks like too much code. And it would walk me through the edge cases and timing problems if we didn't do it that way, and if we didn't request a frame first, and all the other things. And that's a computer doing that. That's a bunch of sand we smashed into silicon and we make chips out of it by burning a little laser at minuscule degrees. It's just, it's so mind-blowing for anyone who likes computers. And I love computers. I mean, this is one of the reasons why I'm still programming because that feels like the direct connection that you have with the computer. And now we're getting this other direct connection with the computer. Through AI. That's just terribly, terribly exciting. So again, I know there are people going to be hearing this and are still sitting on the more skeptical part of the swing here of hyper enthusiasm versus mega skepticism. And I sit on that swing too on at least a weekly basis where I go like, oh my God, everything is amazing.

[00:30:22.06] - DHH
And then the agent will do something completely retarded and I go like, this is so stupid. If I just let it loose, it was going to blow everything up. Which actually maybe is a good transition to some of the ways we've been working and how they've been changing around Basecamp 5. Because one of the big changes in our workflow is the ability of designers and project managers to now write Rails code, write Ruby code, see their thoughts getting transformed into working software without going through the mediation of a programmer. And first of all, I think that's incredible, incredible that we're giving someone who is tasked with finding out how something should work the power to test those hypotheses, to validate their intuition all on their own. That being said, we are not yet at the place where anything that's literally vibe-coded in perhaps the most fundamental sense of that word, I mean, code is being produced that's not being understood or maybe even reviewed in the detail level. We're not merging those things in many, many cases. In most cases, those things are not getting merged. But we're arriving at one of the hardest parts in software so much quicker.

[00:31:40.08] - DHH
How should this work? If we make it work this way, is it good? Is it fun? Is it productive? Does it feel right? Getting those questions answered so much earlier in the process without wasting the time of a programmer for, in cases, weeks or even months is just truly incredible. And I say that as someone who's written a lot of code that got thrown out. Especially in the early days with Jason, he'd ask me to build something in Basecamp, and I would diligently spend a week or two on it, and I'd be so proud of my implementation. And then I'd show it to him, And he'd go like, "Yeah, that's nice, but it doesn't work. It doesn't work. It's got to work this way instead." And I'd just be like, "What? What do you mean? What do you mean? What do you mean? I've just been spending so much time implementing it. I'm kind of married to this piece of code now." Now, I know you're not supposed to be that, but that's just a human reaction when you've invested a lot of blood, sweat, and tears into things. So, the fact that we're being relieved of a substantial part of that Coding in Vain to me feels like a huge step forward.

[00:32:44.08] - DHH
Now, again, as I said, that does not mean that Jason could just vibe code all of Basecamp by himself, at least not yet. Maybe that day will come, but it's not today. It does mean that we can take some of that stuff out and therefore shrinking the process. Like Shape Up, for example, the software methodology that we've promoted and used at 37signals for a very long time, has some assumptions about how long it takes to do an implementation of a major feature that are just no longer valid. Shape Up is built around the 6-week cycle because that was the correct timeframe for building things at Basecamp. That now seems kind of archaic. I have a hard time imagining that almost anything we can come up with, almost any feature we can come up with in Basecamp would require 6 weeks to implement. And that's not just in Basecamp, that's in all parts of software I'm touching, whether that's Omachi or other things that I'm working on. We have really compressed things in a major way, but you still have to pay attention to the quality. You can still wreck a carefully constructed architecture in surprisingly short time because you can produce a lot of code in short time.

[00:33:56.08] - DHH
And if you just naively ask the agent for something, it'll give it to you. I mean, that's the monkey hand curse. It will give you anything you ask for, even if that thing should not be delivered the way it is. I don't feel like the agents, at least yet, are good at what Kent Beck used to talk about, make the change easy, then make the easy change. Because agents can make very hard changes, and it's perfectly happy writing 1,200 lines of code on something when an architectural twist Rails could have reduced that to 20 lines of code. And I think that's foundational to the longevity of good code bases is that they have an architecture that is considered, that is malleable and twistable and will change when new requirements come in that cannot be delivered within the current framework, that they're not just bolted on. And I do feel at the moment agents are eager to please as quickly as possible in as few tokens as possible., and that can lead to kind of bolt-on. Now, as I say, that is also how most software development has been done by humans for a very long time.

[00:35:04.05] - DHH
A lot of codebases turned into a ball of mud over a surprisingly short period of time when the original architects left or pressures came in and there was no longer time to refactor, there was no longer time to clean up. So I do think whatever hesitation I'm expressing around agents are really just hesitations about software development without care towards architecture, without care towards style, and beauty, and all the other things that continue to power my engagement with software development all these years. You really do have to remain committed to those values, at least if you're trying to build a large system that is not turning into a game of whack-a-mole in 2 seconds where you add 1 new feature and then you create 3 other bugs, I don't find that particularly enjoyable. And I think there are a lot of vibe coding adventurers who found exactly that situation being quite sticky and almost impossible to get out of if you just let them run loose and there's no red thread. Again, we may be one model turn away from that no longer being the case. I've been surprised a lot of times in the past year, in particular, and had to 180 my perceptions of how I use these systems.

[00:36:21.05] - DHH
But today that's not the case, perhaps thankfully, right? Then we're still needed, us squishy humans here who know and love computers, that we still have value to add to the system. Um, so anyway, now, uh, see, now, now I'm, I'm almost like the AI. I've just let the conversation just sort of drift down into some corner where I don't even remember the—

[00:36:41.02] - Robby
Well, I, I think the, the thing that I've been ruminating about is, and I think about people like you, people like me maybe run organizations and we have a little bit more leeway to experiment as we want with these new tools and we can like, oh, we'll work on this in the projects, but not all of our, let's say, employees feel like they have the same level of freedom to experiment because they've got to ship things. And so how do you feel like you're using AI versus maybe people on your team might be using AI in their day-to-day development?

[00:37:12.06] - DHH
I would say that good programmers always make time to experiment. They always make time to learn. They always take time to adopt newer, better technologies. And I think in the Ruby on Rails world, we've attracted a gang of people, by and large, I mean, there's a lot of different people and they come in all different shapes and sizes of curiosities and so forth. But if I were to characterize as a whole, I would certainly characterize Ruby programmers as curious. As eager to learn, as eager to squeeze out productivity gains and just satisfaction out of their work. And I think those are the attributes you need for this new AI world and to make the transition. Again, I was proudly a year ago going on podcast saying like, I love just writing all my code by hand because I wanna sweat every single character. And I still wanna sweat every single character in terms of its esthetic presentation. But I flipped on the fact of whether I need to chisel that code myself or not. If I can get an agent to produce code for me that is of the same quality as what I would have written by myself, well, obviously the game has changed, right?

[00:38:17.23] - DHH
So I do actually think it is a professional obligation of every programmer to take this revolution seriously, to dedicate time to coming up to speed on it. To learn where it's not still there, to get excited when it dazzles you, to not be stuck in these distracting ideological dead ends, like it's just a parrot, it's just regurgitating stuff, it's not actually thinking. Whatever your thoughts on that is, you are missing the big picture if you simply to acknowledge the reality, which is that these tools are incredibly powerful and that you need to embrace them and you need to learn them. So I'd say if I look at 37signals, the best people are embracing this full on. And I mean, we're great people. Some of it is a bit about timeline. Some people are just more naturally curious and will occasionally spend a weekend on some of this stuff just to experiment and and find out. But some of it is also just having an organizational license I do think is important. I took longer than others have. I mean, if I look at Tobi over at Shopify, he clearly saw the future earlier than I did and was very forthright within Shopify to mandate actually that you need to pay attention to this before both the industry at large has caught up, before I had caught up, before a lot of people had caught up.

[00:39:50.16] - DHH
But Now I do feel like I've finally taken the topi pill on AI acceleration, as have most other people that I interact with and pay attention to. I feel like the holdouts who will staunchly just be stuck in whatever the parrot thing or other of these dead ends, it's rapidly shrinking. Now, I actually have respect for that. I was there not that long ago. Thinking like, you know what, this is a wonderful piece of technology, but I still want to write all my code by hand. So it's not like I begrudge anyone whatever to hold on to that. If you are exceptionally productive and talented and able to do all those things without AI acceleration, first of all, kudos to you. I am not— I was not that good. I'm so much better now. AI agent accelerated me is so much more productive, able to solve more problems just way faster and explore more ideas. I think that's perhaps the other part of this whole transition that has been such a surprising delight to me because I like code so much, because I like implementation so much. I wanna see a lot of them. It's a little bit like, like art.

[00:41:03.21] - DHH
Like I can look at a lot of different Bart pieces and then go like, I don't like it. I don't like it. I don't like it. I don't like it. I look at a thousand things and then I'll find like one piece. I mean, I love it. This is the best thing ever. I need to be looking at this. I need to be taking that in. And I feel a little bit the same thing occasionally about code. I need to see 7 different implementations of something before I'm like, I don't like that shape. I don't like how that was structured. And with agent acceleration, it's so cheap to just go like, I don't like what you made. Bam, git reset. And now it's gone. And I don't feel bad about it. I don't feel bad at all about flushing 1,000 lines of code down the toilet because I know these agents will happily charge me for the tokens to build another implementation on it. And it just allows you to see more things and to experiment with more ideas without having the cost of implementation be so heavy that it deters you from following your intuition, following your creativity.

[00:42:00.15] - DHH
So I do think that this is something that people should be taking very seriously, obviously. And I don't think there are a lot of people left who don't take it seriously. They may not like it fully, or they may feel uncomfortable about where it's going to lead and all the other things, but we are all taking it seriously now, as we should. And then it's just a professional obligation to stay on top. And I say that as someone who watched other revolutions in our industry kind of swallow some people who didn't get with the times. The internet is obviously a main Stay one. I knew a lot of programmers in even late '90s who were quite negative on the internet, quite negative on the idea of web applications. Remember what they used to call people just working with the web? It was script kiddies. That was one of the things that was said about PHP programming in particular in those old days. Well, do you know what? I learned to be a programmer through PHP. I learned as a script kiddie to get into all this stuff. And then it was mobile apps, right? Like early mobile apps, they were sort of slow and cumbersome and kind of crap.

[00:43:06.10] - DHH
Is anyone seriously thinking that's not a sort of serious part of our business? Of course they're not, right? So some of it is just when you have these big revolutions, it's a difficult moment of transition. Not everyone gets on with it as evenly and as easily as others, but By the time it's over, I think it's just quite clear that, like, for example, if you were holding the fort on, like, we shouldn't use the internet or something, right? Like, probably it'd be a little hard to be a professional programmer. Now, you can build your own business making bespoke, uh, assembler software or something where you don't need the internet, and then— and I would cheer you on. That's not where the economy is. And if you want to have a job being employed by other people, I do think it pays to pay attention. Now, some things, some changes, they don't all pan out the same way. Like, if you were really into NFTs, for example, and building infrastructure about that, and I don't know, bro. Yeah, like, that one didn't pan out, right? But so what? So what? Um, not every idea that this industry has is going to go on the shelf and last forever, right?

[00:44:16.03] - DHH
In fact, if they all did, we weren't trying enough ideas. But I do think it's quite clear at this point that AI is, is one of the big ones, maybe even the biggest one.

[00:44:27.07] - Robby
I think I'm— one of the things I've— with these people I've talked to, I feel like a lot of organizations are— it's not that they're skeptical necessarily, it's just that I feel like operationally they haven't figured out how to change things, or they feel like, well, we got different people. Some people are super excited and running really quickly with it. Other people on our team are not necessarily holdouts, but they haven't quite figured out how to like have there'd be more consistency or more, at least consistent in the outcomes or in everybody. And how has your team operationally changed now? Is it just like, are you using it and you feel like, does it increase the throughput, more pull requests that your team has to navigate, or there are other things that kind of like side effects that you were unexpected or, or maybe you anticipated that happening?

[00:45:07.20] - DHH
I think the level of ambition going way up. Is surprising. It shouldn't be. If you are suddenly vastly more productive, of course you will reach for projects that did not meet the bar being worth it. The anecdote I've given is a lot of performance work focuses on the 99th, right? Or the 95th, like the tail end of requests that take a long time and consume a lot of resources and so forth. Like that's where most of the effort on performance optimization, and of course the mean, is focused. Now, Jeremy on our team kicked off this project to fix the 1%, like literally the fastest request that we have in our system, because why not? Because if you suddenly have this capacity to lower the floor from, I forget what we were at, what we were at, a couple of milliseconds to sub-1, I think is when we went. That actually also adds up and matters, even if it does not matter to the end customer, I mean, if a request is taking, let's say, 10 milliseconds, I mean, that's not perceivable, actually, compared to a request that took 30 milliseconds. But if you have millions of them, it is actually perceivable on your infrastructure spend and so forth.

[00:46:20.22] - DHH
And that's the kind of project that we just wouldn't have tackled. And we have a lot of examples of this, especially on the infrastructure side of things, but also on the front end. And I'd say the same thing for this last Dash sprint. We did or I did on keyboard accessibility. Would I have embarked on that this close to launch in an early age? I probably wouldn't. I would probably have gone like, well, okay, that's something we're going to have to do after launch. We're going to sit down in our ShapeUp circle here. We're going to dedicate it to a cycle. We're going to dedicate specific people to it. And because the cost of implementation have gone down so much, I just feel like it's easier to be whimsical. It's easier to let an idea turn into running code rather than a card for planning. And that has a really positive effect if you have an organization that is capable of absorbing that kind of velocity change, being risk tolerant enough to let individual contributors just run with ideas that they have and deploy them into production. Now, there should be some guardrails too. I could totally see how you can do that wrong and you can introduce a lot of instability into a system.

[00:47:35.06] - DHH
I mean, as we've all found, no agent is able to one-shot everything and they can often get things wrong as good humans, of course. But even if they're at the same level of diligence as a human, and I'd actually say we're at a tipping point here where there's certainly times where the agents show me that they have a vastly higher than average degree of diligence. It's a little bit like self-driving cars. They still crash, just at a much, much, much lower rate than human drivers. It doesn't mean they're safe all the time, but it does mean like, I'd rather that the rest of traffic was a bunch of Tesla self-driving than a bunch of humans, right? So if you're on the receiving side of that, uh, lethal box of metal there, I think anyone who cares about statistics would go like, I already want the AI to do that. Are we there with pull requests? Maybe not, maybe, actually probably on the average, not at the peak. But humans creating pull requests, just a much slower rate, right? It's like with the self-driving cars where wherever number of cars we had, if we had 100 times more cars, Rails, we're also producing some more accidents, right?

[00:48:54.00] - DHH
That's just what percentages do when you scale up the things you're multiplying with. And if you're suddenly going from shipping, I don't know, 5 pull requests a week to 50 pull requests a week, even if the rate of resilience issues is half of what it was before, you're now producing a lot more instability on your system. And I do think that Some organizations are dealing with that, right? Like, there is a bit of a general vibe that certain systems have gotten more unreliable with the introduction of AI. And I think it's not because the AI is necessarily a worse programmer. It is just because they're so much faster, so we can do so many more things, and then you have more opportunities for incidents. Now, we've taken great care about our uptime. Stats I was just tweeting out here. Yeah. Uh, the, uh, this morning about what we went into Basecamp 5 with, which I think on Basecamp 4 in the last 3 months it was literally 100%, like not even a, a second of downtime. Oh wow. So a lot of that is about kind of, um, priorities, like what's acceptable. I actually think for a lot of organizations, especially startups, you should not be aiming for 100%.

[00:50:06.17] - DHH
Like that is, you're not at that phase. You do not need that level of reliability. It's more important for you to get to product market fit quicker and to The libraries are faster, and you can run with C# a little bit and have a little bit more instability there. But again, yes, I— yeah, it's just such a curious moment to be alive. We're seeing this whole transition from these agents are retarded a lot of times, creating terrible code that I wouldn't even work on, right? If you pulled back, 18 months or something, autocomplete. I mean, I gave that shit 5 minutes and then it was like, no, I will not have you complete my sentences in Ruby with gobbledygook that I constantly didn't have to delete. That's an absolute terrible way to work. And then boop, 18 months later, here we are just being utterly delighted on a very regular basis about the quality and the poetry even of what this machine is able to produce. Now, I will admit that my experience of this is probably biased for the reason that most of the codebases, if not all the codebases that we work on at 37signals, already have established patterns.

[00:51:23.09] - DHH
Now, Rails already has a bunch of established patterns, but then there's the architecture of the individual application on top of that. And if you just let agents loose in a kind of shitty codebase, a big ball of mud. I actually don't know what that experience is like. I do not have a lot of experience. Just like, can a shitty codebase be an amenable place for an agent to work and produce new, good, and better code? I don't know. What I do know is the codebases that we have are amenable for agents to do really good work that still needs to be reviewed, that still needs a human programmer. In the loop, but nonetheless is a huge step forward.

[00:52:04.00] - Robby
I'm curious if you think that there's anything we could be doing as a community to help attract people that are curious to start building their first apps, but they're maybe— do you think Rails could be a place for, I'm air quoting, vibe coding their first application?

[00:52:19.22] - DHH
Yes, yes, yes. And I have a bunch of ideas on how we could make that even easier. Because I do think there's an entire class of applications, things that would historically have been served by things like Microsoft Access or what was the thing called back in the '90s? FileMaker Pro. Yes. Applications, Excel, Excel spreadsheets really is one of the largest application platforms for non-programmers in the world. If we can move tools as powerful as Ruby on Rails down to that level and give humans who do not have access to highly skilled programmers the capacity to produce applications that would never meet the bar of hiring someone else to work on, we're gonna unlock a tremendous amount of joy and productivity for the world. So I'd love for Rails to be part of that equation, that Rails, some Rails applications, I mean, this is undoubtedly already true. I don't think we quite have the packaging, but we can get there, can be written entirely by agents in the true vibe coding sense that the person directing this development process never looks at the code. Now, I wouldn't do that at a Basecamp scale. I wouldn't vibe code my next bank app, but there's a whole class of apps that exist at a level of criticality where that's just not a big deal.

[00:53:48.15] - DHH
Now, if you go back like 6 months or 9 months, I mean, we're all talking about like, oh, the agent is just going to leak all your API codes and keys and it's going to just make the password be admin and all that stuff. I don't hear a lot about that. So partly because the models just got a lot smarter, a lot better. They just don't do that in a normal course of business. Now, prompt injection is still a thing and there's occasions where they hallucinate. But even that, like hallucination, for example, stopped being a thing. And it stopped being a thing because we went from AI to agents, and agents have tools, and they can run tests, and they can run linters. So even when they do hallucinate, the hallucination never makes it into the pull request because they've just run out the code and it does. So yes, we should be doing more. I updated the tagline on Ruby on Rails a while back, from, uh, hello world to IPO, to, uh, from prompt to IPO. No doubt in my mind that we will see IPOs over the coming years where the application was Vive-coded, that that was how you got to product-market fit.

[00:54:56.00] - DHH
And then presumably at that point, once you have something economically viable and interesting, you can hire programmers who can review the things and make sure the password isn't just admin, and I don't know, the Redis isn't just fully opened on your cloud infrastructure and all these other things. Or maybe agents are gonna be good enough that they can also do that for you. But Rails needs to, and always has, embraced this criticality spectrum. That from the earliest days of Rails, a lot of the attraction outside of traditional programming circles was that, like, hey, I was coming new to programming. I used to do biology. I used to be a musician. I used to do all sorts of other things. And then I came into programming because I wanted some programming or another. And I started with Rails and I didn't I didn't know everything, and Rails had really flattened the curve, made it very easy for me to get something going, made it such that most of my mistakes weren't gonna be critical, handled a lot of the security stuff, for example, all built in, so I couldn't make the dumbest mistakes you would make in other applications because I just didn't know better.

[00:55:58.08] - DHH
That's actually very similar in terms of on-ramp with where these agents are, right? I think we have an institutional openness to this that a lot of other communities do not. They have more of a, okay, you're an idiot. You need to climb this 200-meter wall before you'll be let into the Garden of Eden we all other inhabit up here in high-minded programmer land, right? I don't want Rails to be like that. I want it to be flat. I want it to be possible for people who don't know a lot of things, to get started, get on the journey, learn things, make some mistakes, maybe shoot a toe off or two.

[00:56:38.12] - Robby
Yeah.

[00:56:38.20] - DHH
Maybe have some downtime. All of these things are rites of passage. And we should be embracing the fact that there are other people out there who love computers as much as we do, who wanna write Ruby, who wanna use Rails. Oh, are we so fortunate. And if a lot of that new code is then written by agents directed by humans or agents directed by other agents or however else it all shakes out, great. This is also one of the reasons for why, while we do have some issues, especially about security reports, where AI slob and agent-generated code can be a nuisance. Yes. And we need ways to tackle that. I am not at all against that agents should be writing Rails features and should be improving the Rails codebase. In fact, I'd love that. Now, it needs to be reviewed, certainly for a long time, by very qualified humans on the core and committer teams and contributor teams and so forth. But we should have open arms to this. This is the most exciting thing that has happened to computers since I got going with them 40 years ago, and we're gonna lean in hard.

[00:57:47.22] - Robby
That's great. So I've kept you long enough and, and we got a tight schedule with you, so let you get back to your Basecamp 5 launch and all the chaos that comes with that. Or maybe it's actually been really smooth for you folks. So congratulations to you and the team again for that. Uh, is there one last thing you would like to leave our listeners with? What do you think Rails developers should spend less time worrying about right now?

[00:58:08.15] - DHH
The end of the world, doom, whether it's climate hysteria or AI is gonna kill us all. Do you know what, if any of those things are gonna happen, they're gonna happen whether you worry about them or not. You do not have the power to impact any of that. So focus on the progress, on the future, on everything that should make you excited. Focus on your love of computers. Focus on the beauty of Ruby, the productivity of Rails, all of these amazing things. We live in the best of times on 500 different axes. And if you focus your gaze on all the ways things are not great, you're going to poison your mind. And it is too precious of an organ to poison like that. So don't do it. Get back to being excited about technology. That is the place you should have both your feet in. And then whatever, occasionally have a slight concern about the way things could go wrong, but do not let that dominate you. And keep your love of computers, plow it forward, embrace the future.

[00:59:13.11] - Robby
Let's go. All right, let's go. David, thanks again for stopping by to talk shop with us on On Rails.

[00:59:18.19] - DHH
My pleasure.

[00:59:21.23] - Robby
That's it for this episode of On Rails. This podcast is produced by the Rails Foundation with support from its core and contributing members. If you enjoyed the ride, leave a quick review on Apple Podcasts, Spotify, or YouTube. It helps more folks find the show. Again, I'm Robby Russell. Thanks for riding along. See you next time.