DHH’s new way of writing code

How has the creative Ruby on Rails changed how we build software now with AI agents? David Heinemeyer Hansen, often referred to as DHH, created Ruby on Rails, Omachi, and is the co-founder of 37signals. He bashed capabilities of AI coding tools on Les Friesen's podcast six months ago. Then over the course of a few weeks over the winter break, he did a 180 turn and went AI first on everything. In today's conversation we cover how David and his team at 37signals build software today and how AI tools are making them more ambitious than ever before. Why Ruby on Rails and Linux could become even more popular than they are today as they are both well suited working with AI agents. Why taste and beautiful software are becoming more important and why both standout designers and engineers who care about the craft could become more in demand. And many more. If you're interested in what one of the most experienced builders in the tech industry thinks about the practical utility of AI tools and how these tools could impact software engineers who care about the craft, then this episode is for you. This episode was presented by StatSig, the unified platform for flags, analytics experiments, and more. Check out the show notes to learn more about them and our other season sponsors Sonar and WorkOS. David, it's awesome to have you here. Thanks for having me. Thanks for coming. I should actually say. You're in Copenhagen. That's my city of choice at the moment. It's a beautiful city. It's got so much going for it. And so what have you been up to? I'm always building stuff. I have been building stuff for a good damn three decades now on the internet. I got started back in 94, I think it was, when I first got exposed to it and basically just never stopped. And in the past six months, I've been building a variety of things. One of them is a new Linux distribution called Umachi. I switched to Linux about a little over two years ago, I think now. First spent some time on Ubuntu, having fun with that, and then realizing I actually wanted to make my own system from scratch, building it on top of Arch and Hyperlens. Put a lot of time into Umachi. It got started as a summer project in between racing at the 24 Hours of Le Mans. There's a lot of downtime in that week, so I just started hacking on it and it really took off very quickly thereafter. It's been a truly inspiring ride to see that even in a market as crowded as Linux distributions, there's about 7,000 different distributions out there. Some of them with long pedigrees and many of them even based on sort of kind of similar vibes to some extent. There's room for something new and it's a great reminder that all the ideas in the world may be taken and it doesn't matter because your spin on it isn't. And I put my spin on Linux, built Umachi, built the perfect computer system for me and saw exactly the same thing I've ever seen whenever I build something that really just hits the spot for me personally. There are thousands of others just like me or close enough to what I like that they find the same pleasure and joy in it. Whether it was Ruby on Rails, Kamal getting out of the cloud, any of these things, it's the same syndrome. Yeah. With Rails, you were literally scratching your own itch. You were just building your own components and then open sourcing them. Is that how it started? I picked up Ruby in the early 2000s and really put it to the test in 2003 when we started building Basecamp. And I did not have a mandate of what to use to build it. Prior to that, I'd been working for a lot of client projects that would say, well, we're building this in PHP because we have someone who knows that. So this is what you have to use. And then we were building our own system. We're building Basecamp and I was free to choose. So I chose Ruby. And at the time, Ruby didn't have any tooling or not very much when it came to web applications. So I had to build it all myself. And that turned into Ruby on Rails, which is still going strong. I'm still very heavily involved with that. I think in some ways, Ruby on Rails is having a little bit of a renaissance now that it is one of the most token efficient ways of building web apps. It's ideally suited for the agent workflows we're dealing with now. We'll see how long that lasts. Maybe all the agents are going to be writing machine code or assembler in about five minutes. So maybe that comes to an end. But for the moment, token efficiency still matters. And it still matters whether the agents produce code that humans are able to read and verify. That may also come to an end at some point. But as it is right now, it's been a fun ride to just see these kinds of projects where I'm scratching my own itch resonate with a much larger community of people who then show up and want to help. I mean, for Umachi, which has only been around for, what is that, just over six months now, we have, what, 400 contributors who've made code changes to the distribution. And on top of that, we have tens of thousands of people who've installed it and use it as their daily driver. So I always love that discovery of something new, novel, and inspiring like Ruby. Or it sounds weird to talk about the discovery of an operating system that's been around since, what, 91? But for a lot of people, Linux now is that discovery because they have not been using it on their personal computer. So they're seeing it for the first time. And for me to help a new cohort of Linux users and hopefully even enthusiasts come to be because I'm flattening the curve a little bit, I'm making it easier to get started, I'm making the default installation just look amazing so that they don't feel like they have to invest a hundred hours into tweaking this system to get going. It's really fun. But what's also fun, of course, is that both of these things, both Ruby on Rails and Umachi were not just hobby projects. I love hobby projects and I will always do those, but I also like to apply them to business. So at 37signals, we built an entire business for 20 plus years on top of Ruby on Rails. We're now running Linux on the majority of developer machines because we now have our own distro. So it's Umachi. Umachi is... I mean, people can choose, right? Can they? Well, sort of, kind of. We started with an open choice and then at some point it just doesn't make sense anymore. In the same way it would not make sense for someone to be at 37signals and say, I want to write this thing in Django. We're going to use Python and this other framework, even if you have Ruby on Rails and you're doing that. So we pivoted from an early invitation to play around. That was what, when I first switched to Linux, I just said like, Hey, if you want to check it out, check it out. Then when things got a little more serious with Umachi, I just said, let's go all in. For everyone who's on the technical side of things, not the iOS developers, of course, but anyone who's working with the web, who's working with Ruby, who's doing DevOps, they should be on Linux because first of all, that's closer to what we deploy. We've always deployed on Linux. We've been a Linux shop on the server side since day one. For developers and system operators, I actually think it is a material advantage to be closer to your production environment and just be more familiar with the tools. Then on top of that, of course, we're building this distribution and we should have as many hands help out as possible. And given the fact that I'm the CTO of this company, I get to set the technical direction and this is the direction we're going. Can you just do a very short recap of how you grew and right now, where are you? Where is the business as a whole? And you keep launching new and exciting and just cool stuff. I think Fizzy was the latest one. Yes. So, 37signals was founded in 1999. It started as a web design firm. And then I joined up in 2001, two years after, and for a couple of years, collaborated with Jason on these consulting projects. And then it was in 2003, we started to work on Basecamp, released it in 2004. Actually either the day after or the day before Facebook went live, which is kind of a funny coincidence that we were of that same time and cohort. And within about a year, we realized this thing was taking off and we went full time and switched from being a consultancy to being a software company. Awesome. And that's now 22 years ago, a little more than that. But in that time, we've released a ton of products. Basecamp was the first, remains the biggest and most important, which is also kind of funny because you sometimes perhaps have this delusion that as you learn more and as you get more experience, you'll get smarter and you'll have better ideas. And like, no, there's tons of people for whom their first idea was the best idea. And I have no... Which many things are when you're building with computers, they are called uncomfortable and annoying. Now, it shouldn't be that most of the time, but occasionally that will be there. And if you have a really strong why, why are we building this? Who is it for? What are we trying to do to improve the world, even if that's not more grand than just letting people love email, it's a lot easier. And it's a lot more enjoyable to then carry whatever burdens you've got to pack if you can set it up that way. This is a good time to talk about our season sponsor, WorkOS. Having a strong why is what gets you to building something great. But after you build it and start selling it to enterprise customers, they expect things like SAML, SSO, directory sync, audit logs, and fine-grained permissions. And those are not small features, they're systems. Systems that can take months to build and maintain. WorkOS gives you APIs that enterprise-ready auth and user management in days instead of months, all designed to fit cleanly into your product. That's why companies like OpenAI and Tropic and Cursor run on WorkOS. Focus on building your product, let WorkOS handle the enterprise infrastructure. With this, let's get back to David and the old way of thinking versus the new way of thinking. Putting your developer hat on, can you talk me through on how you built it? You said it was two years, but was it just one or two people starting to build it? I'm sure as tech, you obviously must have used Ruby on Rails a lot. And then probably some native stuff as well. But the two years seems a lot, especially because you're a small company, you're nimble, you're a great developer. You hire great developers, so it's been two years. What took so long for... And of course, it's a beautiful product, but right on the surface, I think as developers, we might have this thing where I look at it, it's like two years with a talented team. That's the Hacker News quip to basically everything, right? Like, I could have built that in a weekend. I mean, famously stated with Dropbox that I could have built that in a weekend. We could have at the original iPod when it launched, it was like five gigabits, no Wi-Fi, whatever, less speed than Nomad Lane. So I get that because I also have that same instinct. I think that is our hubris as developers. We think we are gods and we can make anything happen in no time at all. And you totally could. You can make a prototype happen these days faster than a weekend, right? Like in a few hours, we should be able to have... Just kick off an agent. Yeah. But figuring out what you actually want to build takes a lot longer. And arriving at something that's worth publishing takes longer still. At least it does for us, and I think it does for anyone who arrives at anything good. And the original Hey construction was just me on the technical side. This is actually how we've started. Majority of our major products is either it's just me, sometimes it's one additional developer, but it's in a tiny, tiny team until we have a shape, until we have an architecture, and we have a direction of where the product is going to go. I've found that you actually go slower if you pour a bunch of people into a direction that is uncertain. If you don't know what you want, a million people is not going to build it for you. You have to figure out what you want. We can talk about this later, but this is where AI's very recent progress is changing things dramatically. It is now quicker to arrive at what do I want. But for Hey, it was me. And then it was Jason and one designer, two designers, very, very small team trying to figure out the shape, trying to figure out if you're taking on Gmail, you can't just do Gmail in blue. No one's going to buy that. No one's going to be interested in that. It's gotta be novel, which means it's, well, not just novel, it's got to be good. It's got to solve problems that people haven't even articulated they have with Gmail. Because the articulation people have of their problems with Gmail is I hate email, which as we talked about, is a bit of a misdirection. My contention is you hate Gmail and not just Gmail, but most email systems built on the old way of anyone has access to the inbox and all that stuff. But figuring that out, figuring the shape out takes a while. And it's also fun to do in this way where you noodle with it and you don't have infinite capacity. The original Basecamp was built the same way. It was just me on the technical side. Is this a shape-up methodology? There's shape-up thinking in trying to actually endow the designer with an intention of how should it work, not just how should it look. And figuring out, it's also how it should look. Products should be beautiful and they should be unique and appealing and so forth. So that also takes time. But figuring out how it should work is primary. Figuring out where's the epicenter, what's the most important part, and teasing all that apart. But with Hey, as with all the major products we've done, we start with an absolutely tiny team, often just one individual on the programming side and then one or two individuals on the design side. And then we go, we go, we go, we go, suddenly something clicks and we go like, this is good. There's something here. And then there's a bit of a ramp. We take on a few more people. And then when we get within maybe the last 20%, we go, okay, now we know what the terrain looks like. We can go way faster if everyone piles in. So one thing that is super interesting and you might take it for granted, but it's very different to how most startups that raise VC money, which I'm very familiar with, and big companies, Uber, Facebook, you name it. The way projects would start there is you take the product manager who works with maybe half a designer and comes up with a spec and then developers get involved later. And what I'm hearing, what is very novel to me is you take one or two designers and a developer. How do you think about designers even? You recently hired a designer, Zoltan, actually, who I'm chatting with on the side. Great guy. But my sense is you think of designers a little bit different than potentially the rest of the industry does. We very much do. Designers at 37Signals are not just here to make a spec look pretty. They're here to find what the spec should be. They're product managers in many ways. They are the finders of the how and the why in many cases, deducing in some cases, customer feedback, in other cases, just pure intuition and distilling that into what should we build and how should it work. And then on top of that, they're also responsible for building it. They're responsible for doing the CSS. They're responsible for doing the HTML. They're quite often responsible or at least dabbling in the JavaScript and the Ruby code to get to something functional. Now, with agent acceleration, they do the whole thing, not necessarily as it will be merged, but the whole thing in terms of here's the final shape and design of what it should look like. But I do think we are very peculiar in this sense. And we have found this when we've been trying to hire designers, that many designers working at other companies are not used to also wearing the product manager hat, figuring out what we should build, and wearing the implementation hat, shaping it into CSS and HTML. I've found that when you combine these three hats into one, you have an individual who knows the materials they're working with, know how they stretch, know which way the seam is supposed to be cut, and therefore works natively with the fabric of the internet. When you're working directly in CSS, when you're working directly in HTML, you're just much more in tune with what this medium wants. And I find that that's probably quite similar if you're a jewelry designer. You should know the properties of gold. You should know how it bends in the strength. An architect should have some engineering understanding of load-bearing structures and so on. Not to the degree that the architect is just going to design the whole thing and then we start pouring concrete. You still have engineers helping you out. But the more you understand the materials you're working with, the more you're likely to come up with something that cuts along the grain and therefore ends up feeling correct, feeling good. Just a quick hop to Apple. I think this is one of the reasons why some of the historic superfans like Derek Fireball and others, Gruber, have been disappointed by the new direction is that Apple used to stand for these exquisitely designed native Mac applications, which is a dying breed. Like, they're essentially dead. Now, we have Electron, which we can talk about that too, gets way too much hate in my book. There's crappy implementations of that, but it's just a web in a box. But the disappointment with The early ergonomics where it was autocomplete, where it was Copilot and Cursor in your editor trying to guess the next character. It would be sometimes littering it, right? Yes, I found it infuriating. I found it as we're trying to have a conversation, you won't let me finish a sentence. You're constantly trying to, was this what you meant? Was this what you meant? You're like, shut the hell up. Can I just finish a thought? And I thought, even if it is capable of occasionally accelerating, it's also wrong so often that that acceleration feels like a nuisance, even if it's somehow net positive, which it wasn't for me, or maybe I gave up too soon, but I just did not enjoy that. I didn't think the models were good enough. I thought the way of using the models with autocomplete versus agent harnesses was just dreadful, annoying. In fact, to the point that I got a little pessimistic about the direction of the industry for a hot second, because I thought this was what we were all going to do. We're all going to sit and do tap, tap, tap. No, thank you. Well, Cursor even have, they had, I even got one of these, one of their swags was a tap key. Exactly. Which felt very, and I haven't, like, I got it from them. It's really cool, very well designed and all that beautiful design. But dystopian. Dystopian. When I see that, and I remember that was a meme for a while, just, we only need three characters on the keyboard, right? I thought of that episode of The Simpsons, where Homer puts a mechanical bird on the keyboard that just dips down and hits enter because all he's been doing is hit enter. Except suddenly there's a warning about the nuclear core overloading, and the bird just hits enter and the whole thing burns down. I'm like, wow, that's quite a parallel. The Simpsons really does predict everything. But I did not like that style of using it, as much as I retained my enthusiasm for the general direction of travel because it truly is amazing. And the amazement to me, I tried to embrace as a tutor model, as a pair programmer who doesn't drive. It was amazing to have ChatGPT and the other models just be there for like, I don't understand this fully. Here's a piece of code. Here's a question. Can you tell me why it works like that? Can you tell me what's wrong with it? Because that's how I've been using the internet since day one, right? That's what Google was for me. Here's an error message. Here's a concept. Maybe I find something on Stack Overflow with some passive aggressive nerd telling everyone why he's so smart. And then at the bottom, there's the solution I'm looking for. Or I don't find it at all, and that's just kind of frustrating. With the ChatGPT model, I very often got a really good explanation. Yeah, this was actually, I talked with a game developer, Jonas Tyroller, who built this really cool best-selling game. I loved playing it. And this was during this time of the tap completion. And he said that in his, the way he works is he just turned off all auto completions in his ID because he got annoyed by it. And then every now and then he went to ChatGPT to ask something or have a longer thing. And then he had the mode of like, I'm thinking and I'm doing this stuff. Oh, I need some help. Okay, here's the specifics. And I'm taking it. And somehow it felt that, you know, like he was in the zone the whole day by controlling it. And somehow those tabs, it sounds like, you know, you're saying the same thing. It kind of took it away from you. Exactly. And I did get a little worried that that was going to be the direction, that we're all going to be the bird, and I didn't want to be the bird. Then I was like, well, what should I do instead? Maybe like farming potatoes? Like that's a long tradition here in Denmark. Maybe I could take that up. But then thankfully, two things happened. A, Claude code in, what is that? Starts in the spring, gets going sort of over the summer. Then by the fall, has some traction on a new way of using agents to help you code with the agent harnesses, right? This is really where we transition from AI to agents. Suddenly the AI has tools. It can use Bash. It can use everything you got on your terminal. It can call the internet in for appropriate information. It just is capable of doing more than just reasoning about a thing you gave it, or input from a source context file. And then the models. Opus 4.5 to me is the other, one of the other points we're going to have on the line, where it's the first model that continuously and consistently would shock me with the quality of its output. The quality of its analysis on the basis of vague inputs. And even more importantly, the quality of its output. It produced code I wanted to merge without very much, if any, alteration. And if I did want to do alteration, I could tell it. And it would remember. And it would not make the same mistake next time. That to me, the combination of those two things was the unlock. And you have a high bar. I have an incredibly high bar. I, as we've talked about now at length, like the aesthetics of the output really matters if I'm going to look at it and I'm going to review it. I'm going to give you another anecdote in a second where those things don't even play in. But when I'm using agents to work on Ruby code, I want their code to look as good as mine. I'm not going to merge their stuff if it's sloppy. No more than I would merge the work of a junior developer who has not yet fully internalized our style and so forth. So I want it to be on par and on parity. And the early models just couldn't. That didn't mean they couldn't produce working software. At least some of the time. They could. Very impressive. I mean, I remember when I did my first snake game and I'm like, holy smokes, I've been wanting to do this since I was six years old. Like I've been wanting to have this idea. I want to get it into a game and I was able to see that in, I don't know, a few 30 seconds. It was done with the game app. Copy paste the HTML. Magical experience, right? So I think that ramp was very interesting because it actually took a while until we found the form factor of the agent harness, of the terminal interface that to me was the big unlock from this is interesting. I want to have a conversation with it to, I want it to write my code. I will now start any project I'm starting with. I'm starting agent first. And that's a massive shift. And it just happened from November 27, I believe, is when Opus 4.5 dropped. Now, there are other people who have different points. They felt like, oh, it was Opus 4.0 or maybe some people talk about Sonnet 3.7. There are other earlier checkpoints, but there, I do feel like there's a general consensus. I can lean up against that capacity and others have expressed, like, yep, it was right around end of November, early December. Everyone who works, works at larger tech companies. It was the winter break because people just, you know, like the whole industry shuts down for two weeks, save for a few places where you're on call. But again, no production work happens across the industry. Now you get to play with this. My sense was that people were playing with it because you give it your side projects you never finish, expecting not to finish. And then they also got shocked. You're done. And that was just a complete sort of break, right? Like if this was a movie, you'd hear the scratch sound. Like, ah! You're like, wait, what? Rewind. What happened? I feel it was the most collective shock, which happened individually. And then people came back in January and everyone, especially because a lot of the decision makers who are, you know, like CTOs, directors, et cetera, were not as hands-on, but they were hands-on. And a lot of them, it's this weird thing where they came back and they started to mandate or like, say, all right, you guys need to use this because I've seen the future. I've literally used it. You need to see it. So we're going back to a little bit of hardware. Like people were trying to give, you know, like the new hardware into people's hands saying, you need to experience it because you're not going to believe it, right? There's something with this as well, where you really don't believe it. We can talk about this and whoever's not tried it or not had that aha moment. I don't think we can convince them. This is another one of those cases where words just are not effective. You need to sit down in front of open code or whatever harness that you use. Use one of the frontier models. Start with that. Start with Opus. I'd say start with Opus. It's the best frontier model. Other models are better at other things, blah, blah. But if you're just going to work on a piece of code and you want to see what the current frontier is, and if you, I mean, I'd be shocked if any of your listeners haven't done it already, but if there should be some left, now is the time. And I don't want anyone to say in the sense I I found it really off-putting, this trend on X where, unless you've internalized everything there is about AI, like you've been left behind. Shut up. First Models? I don't know, but when you experience it yourself on your own damn claw that you just telling over Telegram to do something, and it's signing up for products autonomously, that's pretty startling. It was for me. And then the next time I went like, well, if it can sign up for Hey, and it can sign up for Fizzy, let me invite it to Basecamp. So I send it an invitation to its own email address. Here's the invitation link to Basecamp. Can you just jump into the AI Labs lab project that we have and introduce yourself to the team? Hey, I'm David's assistant. It's very nice to meet you all. I've read back the transcript a little bit. I see you're all excited about these things. And you just go again, what? What? And that was fun because it showed me that even if it was going to take a while, it did take a while. It took a while. This is agent terms. It took, I don't know, seven minutes. That was like, oh, it feels like an eternity. But it was able to do it. And that seems like the end state. The end state is that agents will not need any of our accommodations. They do not need any on-ramp. They're not coming on a little wheelchair. They'll be coming on bionic legs and running five times as fast as you in about two seconds. Which we'll get to in a second to the speed aspect of it. But then you also realize, okay, well, I can't just sit around fiddling my thumbs until AGI happens. Let's build for today. And that's what we've been building for Basecamp. We've been building a CLI. We're gonna build it for Hey. We're gonna build it for Fizzy. We're going to build it for everything, even probably some of the legacy products. And what I love about the CLIs, as much as I also love it about these harnesses, is that they validated the fundamental Unix philosophy from like, whatever, '71. You should just build small tools that can interoperate with pipes and you can put things together. That's the Unix philosophy, right? It's the total Unix philosophy. And that is actually the magic to me about seeing everything having a CLI. It's not that Basecamp is easier to use now with the CLI. No, no. It's that GitHub also has a CLI. And Sentry, I don't know if they have a CLI, but they have an MCP. That you can tie all these things together, and now you can tell an agent, Hey, we have some errors in Sentry. Can you go check them out? Then post a write-up to Basecamp, iterating what's wrong. Then go on GitHub, come up with a pull request, post a comment back to Basecamp when you're done. And now we have a central record in Basecamp where we're following the work as it's going on while we have an agent doing work, looking things up. And again, when we try to talk about it and relate it, I guess some people can see it. And now OpenClaw has enough videos on YouTube and so forth, so you can get at least a passenger ride. But try it yourself with your own product, with your own tasks, and with your own prompts. And you will be pilled. You will be simultaneously incredibly excited for what we've been able to make sand do, the silicon, the chips, the weights, the whole thing, how. And then also a little bit anxious about where it's all gonna go. And it's in that tension that I, and probably anyone else who's been pilled on this, live, right? Wait a minute. If we're already here, what does not 18 months from now look like? Like, if in the last three months, we've upended my entire understanding of what's possible with computers, what does the next three months look like? What does the next nine months look like? Yeah, this is where like, I was a little bit on your end for a long time. And I think I still am, where I believe what works. And I'm always skeptical of projections. Moore's law broke down at some point. I, I lived through everyone said it will continue forever and, you know, and then it broke as we all suspected it would, but then they found another way. I think that's a good point about the Moore's law, right? It broke for individual cores. How much can you push it? And then we just went, well, what if you just had, what's the latest chip? 256 on the AMD Zen chips, right? And even when performance broke, we, we, we went into power consumption and size and all of those things. So yeah, like, but it's, it's harder for me to also just to say, oh, it's going to stop here because we've seen it grow. We, we know the approaches that they're taking, this is larger and larger training sets. And it's been working so far. And there's also the better lesson, which I think, I think is a, it's such a short paper that it's just so worth reading. I think it's one of probably the most popular papers outside of academic circles because it just plays out this thing that we, we don't want to believe that. We want to believe that our knowledge, our understanding is superior. That, you know, you and me knowing how to code or me putting in these 15 years or however long it's been, it's special. Sometimes it shows that it's, it's not as special. What's interesting actually is like right this second, this snapshot in time, it a little bit is. And this is a funny provocation that's happening, junior versus senior developer, is that the most successful and applicable agent acceleration that I've seen at 37signal has been from the most senior people. The people who are able to validate whether what the agent produces is suitable to be deployed to millions of people. There was just this story yesterday about some of the major outages at Amazon, and Amazon's own internal analysis essentially pinned that. We can no longer let junior programmers ship agent-generated code to production without review. And the problem with that is, first of all, I think that's the realization that most companies are now having across the industry. Whenever it's mission-critical for something of that nature, we cannot yet rely on the agents to have vetted it all and junior programmers are not capable of figuring it out. Therefore, the role is suddenly more tenuous than it was six, nine months ago. Because a senior programmer can. And this is why senior programmers are getting so much more acceleration. They're able to, first of all, work in parallel with lots of agents, but critically examine the quality of the agent output and have a high degree of confidence of whether this is gonna work or not, or redirect them if not. Because this is what made them senior in the first place. This was the role that they had, that they had the long insights and history and overview of the architecture. How does it all fit in? Is this gonna work? Is this not gonna work? This was the role they played to junior programmers. But now they can play that role to agents. And agents are faster at following instructions and redirections. And suddenly you have senior developers who can 5x, 10x their individual productivity. And now, this is the second order effect. If you manage to 5x or 10x a senior developer, that person's value per hour just went up 10x. Now, take that hour, instead of that person spending it with the agents, just shipping stuff and making things better. They spend that hour as they would before teaching a junior human how to do things better. There's something in that equation that's in play right now and it's not clear how it's gonna map out. Now, one way it could map out is that the agents will get so good that they stop making mistakes. They become senior in their capacity to ship working code. This is what my bet would be if we look X amount of time forward, because this is what just happened with cars. So self-driving Teslas now drive better than humans do. Not all humans, not in all circumstances, but on average. It's very possible that if we're able to delegate the mortal risk, the highest criticality we basically deal with on a daily basis, sitting in a metal tube along other metal tubes that go 60 miles an hour, where you can die if someone makes a mistake. We delegate that to an agent, well, they can probably figure out how to make the code work too, right? So I do think it's coming, but who knows when, who knows how. Right now, we're at a stage where the bulk of the benefits are accruing to the most senior developers. And also, I wonder, just like with self-driving, like you realize there's always kV. So for example, inside companies where it matters, when you're a startup, you have zero customers. It doesn't matter. You can one-shot it and it doesn't matter if it doesn't work and it crashes. But inside these companies, at Uber, just got details on how they're adopting AI and they have all these tools, Claude code and all of these things. But what they realized is, well, when you just put it in there, they have all these internal monorepos. They have their ticketing systems. They have their Slack. They have so much. They have their RFCs, design documents on how and why they have this jumble of a mess with microservices, which was a fun way that we were originally connected, like many, many years ago. But what they found is they built a bunch of internal systems, a lot of it to help to feed into these agent harnesses. And now they're working better. But where we are right now is there's, and this is why. Between 25% things I then just realized, I just don't want this. It shouldn't, we shouldn't have it. And 25% Claude telling me, maybe there's something here, but it's really not a good implementation. We don't have a straight shot to making a great one. A hundred issues in 90 minutes. And I sat back, this would have been a week's worth of work, days at the very least. What the heck? And even more than that, Claude's analysis of at least half the issues pertained to things I knew nothing about. Where it was undeniably a smarter, better reviewer, programmer than I could ever dream to be. But not dream to be. But was in that moment. But you would have not put in the effort for those areas. This was why the PR sat in the first place. In many cases, I would look at it and go like, I think there's something here, but like, then I now have to read up on this D bus thing. I have to figure out, is this the right way of doing it? I don't want to just merge something that then has other issues. And to be able to do that, agent accelerated was one of top 20 programming moments. I like how you put agent accelerated. And it sounds like, it's especially efficient for work that is waiting on you, but you don't want to do it or you're not as skilled of doing it, but it's a hassle to delegate. Because again, you have a team, right? Yes. But you probably didn't delegate it because you probably knew that it wouldn't make it faster or better. So I, I wonder if there's a part of AI that, because we talk a lot about like, you know, like companies love to measure, especially larger ones like efficiency, PRs, and they want to see impact, but about the impact of doing work that we would have not done before. That's the kicker for me. That's the fact that the pie is just exploding right now. It's not growing. It's exploding. The number of projects we have tackled internally that we would never even have contemplated starting on are legion. We had a great project where normally on performance work, you worry about a P50, P95, P99. Jeremy, one of our most agent accelerated people, went like, what about P1? What about the floor? Can we fix the floor? What is the floor? And he went like, well, right now our floor is, I forget what it was. Four milliseconds. Let's say that, right? Well, actually four milliseconds can add up if you have a bunch of fast requests, they can still, it still matters. And he just went like, we're going to do P1. We're going to optimize P1. Literally the fastest 1% of requests. We're going to make them even faster. He took it from, I think it was four milliseconds to less than half a millisecond. He 10Xed the performance. I was like, I would never have signed up on this. And he did the P1 project over a couple of days as like a side chef. Because now he could. Now he could. Because he had a hunch. He had an intuition that there was something here. He let agents run with it. And the number of PRs that like, all right, we'll fix this. We'll fix this. I think total the PR, the P1 project, I may be misremembering, but I think it was like 12 PRs. Like just fixing all sorts of things where I look at the single PRs. I'm like, yeah, actually. Okay. Yeah. Makes sense. I look at the total sum of it. You've changed 2,500 lines of code. You're like, you've done that in a few days. So I wonder if there's a part of AI that, because we talk a lot about, like, you know, like companies love to measure, especially larger ones, like efficiency PRs and they want to see impact, but about the impact of doing work that we would have not done before. That's the kicker for me. That's the fact that the pie is just exploding right now. It's not growing. It's exploding. The number of projects we have tackled internally that we would never even have contemplated starting on are legion. We had a great project where normally on performance work, you worry about a P50, P95, P99. Jeremy, one of our most agent accelerated people, went like, what about P1? What about the floor? Can we fix the floor? What is the floor? And he went like, well, right now our floor is, I forget what it was, four milliseconds. Let's say that, right? Well, actually four milliseconds can add up if you have a bunch of fast requests, they can still, it still matters. And he just went like, we're going to do P1. We're going to optimize P1. Literally the fastest 1% of requests. We're going to make them even faster. He took it from, I think it was four milliseconds to less than half a millisecond. He 10Xed the performance. I was like, I would never have signed up on this. And he did the P1 project over a couple of days as like a side chef. Because now he could. Now he could. Because he had a hunch. He had an intuition that there was something here. He let agents run with it. And the number of PRs that like, all right, we fixed this. We fixed this. I think totaled the PR, the P1 project. I maybe misremember. I think it was like 12 PRs. Like just fixing all sorts of things where I look at the single PRs. I'm like, yeah, actually. Okay. Yeah. Makes sense. I look at the total sum of it. You've changed 2,500 lines of code. You're like, you've done that in a few days. So I wonder if there's a part of AI that, because we talk a lot about, like, you know, like companies love to measure, especially larger ones, like efficiency PRs. And they want to see impact. But about the impact of doing work that we would have not done before. That's the kicker for me. That's the fact that the pie is just exploding right now. It's not growing. It's exploding. The number of projects we have tackled internally that we would never even have contemplated looking before is funny. I remember this scene from Terminator 2 where they found this chip from the Terminator in the first movie. And he goes like, this thing gave us ideas we would never have investigated before. And I'm like, there's some beautiful parallels here about like, maybe we're about to build the Terminator, the cliche. But also, we're getting ideas. We're getting ambitions. We would never have looked at before because suddenly the cost of exploring a hunch has just dropped by a 1,000 fold. I do this all the time now too. I'll give it some big, crappy instructions. Just because like, I have this fleety idea. I haven't even crystallized it into a neat prompt. I just want to see something. It'll, and then I go like, oh yeah, delete. As in revert code back to normal. I was like, before I would be a little more precious about 75 lines of code because it would have taken me two hours to do them. Now there's no residual value to any of this stuff. And I can just go like, uh, show me a draft. I feel like a little bit like a king where you just go like, show me the, the analysis of the far front regions. Where are we with the tax? And this boy is like, this servant is like, yes, I shall do so and return in three weeks. Except like you can just wave your hands around and agents just come back with answers to stupid questions, terrible ideas. Then suddenly it wasn't so terrible. It's actually a great idea. And you go like, wow. I did this with Umatra. I haven't even pulled the trigger on it yet. But one of the things with Umatra people have been asking for since the beginning is dual boot. Being able to install Linux next to the windows installation so that they can still play all their games. And I just went like, you know what? I have more than one computer. So when I'm play, play games, I can just do it on the PC. It's not a me problem. Yeah. I totally get why a bunch of people want it. I'm not heavily inclined to spend four hours figuring it out. And I just, a little while ago went like, Oh, this is exactly the kind of problem. Like I don't have to figure it out. Just make the agents figure it out. So I kicked off initially the process of just coming up with a plan. This is a pretty big change, right? Like if you fuck up someone's boot records or you overwrite their petition, criticality high, which is one of the reasons I didn't want to engage with it. Secondly, it's a little finicky if you want a Lux encryption on the Linux partition, but the Linux partition doesn't own the whole drive. It's a little hairy. I didn't want to take on the criticality. I'm like, this is perfect for the kind of agent stuff. So it started off basically just having Opus and Codex ping pong a plan. Like I'll just, I asked Opus first, like, come up with a plan for this. It thinks for minutes and minutes and then come up with a good plan. And then I kick it over to Codex and like critique the plan. And then I had him ping pong back and forth a couple of times. And at the end, looking at the plan, go like, yup, that's a good plan. We should totally do that. And I You want to sit and code, you have to be John Carmack levels of good to retain that privilege, to just, I just want to sit and code. And even John Carmack, I mean. Yeah, of course, is also super AI-impelled and leading in. Well, but also, like, he also saw some trends that he could do. Like, for example, like, just like, you know, the type of games that people would buy, right? Like, he needed to have some business skills or just surrounded by people who did that. Totally, totally, totally. But like, you need to literally be the very best. And not just the very best, but you need to be better than the agents, right? For you to get the privilege to just be an implementer, you have to be better than what's available off the shelf from agents. So who are the very best? And you're a good person to ask, because whenever you advertise a position, and this was even well before AI, I remember that you, you put out a job for both a software engineer and a designer, and actually, I want, I want to interview your designer who you hired. And because you published the salary, which is a San Francisco salary, you put the exact number, you can check it for it. You have a social media presence, so it's kind of goes wide and you get a lot of applications and you do a pretty good job, as I understand, you try to be very fair. You put a lot of effort into it. So what did it take to get hired at 37signals? Because now you are trying to hire some of the best. And based off of this, what advice do you give to people who are like, okay, I want to be the best in this age right now? Incredibly good question. No one has figured out, we haven't cracked it. And I say that as someone who have run an organization where we must have looked at tens of thousands of, now of course, if you're running Google, you've looked at millions. But we've looked at tens of thousands of candidates. The number of candidates we've hired is quite small. I mean, total number of programmers that have been through 37signals over its entire lifespan was that gonna be like, I don't know, a hundred, 150 at most. I haven't even done the math. How big is your team right now-ish? We're 60 people at the entire company and we are, what's that gonna be, like 20 programmers, something like that? Yeah, that's probably about right. Oh, so, so who, what is the other, other 40 folks? We have designers, probably 10 of those. And then we have customer support, which is at 14. Then we have a bunch of support functions, HR, finance. And then we have operations. Operations is quite large. We have 10 folks managing all our servers. And yeah, that's about it. But yeah, I probably, it's probably about a hundred people in total that I've worked with or employed at the company as programmers out of tens of thousands. We've looked at. And even all those hires did not pan out in the longterm. Like I'd actually say, I think I looked at this recently. Our batting average at best, I think is slightly better than 50, 50. So half of even those hires… Add, have to go through all of it because you have a really long, thorough process. Yes. You, you, you put in a lot of effort, right? No one has figured out just to hire with such efficiency that they don't make mistakes. There's a great paper that Google published quite a long time ago now where they tried it also to do with my hypotheses. Well, can we predict employee outcomes on the basis of Ivy League education background, on GPA, on all of these things? The conclusion was basically like, we know nothing. We can't predict it on any of these things. We can't predict it on LeetCode. We can't predict it on any of these metrics. Now, what I'd say is I've clearly been spoiled by working with some very good people, not just at my company, but in open source in general. Yeah. Oh yeah. And therefore I've ended up with occasionally a twisted perspective of what the average programmer is capable of. And when we do hiring rounds, I am sometimes, well, not sometimes, every time I'm kind of surprised how poor the majority of the submissions are, how little effort is put into being presentable. And that can sound really boomer, crotchety very quickly. But it's also just the reality of trying to get a job. Like you've got to stand out. And I understand that that's uncomfortable, right? Like who wants to look at this as like, well, the odds are kind of against me. But it's also a trap to actually fall into thinking of this in terms of odds. Because what I've seen the miscalculation happen time and again is people go like, okay, so you have a thousand applicants. There's only one who gets the job or maybe two who gets the job. So that's 0.1% chance. No, it's not. Not at all. With that math, you had 0% chance. Zero. And the very best, they probably had a 10% chance, 20%, 30% chance. It is not equal distributed. It is not a lottery. We don't just like pick a thing out and be like, oh, it's going to be this person because they happened to be the one drawn from the bunch. Not at all. We discard off the bat probably at least half the applications. Maybe it's two thirds. Just because they're either not addressing the job directly, they are not following the instructions in the relatively clear spoken, written openings that we have, right? They're obviously not right for it or whatever. Or we get some other smells. Then there's like perhaps a third left. And then we start looking at some of the submissions. Then we narrow it down historically to a pool of around 20 people that we give an at-home test. The at-home test is wonderful. Some people hate it. They feel like it's free labor. I'm like, what the fuck are you talking about? I'm not gonna use your submission to a code test. I'm going to deploy to production. How do you think we came up with that code test? Because it already exists in the system. I say that a little harshly. I also get the sympathy of like, I don't want to put six hours into making a test if it's not going to go anywhere. Okay, I get it. But there's no way around it. Because if you have it in your head that you just send in a resume, someone's going to call you up on the phone, have a 30 minute conversation with you and go, you hired sir. I don't know if that ever existed, but certainly does not exist today. It never existed in the lifetime that I've been in this business. Well, the only time it exists, right, is through a very warm referral where you're starting a… If you're skipping, if you're skipping the whole pipeline. And when you skip the whole pipeline, it typically only happens at the very beginning of a company when you're founding a company. And often it goes both ways where it's very risky. And then you see like, this buddy of mine, I worked with this person for two years straight. I would like trust them with my eyes closed. So that's actually the black pill on the whole hiring process. If we look at the long-term success rates, we have had more long-term employees from I've worked with this person for two years, we should hire them, than we have from the open calls. It is actually exceptionally difficult, has been for us, to find the kind of programmer who thrives in our environment from open call. It has happened. We have hired people that way. And I continue to want to believe, even if the odds seem insanely long. When you start doing the math of like, oh my God, we've looked at tens of thousands. And how many of them got hired and how many of them didn't work out. Like, Jesus. There's only like a handful left. I'm starting that. That that's kind of blackmailing. But then hiring directly on the base of a warm referral, as you call it, has worked very well. And that, the hit rate there is really high. But how does that help anyone, right? Like, that's not a very actionable advice, except that's to say, get as good as you can get and put in as much effort as you can and work with someone. Because I want to say that as a counter. Some people have this notion in their head that if they work at a place they consider shitty, they shouldn't try. You're shooting your own feet, buddy. If you show up at the shitty place of work, and we can even be objectively in unison about that, that it is a shitty place of work. And you then go like, well, I should just try to skirt. I should just try to goof off. I should just try to read X or Reddit all day, right? Everyone else you work with, they're going to watch that. You know where that warm referral is going to come from? It's going to come from someone who worked with someone else at a shitty job, but identified that that individual still showed up and did as best as they could to learn, to ship, to do all of this stuff. There is no shortcut here. You'd simply just have to be good. And you will not get good if you do not practice. And if you think your place of employment is not worthy of your best, you're cheating yourself. If you're not helping, even if it's a shitty place, if you're not helping that place get better, why would a great place hire you who only hires people Steve Yaghi, he was, he looks a bit more drained than you can see it on the video, but he's honest. Like he's being pulled into this. He's doing, he has friends who are, and when you're on the edge, you're there. You've clearly been AI-pilled, but how are you finding of keeping a balance of like, all right, stepping away, you know, like I know you've, I think you previously talked about the importance of sleep, but apparently you don't have an alarm. Greg, I don't use an alarm, although my wife now does because the kids need to go to school on a regular basis. But yeah, for me, eight hours a night is the best investment you can make in your own cognitive capacity. So I just am reminded every single time I do not get eight hours that it is such a poor trade. If you go from the eight to the six, I go like, well, I'm gonna be awake for, in that case, 18 hours. What is the drag I'm gonna carry for all those 18 hours for getting one more hour, two more hours by cutting back on the sleep? It is such a bad piece of math. It makes no sense. Now, occasionally it's involuntary. I have actually had, especially around this AI stuff, I've had a couple of times, very rare, I can count on two hands the number of times where I've been sleepless. Like the brain racing a little too much. That's not typical for me and it's still not typical, but I have had a couple of them, right? So I get where some of that excitement comes from, but I'd also say the last thing you should trade is sleep and then you should not trade your health. You should not try to save the three hours a week of working out to do more agent work. That's a very poor trade. Keep in good condition. Like there's nothing that's gonna be more important if you wanna keep like sharp up there that like the rest of the system is operating, if not at peak capacities, then at a good sustainable level, right? And I do think there are some individuals right now who are at fear of running ragged on something that we're gonna be dealing with for like, slow down, buddy. Like it's not, again, limited sale. The next 10 years, we're gonna see more and more, it's gonna get crazier and crazier. So don't squander your health. Don't squander your sleep. Don't squander your diet in the service of anything because even on the short term, it does not work. You cannot get more productive within three weeks, let's say, by trying to cut back two or three hours of sleep every night and then think there's anything coherent left after three weeks. You will be a hot mess. So let's close. We talked about the stuff that we don't know, a lot of things we don't know, but let's close with what you do know. So you could have retired a long time ago and just, you know, kicked back and like listened to birds. What is it that keeps you doing, keeps you building, keeping, getting up every day? And before AI, you would open your terminal. I think you shared like, like you would go in and write. Now you're doing with agents, like what drives you? And looking ahead, like what, what are things you're excited about? My drive continues to be a deep love of computers. This is simply the best way, the most fun way to spend my time. I could spend my time on a lot of things. I do spend my time on a lot of things. I don't just do computers. I drive race cars. I take lots of time off. I have three kids. We enjoy all of that stuff. But if I'm gonna fill eight hours every day with an activity, my best bet is computers. And it has been so since I was literally five years old, whether it's video games or what now feels a little bit like a video game, actually, instrumenting all these agents and playing a little bit of Starcraft with uh moving them around and... Yes, exactly. So I just really like computers. So whether I need to do so for economic reasons or not, I will continue to play with computers, see what makes them tick, and make things. I think that's the other big misconception that some people have about wealth, is that they conceive of it as some sort of checkpoint. Like once you've made it, then you can just kick back and leisure, as though that was happiness. We simply have a hundred years of psychological studies telling us, no, that's misery. If you have all the time in the world and no purpose, no mission, leisure is not gonna cut it. It's not gonna be fulfilling way. And this should be obvious by example of literally every entrepreneur who sells their business. They sit on the beach for three weeks and then they're back into the game, right? Because this is actually not just something they do in pursuit of a goal. It's the goal itself. It is the mission itself. It is the satisfaction. It is the affirmation of being a human that I'm not just a blob laying around. I am a useful individual who put my skills to the best use possible. So I'm gonna continue to do that. And I'm gonna continue to do it whether I'm sitting typing at the keyboard, whether I'm instrumenting these agents, whether they're teaching me however, which way it is, I wanna play with computers. I wanna continue to do that. And then even more specifically, after the last three months, I'm leaning in hard now with agent accessibility, for example. This is what I've been doing last few weeks. We've been working on the new CLI, which also taught me, like, we're not quite at AGI yet, right? You think like, well, just ask the agent to make a CLI. It will, but like, it's not quite there, right? Like I want it to be just right. And the agents still need a little bit of help. I'm very happy to provide that help to these agents and we'll release a great CLI for Basecamp very, very shortly. Maybe by the time this is out, it'll probably be out and for the rest of them too. And I wanna lean into all of this. How can we use this as much as we possibly can? And then right now, I'm also just an incredibly curious person. I wake up every morning. I have a new ritual, which is not to pull my phone up and start hopping on X. Like right when I wake up, I don't think actually that is great, but it takes a tremendous willpower to not do so because I'm just so curious about what happened. There's so much happening right now. I wanna know. I wanna know. I wanna be enjoying it, be a part of it. So I don't foresee that ending. I don't foresee a love of computers evaporating. In fact, if anything, right now, I'm seeing like a flourishing of it. I'm liking computers more than I did five years ago. And that's amazing. Amazing. David, this was awesome. Thanks a bunch. All right. Thanks for having me. This was really great. This was a fascinating conversation and I love the energy that David has. I hope some of his energy that is obvious in person also came across to you. I really appreciated that David was open that his stance did not change about AI because his philosophy changed. It's just that the tools became good enough to do useful stuff. AI for autocomplete was annoying for experienced developers. AI agents that can produce pretty good working code by themselves, on the other hand, are now pretty useful. And yet David kept coming back to taste, judgment, and craft. He wasn't just saying, just let the model write whatever. It's the opposite. He has a very high quality bar and he wants the output to be code that he would actually be proud to merge. It feels like AI might make good judgment even more valuable than before. I also really liked how David thinks about the importance of design. At 37signals, designers help figure out what should be built, how it should work, and increasingly even decide how it gets implemented. I wonder if 37signals is a step ahead of the industry in thinking about designers a bit like developers as well and developers a bit like designers as well. Finally, I found David's take that we might have hit peak software engineer, an interesting argument. David thinks we'll produce more software than ever, but his observation is that we might be nearing the end of the time when developers could command high compensation simply because they were the bottleneck. My two cents is that there will surely be high demand for professionals who can build profitable software, but this will mean software engineers who are not only good at coding or using AI to generate code, but can oversee building complex systems, have taste and business sense as well. If you'd like to hear more from David, check out a bonus episode with him linked in the show notes. Also check out the show notes for related, the pragmatic engineer deep dives on software craftsmanship and practical ways of building software. If you've enjoyed this podcast, please do subscribe on your favorite podcast platform and on YouTube. And a special thank you if you also leave a rating on the show. Thanks and see you in the next one.