DHH on Basecamp 5, Agents, and Why Rails' Stability Matters More Now
Ruby on Rails
Recorded the same week 37signals shipped Basecamp 5, this episode of On Rails has host Robby Russell asking David Heinemeier Hansson, the creator of Ruby on Rails and co-owner of 37signals, two related questions. What does modern Rails make possible in a flagship product today? And how is AI-assisted, agent-driven development changing the way 37signals builds software? Heinemeier Hansson argues that Rails' long-stable backend has become an unusual advantage in the AI era. He describes reversing his earlier insistence on writing every line of code by hand, and he now calls taking AI seriously a professional obligation. He also names the limits: agents that bolt on code instead of reshaping architecture, and organizations whose instability grows with their output.
What still excites him: Ruby and the internet
Asked what still keeps him excited after all these years, Heinemeier Hansson names two things. The first is Ruby itself, which he calls the most beautiful programming language he has ever seen. That holds, he says, "whether I'm writing it or watching an agent do it." Seeing ideas come to life in code that beautiful remains a constant delight to him.
The second is the internet. For all its flaws, he considers it the best application platform software developers have ever had, because it lets them distribute applications without the gatekeepers found on other platforms. Combining Ruby with the open web to build good web applications is still, for him, a compelling mission. He admits that if someone had asked him 23 years ago whether Rails would last this long, he probably would have said no. Now, on what he calls the eve of another great revolution in computing with AI, he says working with Rails is as satisfying as it ever was.
A backend that barely changed in twenty years
Russell asks which parts of Rails today feel closer to the original vision than expected. Heinemeier Hansson says that when he looks at old Rails code, including his well-known 2005 demo video, "the shape of that code is eerily similar." Controllers look much the same, especially after the move to REST and the seven standard actions. ActiveRecord has kept the core of its DSL since essentially the beginning. It has become far more powerful and polished, but in his view anyone comparing a 20-year-old Rails backend with today's would find it immediately recognizable.
The frontend is different. Even for a strong advocate of Hotwire and minimal build pipelines, he says, frontend code looks quite different from 20 years ago. On the backend, though, he believes Rails and Ruby got many things right from the start. For him, the payoff is the return on learning. In most ecosystems, time invested in, say, a 2009 JavaScript framework pays few lasting dividends beyond general principles. Deep knowledge of ActiveRecord, by contrast, is "an investment you could amortize over literally two decades."
He notes that Rails has more than longevity. Large companies such as Shopify still build on it, and new startups keep choosing it. Some ecosystems, he says, belong to a single generational cohort whose applications simply carry on. Rails has some of that too, but it also keeps attracting fresh developers. With AI in the picture, he argues, "it's never been a better time to use Ruby on Rails." The conventions, guardrails, and huge body of existing code written to Rails principles can teach both human and agent developers to write better code.
Basecamp 5: fewer SQL fragments, same architecture
Russell asks what modern Rails made possible in Basecamp 5 that would have been hard seven or ten years ago. Heinemeier Hansson first points out that Basecamp predates Rails; he started building it in 2003. The Basecamp 5 backend still closely resembles that first version. One visible difference is the near absence of raw SQL. He doesn't think Basecamp 5 contains any complete SQL statements anymore, because ActiveRecord has become powerful enough that dropping to that level is rarely needed.
The biggest shift in how the code is organized, he says, was adopting patterns such as recordables and delegated types. He is careful to add that this isn't really a Rails feature. Rails includes delegated types mostly to nudge developers toward an architectural style, and the pattern doesn't depend on Rails or need much plumbing.
What he finds more interesting is how Rails has kept pace with changes in the web platform. One example is passkeys, which 37signals is working to bring into Rails in a fully native form. Another is how much faster developer hardware has become.
A 60-second test suite on a local machine
Heinemeier Hansson describes a reversal in where the fast computers are. For a long time the development machine was the slow one and servers were fast. Now, he says, the fastest single-core CPUs are in developer machines, which also have many cores. Just before the recording, he had benchmarked the entire Basecamp 5 test suite on his local AMD 395 machine against one of the fairly fast cloud machines 37signals uses for this work. By his account, the 16 physical cores of his local machine ran the suite about twice as fast as 20 data-center-grade cores in the cloud. The full suite finished in about 60 seconds.
He calls this remarkable in itself and says it enables a different way of working. Auxiliary processes such as CI and build pipelines can be greatly compressed when a test suite for an application as large as Basecamp runs in a minute on a modern computer. In his view, much of what modern Rails gains today comes from hardware that has become better, faster, and cheaper, and from a web platform whose capabilities have grown quickly.
No-build and the end of an uncomfortable frontend era
The move to no-build a few years ago, using native JavaScript modules that can be loaded and referenced directly, changed how Basecamp's frontend was built. Heinemeier Hansson describes the Webpacker era, roughly 2015 to 2019, as years when building Basecamp's frontend was less enjoyable than building its backend. He says he knew at the time that this was not the final form. It was simply what was available: a modern application meant accepting uncomfortable, cumbersome build pipelines. Reaching a point where none of that is necessary, he says, is "truly a delight."
Lexi: a new editor built on Lexical, headed for ActionText
The other major piece he highlights is a new rich text editor in Basecamp 5 called Lexi, built on Meta's Lexical framework and destined for ActionText. 37signals had wanted tables in Basecamp's WYSIWYG editor for almost a decade. Its previous in-house editor, Trix, worked well within its scope but couldn't be extended for certain things. Heinemeier Hansson finds it delightful that the same foundation used by Facebook and WhatsApp, platforms serving billions of people, is now easily available in Basecamp and soon in Rails.
He notes that passkeys, the build pipeline, and Lexical all concern the frontend. That supports his earlier point: the backend is so stable that the team is "really chipping away at it now." Looking at the commits in rails/rails, he says, much of the ongoing work polishes rare edge cases. "We're down to the 99.999% of coverage," as he puts it, and he thinks the community should see this as a real achievement.
He adds that he'd gladly discard any of it if something better came along. If he looked at code and found it existed only for legacy reasons, he would rip it out. But whenever he finds a better way, it goes into Rails, and these days there is little left to change on the backend. He credits the six or seven thousand contributors Rails has had over the years. It would be odd, he says, if all that work weren't accumulating into something durable, but he still considers it special that after 23 years people would happily start a greenfield application on the same stack.
Balancing legacy stability and greenfield joy
Russell raises a tension he sees from running an agency that maintains long-lived Rails applications. Most teams, like Shopify with an application in development for more than 20 years, can't rebuild from scratch every few years. 37signals, meanwhile, periodically reimagines Basecamp. Rails seems to serve both groups, and Russell asks whether that balance was intentional.
Heinemeier Hansson sees it as a benefit of longevity and of the intense community engagement in Rails' first five or six years. During that period the framework really did rip things out and change dramatically. He cites the Rails 2.3 to 3 transition as "big open surgery." That churn, which he considers unavoidable while learning what a framework should be, happened early and produced a solid foundation. He compares it to a UK tavern from 1284 that is still standing, not by accident, but because it was built on a solid foundation. Because backend programming hasn't produced major new paradigms in a long time, Rails hasn't had to trade away the qualities that make greenfield development enjoyable in order to stay stable.
The Basecamp 3 chassis, Fizzy, and carbon-dating an app
He knows this firsthand because 37signals maintains codebases of very different ages. Basecamp 5 is built on what the team calls the "chassis" of Basecamp 3, a codebase started in 2013. Basecamp 5 substantially revamps the UI and more, but it evolved on top of that 2013 code. 37signals also still maintains the original Basecamp written in 2003. Thousands of customers still use it, even though it stopped being sold to new customers in 2010.
At the same time, 37signals recently released Fizzy, a greenfield application built to the best standards and ideas the team has today. Fizzy's code is public, and Heinemeier Hansson can compare it with Basecamp 5's private code. His verdict: "They're not that different." He sees this as bridging the gap between stability for long-lived applications (Basecamp, Shopify, and what he describes as over a million other Rails apps) and enjoyment for new ones.
He repeats that this doesn't hold for the frontend, and says Rails can't take all the blame for that. He attributes it to the churn in the JavaScript ecosystem since around 2009, including the rise and decline of React and many other frameworks. If you want to "carbon date" a Rails application, he suggests, look at the frontend: Webpacker, esbuild, or no-build, whether there's jQuery, which frontend framework it started with. Opening an ActiveRecord model file won't tell you much. A connoisseur of the DSL might spot small tells, but he says he can open model files in the Basecamp codebase that "would look absolutely right at home in Fizzy, even though Fizzy was just written 5 minutes ago."
Coming to Rails World: Lexi in ActionText, passkeys, and magic links
Asked what might be extracted from Basecamp 5 for the community, Heinemeier Hansson confirms the two items he has already teased, both planned for Rails World in September.
The first is a major upgrade to ActionText, with Lexi as the default editor while remaining compatible with Trix. Existing applications, including some of 37signals' own, still use Trix, so both should be supported and migration should be possible. He calls rich text input table stakes for nearly every modern web application. Trix served people happy with its toolset but had glaring omissions, notably Markdown support and tables. For some applications either one was a deal breaker that forced developers to build their own editor, which he calls a useless time sink. Shipping a comprehensive editor built on Lexical by default is, in his view, a big step up.
The second, already an open pull request, is end-to-end passkey support in Rails. He says he has changed his mind about passkeys. His first take assumed they would replace passwords entirely, and he saw usability problems with that. For example, a passkey created on an iPhone might leave you unable to log in from a Windows PC. His breakthrough, used in Fizzy, was to pair passkeys with magic links so users can always log in through email. He now thinks this is the right shape for most applications: magic links and passkeys, "That's it," and ideally no social logins either.
He hopes this combination will also ease the intimidation many developers feel about authentication. He has always found it crazy that teams outsource their entire login system to a SaaS provider, not just offer "log in with GitHub." He accepts that it happens because developers feel uncomfortable building authentication themselves, even with what Rails provides. Passkeys, he says, are simple in concept but subtle, and getting the JavaScript "dance" exactly right is tricky. If the framework takes responsibility for that and wraps it in an easy API that anyone can add to a login page, he believes it will "bring the floor down so low that everyone can play." He mentions a few more tricks planned for Rails but doesn't reveal them.
Agents, authentication, and why Rails shouldn't ship an AGENTS.md
Russell asks how passkeys and similar mechanisms would work if agents need their own accounts in applications, and whether there's an architectural problem to solve now. Heinemeier Hansson agrees there is interesting work to do, but says "it's not figured out at all." Everyone briefly went all in on MCP, then "the puck kind of skated to CLIs," and now people talk about doing both. Because the field is so important and moving so fast, he wants to be careful about "pouring foundational framework concrete" around it before its final shape is clear.
His example: if the last Rails release had shipped a default AGENTS.md file, it would already be outdated about three model generations later. He goes further and says it would be harmful. He cites what he calls studies on AGENTS.md files and other agent steering, which suggest that telling an agent to do something it already knew how to do well can make it worse. The instructions fill the context window with distractions and produce worse code. He compares the pace to JavaScript's framework churn "on turbo steroids": not a new framework every six months, but a complete rethink of how to work every six weeks or so. Many people, he notes, point to last December as the turning point when developers began letting agents write the first draft of code instead of using autocomplete in Cursor or Copilot.
The same speed affects Rails World itself. Talk submissions are already in, yet Heinemeier Hansson says he doesn't know exactly what he'll talk about, because he wants his talk to be timely. He describes the industry as moving faster than it ever has. That is exciting, and also a little frightening and hard to keep up with. He thinks people have to hold both feelings: some anxiety about what the industry and the world will look like "5 minutes from now," and excitement that computers can do this at all.
GPT-5.5 and the keyboard accessibility sprint
He calls the recent jump to GPT-5.5 a massive step forward, comparable to what he calls an "Opus 4.5 moment" where "my mind is blown." He says he can delegate much larger tasks and gets much better code back.
His concrete example is the last sprint before Basecamp 5's launch, when he worked on keyboard accessibility. He wanted an almost NeoVim-like experience in which users can move between the sidebar and other areas. Getting focus management right, he says, takes a lot of work, and he spent much of that time with GPT-5.5. The model wrote good implementations, though they still needed steering and some of its first attempts didn't satisfy him. What impressed him more was its ability to explain itself. When he questioned code that looked excessive, asking why something was necessary, it walked him through edge cases and timing problems, such as needing to request a frame first. He says he had a handful of experiences in the last two weeks where it explained intricate parts of his own code with a fidelity that left him speechless.
He describes this with wonder: sand turned into silicon and chips by lasers, now reasoning with him about code. Part of why he still programs is the sense of a direct connection with the computer, and AI gives him a second kind of direct connection. He also acknowledges swinging between "hyper enthusiasm" and "mega skepticism" at least weekly. Sometimes everything seems amazing. Other times an agent does something so wrongheaded that he feels it would have blown everything up if he had let it run unchecked.
Designers and PMs writing code, and the limits of vibe coding
One of the biggest workflow changes at 37signals around Basecamp 5, he says, is that designers and project managers now write Ruby and Rails code. They can turn their ideas into working software without a programmer in between. He finds it remarkable that the people responsible for working out how something should behave can now test and validate their intuitions on their own.
He adds clear caveats. 37signals is not merging truly vibe-coded work, meaning code that is produced without being understood or reviewed in detail. "In most cases, those things are not getting merged." The value, in his account, is reaching one of the hardest questions in software much sooner: how should this work, is it good, is it fun, does it feel right? Answering those questions early saves programmers weeks or even months.
He draws on his own history. In the early days, Jason (his 37signals partner) would ask him to build something in Basecamp. He'd spend a week or two on it and feel proud of the result. Then Jason would say it didn't work and had to work some other way. He recalls feeling "married to this piece of code," a natural human reaction even if you're not supposed to have it. Being spared much of that wasted coding feels like a big step forward to him. That doesn't mean Jason could vibe code all of Basecamp alone, "at least not yet. Maybe that day will come, but it's not today."
Shape Up's six-week cycle now looks archaic
This compression directly challenges Shape Up, the methodology 37signals has long used and promoted. Heinemeier Hansson says Shape Up's six-week cycle rested on assumptions about how long major features take to build, and those assumptions "are just no longer valid." Six weeks used to be the right timeframe for building things at Basecamp. Now he struggles to imagine almost any Basecamp feature needing six weeks. He says the same applies to other software he's working on outside Basecamp.
"Make the change easy, then make the easy change"
Quality still requires attention, he stresses. Because agents produce so much code so quickly, a carefully built architecture can be wrecked surprisingly fast. Ask an agent naively for something and it will deliver, which he calls "the monkey hand curse": you get whatever you ask for, even when it shouldn't be delivered that way.
He doesn't think agents are yet good at what Kent Beck described as "make the change easy, then make the easy change." Agents can make very hard changes and will happily write 1,200 lines of code where an architectural adjustment in Rails could have reduced it to 20. He considers that kind of adjustment essential to a codebase's longevity: a considered, malleable architecture that reshapes itself when new requirements don't fit, rather than having features bolted on. In his view, agents currently try to please as quickly as possible with as few tokens as possible, which encourages bolting on.
He also notes that humans have long developed software the same way. Many codebases turned into a big ball of mud quickly once the original architects left or deadline pressure removed time for refactoring. So he frames his hesitation about agents as hesitation about development without care for architecture, style, and beauty. If you're building a large system, he says, you must stay committed to those values or end up in whack-a-mole, where one new feature creates three bugs. He believes many vibe coding adventurers have found that situation sticky and nearly impossible to escape when the agent runs loose "and there's no red thread." He allows that the next model might change this, since he has had to reverse his views several times in the past year. For now, though, "we're still needed, us squishy humans."
AI as a professional obligation, and taking the "Tobi pill"
Russell notes that organization leaders have more freedom to experiment than employees who must keep shipping, and asks how Heinemeier Hansson's own AI use compares with his team's. He replies that good programmers always make time to experiment and adopt better tools, and that Ruby programmers as a group tend to be curious and eager to learn. He sees those traits as exactly what the transition requires.
He openly acknowledges his reversal. A year ago he was proudly saying on podcasts that he wanted to write all his code by hand and "sweat every single character." He still cares about the aesthetics of every character, but no longer thinks he has to chisel the code himself. If an agent can produce code as good as what he'd write, "obviously the game has changed." He therefore calls it "a professional obligation of every programmer" to take this revolution seriously: spend time learning it, learn where it still falls short, get excited when it dazzles, and avoid what he calls distracting ideological dead ends such as "it's just a parrot." Whatever one believes about those debates, he says, it misses the practical reality that these tools are very powerful.
At 37signals, he says, the best people are embracing AI fully. Timing plays a part, since some people naturally spend a weekend experimenting, but he also thinks organizational permission matters. He admits he took longer than some. Tobi Lütke at Shopify saw the future earlier and mandated within Shopify that people pay attention to AI before the industry, or Heinemeier Hansson himself, had caught up. He says he has now "taken the Tobi pill" on AI acceleration, as have most people around him, and that holdouts are rapidly shrinking. He says he respects them, having been one recently. Anyone who is exceptionally productive without AI deserves credit, but he says he wasn't that good and is much more productive with agents.
Code as art: git reset and exploring more ideas
The most surprising delight for him has been the chance to see many implementations. He compares it to looking at art: you may look at a thousand pieces and dislike almost all of them before finding the one you love. He feels the same about code and sometimes needs to see seven implementations before deciding which shape he likes. With agents, rejecting one is cheap: "Bam, git reset. And now it's gone." He says he doesn't feel bad throwing away 1,000 lines, because the agent will happily build another version (for a token fee). Lower implementation cost means he can follow intuition and creativity instead of being deterred by effort.
He places AI alongside earlier shifts that left some programmers behind. In the late 1990s, he knew programmers who were dismissive of the internet and web applications, and web developers, especially PHP programmers, were called "script kiddies." He points out that he learned to program through PHP. Early mobile apps were slow and clumsy, yet no one now doubts mobile is a serious part of the business. You could still build a niche business writing bespoke assembler software without the internet, and he'd cheer you on, but that isn't where the economy is. Not every trend lasts; NFT infrastructure, he says, "didn't pan out," and if every idea succeeded the industry wouldn't be trying enough ideas. He considers it clear that AI is one of the big shifts, possibly the biggest.
Rising ambition: optimizing the fastest 1%
Russell asks how 37signals has changed operationally: more throughput, more pull requests, unexpected side effects? Heinemeier Hansson says the biggest surprise is how much ambition has risen, though he says it shouldn't be surprising. When you become far more productive, you take on projects that didn't used to be worth doing.
His example is performance work. Optimization usually targets the slow tail, the 95th or 99th percentile, and the mean. Jeremy on the team instead started a project to speed up the fastest 1% of requests, "because why not." Heinemeier Hansson recalls they went from a couple of milliseconds to under one, though he says he doesn't remember the exact figures. A request taking 10 milliseconds instead of 30 isn't noticeable to a user, but across millions of requests it shows up in infrastructure spending. He says there are many similar examples, especially in infrastructure but also on the frontend.
The keyboard accessibility sprint is another. In an earlier era, he says, he probably wouldn't have started that work so close to launch. It would have been deferred until after launch and given a dedicated Shape Up cycle and specific people. With implementation so much cheaper, "it's easier to be whimsical," and easier for an idea to become running code instead of a planning card. He sees this as positive if the organization can absorb the change in velocity and tolerate the risk of letting individual contributors ship their ideas to production. He also says guardrails are needed, because doing this badly can introduce a lot of instability.
Self-driving cars, PR volume, and reliability
He offers an analogy for agent reliability. By his account, self-driving cars still crash, but at a much lower rate than human drivers, so anyone who cares about statistics would rather share the road with them. He says agents are at a tipping point where they sometimes show much higher than average diligence. On pull requests, he thinks agents are probably at human level on average, though not at the peak.
The catch is volume. More cars mean more accidents even at a lower per-car rate. Likewise, a team going from about 5 to 50 pull requests a week introduces more instability overall, even if each pull request is half as likely to cause a problem. He says there's a general sense that some systems have become less reliable since AI arrived. He attributes this not to AI being a worse programmer but to the speed and volume of changes creating more chances for incidents.
Uptime, and why startups shouldn't chase 100%
He says 37signals takes uptime very seriously. That morning he had posted stats showing that Basecamp 4 had 100% uptime over the previous three months, with not a second of downtime, going into Basecamp 5. Much of that, he says, depends on what an organization considers acceptable. He argues that many organizations, especially startups, should not aim for 100%. At their stage, reaching product-market fit quickly matters more, and some instability is acceptable.
He then reflects again on how fast things have changed. About 18 months ago, he gave AI autocomplete five minutes before rejecting it, because it filled his Ruby with gobbledygook he kept deleting. Now he is regularly delighted by the quality, and even the "poetry," of what these tools produce. He acknowledges a likely bias: nearly all 37signals codebases already have established patterns, both from Rails and from each application's own architecture. He says he has little experience of what agents do in a messy codebase, a big ball of mud, and doesn't know whether they can produce good code there. What he does know is that 37signals' codebases let agents do very good work that still needs review and still needs a human programmer in the loop.
Can Rails be the place to vibe code a first app?
Russell asks whether Rails could attract newcomers who want to vibe code their first application. Heinemeier Hansson answers "Yes, yes, yes," and says he has ideas for making it easier. He sees a whole class of applications historically served by Microsoft Access, FileMaker Pro, and especially Excel, which he calls one of the largest application platforms for non-programmers. Bringing a tool as powerful as Rails down to that level, for people who will never have access to skilled programmers or projects worth hiring for, would in his view unlock "a tremendous amount of joy and productivity."
He believes some Rails applications can already be written entirely by agents, in the true vibe coding sense where the person directing the work never looks at the code. Rails doesn't yet have the right packaging for this, he says, but it can get there. He wouldn't do this at Basecamp's scale or for a bank app, but many applications sit at a level of criticality where it isn't a big deal.
He notes that six to nine months ago people worried about agents leaking API keys or setting passwords to "admin," and says he hears much less of that now, partly because models have become smarter. Prompt injection remains a problem and hallucinations still happen. But he argues hallucination has largely stopped mattering, because the shift from AI chat to agents gave models tools to run tests and linters, so hallucinations rarely reach a pull request.
From prompt to IPO, and the criticality spectrum
He recently changed Rails' tagline from "Hello World to IPO" to "From prompt to IPO." He has no doubt that companies will go public in the coming years with applications vibe coded to product-market fit. At that point, he suggests, they can hire programmers to review the code and make sure the password isn't "admin" and Redis isn't exposed on their cloud infrastructure. Or agents may become good enough to do that too.
He argues Rails has always embraced a criticality spectrum. From early on, much of its appeal was to people outside traditional programming, such as former biologists and musicians. Rails lowered the barrier and built in security so beginners couldn't make the worst mistakes. He sees today's agents as a similar on-ramp. Other communities, he says, effectively tell newcomers to climb a "200-meter wall" before being admitted to "high-minded programmer land." He wants Rails to stay flat, letting people start, learn, make mistakes, "shoot a toe off or two," and have some downtime, which he calls rites of passage.
This openness extends to Rails itself. He acknowledges that AI-generated slop, especially in security reports, can be a nuisance that needs addressing. Still, he says he'd welcome agents writing Rails features and improving the codebase, provided the work is reviewed "certainly for a long time" by highly qualified humans on the core, committer, and contributor teams. He calls AI "the most exciting thing that has happened to computers" since he started with them 40 years ago, and says Rails will lean in hard.
What to worry less about
To close, Russell asks what Rails developers should worry less about. Heinemeier Hansson's answer is doom: "climate hysteria" or fear that AI will kill everyone. If such things happen, he says, they'll happen regardless of individual worry, which individuals can't influence. He urges listeners to focus on progress, their love of computers, the beauty of Ruby, and the productivity of Rails. He believes we live "in the best of times on 500 different axes," and that fixating on what's wrong poisons the mind. His advice is to keep both feet in excitement about technology, allow occasional concern about what could go wrong without letting it dominate, and "embrace the future."
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 Hansson, welcome to On Rails.
Thank you. It's about time I got on the show, so I'm really happy to be here.
Welcome aboard. So, David, after all of these years, what still keeps you excited about Rails?
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 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.
Are there parts of Rails today that feel more aligned with your original vision than you probably would've expected it to?
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.
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. 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.
So I'm definitely going to want to dig into 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, and congrats to you and the team on that, but because it does feel like a good opportunity to ask, 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?
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. 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 it 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. 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.
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 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.
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. 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 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. 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. 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. 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 the things running, that 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, 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?
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. And I know this because we do both.
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? 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 a 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. 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.
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?
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. 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 Fizzy 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. 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.
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.
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. May cause upgrading, sighing, and saying, "We should really tackle this," for 6 straight months.
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?
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.
This is one of the curious revelations we've seen on some of the studies on agents.md files 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 in 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. 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 World, 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, 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 a little anxious, to be frank, about what does our industry look like 5 minutes from now.
Sure.
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. 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. 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. 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. 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 Omarchy 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. And if you just naively ask the agent for something, it'll give it to you.
I mean, that's the monkey's paw 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. 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. 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.
So anyway, now, see, now 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—
Well, I think 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?
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?
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 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. But now I do feel like I've finally taken the Tobi 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 art. Like I can look at a lot of different art 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.
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 mainstay 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. 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 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? Not every idea that this industry has is going to go on the shelf and last forever, right? 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 one of the big ones, maybe even the biggest one.
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 maybe you anticipated that happening?
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, 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. 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 Shape Up 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. 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 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? 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. 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 second of downtime.
Oh wow.
So a lot of that is about kind of priorities, like what's acceptable. I actually think for a lot of organizations, especially startups, you should not be aiming for 100%. 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 scissors 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. 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.
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?
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.
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 hello world to IPO, to from prompt to IPO. No doubt in my mind that we will see IPOs over the coming years where the application was vibe-coded, that that was how you got to product-market fit. 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 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.
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.
Yeah.
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 slop 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.
That's great. So I've kept you long enough 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. 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?
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. Let's go.
All right, let's go. David, thanks again for stopping by to talk shop with us on On Rails.
My pleasure.
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.
Article published