DHH’s new way of writing code

25:30So there are way more people working on that quality of it. But at the large companies, it's exceptionally rare to non-existent, to have that kind of dynamic. I think some of that is going to change. 8-gen acceleration is going to empower designers to be more capable in these ways. So the industry is coming a little towards our fundamental stance, which is funny, too, because the same is true on the programming side. When I talked about Basecamp being a product of just me on the programming side for launch, that for so long sounded unambitious or even wrong or even to the point of lying from some quarters of the Internet.

26:10And we're like, yeah, but you can't build anything real, anything meaningful, anything big unless you have a team that's much larger because it's just going to be a toy product, right? And my insight from the start was that's, of course, bullshit because you just haven't used Ruby on Rails. You just haven't used the acceleration that's possible if you use better tools. Now, we're all realizing that. We're realizing, oh, so if you use agent acceleration, a single individual actually can build something highly valuable. That needs to take a team. Yes. And that's just fun to see that the industry is coming towards, oh, smaller teams are better because now the cost savings you have on the logarithmic curve on communication cost starts to be relevant.

26:53And this is one of the things, maybe we can talk about this, where agent acceleration is really changing the bargain between junior developers and senior developers. Let's talk about this. But before we go into that, do I feel that you very much value software engineering as a craft, which is very obvious. But what I'm sensing is you're valuing design, user experience design, designing on software design, like, you know, like building stuff that feels good. May that be software, hardware. You also value that as a craft and you look for it. Like these two things. Do I sense this correctly? I mean, I think aesthetics is truth.

27:31When something is beautiful, it's likely to be correct. I think this is true in mathematics. This is true in physics. This is true in a lot of different domains that when you arrive at something that has the correct aesthetic quality, it's like we have an intuition that guides us towards that level of beauty because it also happens to be correct and noble and something to aspire for. I also happen to believe it's what makes people happy. Being surrounded by beautiful, well-functioned objects is a key part of happiness. In fact, I'll put it in a negative way too. One of the great sources of anxiety and frustration is when everything is shit, when everything is laggy, when that touch interface doesn't register, when you have to restart it, When you're calling a travel agent, they can't do something because their old shitty copal system won't let them, right?

28:26The world is full of not just in shittification, that is things that went from being good to being bad, to just plain bad, just plain awful. And I think it is a serious source of malaise for civilization, that we could literally raise the bar of human happiness if we were surrounded by more beautiful items, more beautiful systems, both in the sense of its aesthetic exterior qualities, but just as much in terms of its aesthetic interior qualities, because I find those two things are usually in perfect harmony. The reason why Steve Jobs cared about the inside of the box was because he intuitively knew that the kinds of people who care about the layout of the print board will be the kind of people who sweat the details on the user interface, will be the kind of people who sweat the ergonomics of opening the case.

29:21So I think there is essentially no choice if you are a person who is attracted to this aesthetics, which I think is everyone. There's just varying levels of awareness about whether you are or not, but that you want to make it all beautiful. And for me, Ruby in particular has been this seminal language because it produces the most beautiful code. In my book, there's barely even competition. There are other things that can be beautiful in a way. I find looking at small talk, for example, very beautiful in its minimalism, but not the house I want to live in. Ruby is the house I want to live in because it's got that aesthetic quality while not being rigid about its ideology, which is a very rare aspect too.

30:09I more often find, now we can refer to Ive again, is that when someone is obsessed in this way, they are a little narrow-minded. Like that's the trade-off. That's the price. And I find that Ruby has somehow managed to be both broad scoped, yet also intensely focused on this. But overall, we have to have beautiful things. We have to work with beautiful tools. We have to produce beautiful, fluid interactions. This is how we should see ourselves as craftspeople, that we care about polishing it until there are no splinters left. how is ai changing how you work and how do you think it's changing your craft or just let's just talk about the craft of again you're you're hiring people in 37 signals who similarly care about design and software crafts quality how is changing what you get out of the craft or how it's how it's making it better or or worse in some ways i i just want to you know start with like how has your view changed because the last time you you talked in length about this that was on lex friedman's podcast and you were still rightfully so very skeptical of of ai it was a different set of tools it didn't work as well and i think you went there bashing it pretty hard but things have changed since this is a nuanced point and maybe it's self-serving but i don't actually think my opinions have changed what have changed is the circumstances and the facts which uh is is something i called out on that joe and in many other writings was right from the get-go i could see that we had something new and novel here that was going to change things.

31:45ChatGPT, its launch, what, three years ago, was clearly and obviously, even at the time, something you would mark on a timeline. You're like, here are all the important things that happened in the history of computer science or the world, yoinks, there's the launch of ChatGPT. And interacting with computers in this way and seeing them reason, even if that's still a disputed term, perhaps, But to me, it seemed obvious that these things were freaking smart, smarter than me in many ways. Whether those smarts came from parenting weights and data relations, so what? We don't know how human consciousness works.

32:23We don't know how human wisdom or intelligence works, barely. So let's not be so categorical about what constitutes consciousness or intelligence. At least I find no utility in that distinction, even if it's fun to ponder. But what I found with the early models and the early ergonomics, where it was autocomplete, where it was co-pilot 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 the sentence. You're constantly trying to, was this what you meant?

33:01Was 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.

33:40We're all going to sit and do tap, tap, tap. No, thank you. Well, Cursor even had, they had, I even got one of these, one of their swags was a tap key. Exactly. Which felt very, and I haven't, 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 answer and the whole thing burns down.

34:24I'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?

35:00That'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 love playing it and this was during this time of the tab 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 I went to chat GPT 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 And somehow it felt that, you know, like he was in the zone the whole day by controlling it.

35:50And somehow those habits, 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 can take that up. But then thankfully, two things happened. A, Cloud Code 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?

36:26This 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 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. its 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 and you have a high bar I'm an incredibly high bar.

37:35As we've talked about now, at length, 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 wanted 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.

38:09They 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. I'd copy, paste, the HTML. When you do your first. 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.

38:47I want to have a conversation with it too. I wanted 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 I do feel like there's a general consensus I can lean up against that Kapathi and others have expressed. Like, yep, it was right around end of November, early December. Everyone who worked 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.

39:33But 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 project. You never finish, expect 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, 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, director of engineering, 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 start to mandate or like say, all right, you guys need to use this because I've seen the future.

40:15I'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.

40:47I'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 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 to say in the sense 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 of all, patently not true. You could literally pick up everything in the next three weeks.

41:17This is the other magical thing about this kind of project, right? Or progress. when if we'd been having this conversation in spring of last year, everyone'd been like, MCPs, MCPs, MCPs. And do you know what? You can now manage to just have jumped over that entire thing and go straight to CLIs and skills. That's just worth having in mind that this FOMO, that unless you're up on all of it as it happens, play by play, you're left behind is complete and other nonsense. That being said, I can still appreciate that some people were early. And for me, Toby Lutke at Shopify is the main individual who saw this and saw the changes that were coming from it way earlier than I did.

42:02And it really helped drag me into this by constantly sending me like, hey, look at this, look at this. And I do think that's actually quite helpful. It's quite helpful to be surrounded by people who have a higher faith or maybe their eyes are a little further up. My eyes tend to be relatively close to the road, like right in front of me. And some people have a gaze that's a little higher up. And sometimes they see things that don't come to pass. In this case, Toby saw exactly where we were going two years ago. And I finally saw it because the road came to me in December. And it's funny because along the way, I kept saying like, yep, when the models get good enough, when they can do all this thing, it's going to be amazing.

42:44and thinking, well, it's going to be, I don't know, 18 months, two years, maybe it's five years. It's very hard to predict these infliction points. And I think the industry itself didn't even predict the infliction point, right? You have an entire city, Silicon Valley and surrounding areas of San Fran focused on making this happen, but predicting exactly when the hockey stick starts hockeying is very difficult, but then it happened. And now my daily work is very different. So what is your daily work now? My daily work is agent first on everything. Going agent first is a good time to mention our season sponsor, Sonar.

43:25When shifting to agent first work, one thing that inherently comes up is the quality of the code. Sonar, the makers of SonarCube, is deeply rooted in the core belief that code quality and code security are inherently linked. High quality code is naturally more resilient and as agents start writing code at a massive scale, that verification layer becomes your most important security parameter. This is where solutions like SonarCube Advanced Security are valuable. With this new malicious package detection, Advanced Security provides a real-time circuit breaker, automatically stopping agents from pulling in unverified or risky third-party libraries before they ever hit your pipeline.

44:01The impact is measurable too. Developers who verify their code with Sonar are 44 % less likely to report experiencing outages due to AI as per Sonar's State of Code Developer Survey 2026 report. It's really about closing the gap between the speed of AI and the reality of production security. What else is Sonar doing to help reduce outages, improve security, and lower risk associated with AI and agentic coding? Head to sonarsource.com slash pragmatic to find out. With this, let's get back to David's agent-first workflow. Specifically, cloth code. I use OpenCode as my main harness. I also use CloudCode a little bit.

44:35They unfortunately got that early lead. Opus is currently the best model. So then they started thinking a little bit in that, like the game is single match instead of thinking it's multiple rounds and yanked their subscription from OpenCode. So if you want to use your Mac subscription, you kind of have to use their harness, which I don't love it. I think it's a mistake, but leave that be for a second and let's just celebrate the fact that they have the best model And Opus 4.5, 4.6 is also nice, but 4.5 to me was the infliction point. And it creates a lot of composition because everyone wants to catch up and overtake them now.

45:08Of course, of course. And especially because you see Anthropics revenues. I think started the year, they're at 9 billion. A few weeks later, they're at like, whatever, 14. Now they're at 19 or something. It's just the craziest rocket ship you could possibly imagine, which is inspiring all this capital to be deployed for competitors and so forth, which is wonderful. Great to see. So even if I don't love everything that they do and Cloud Code is not my preferred harness, manage to hold two things in your head at the same time. This is what I also try to do even with Apple, which I have serious griefs about how they operate and act as the gatekeeper and all the other nonsense we've talked about.

45:43And then I also keep my I just love computers hat on and go, I like the new Neo. I might even buy a new Neo and just see what is possible at$500. For Opus, I have no qualms about using Opus. In fact, whenever I feel like, this is a really hard problem, I go to Opus right now. But I also use other models. And one of the things I've incorporated into my flow is to kind of have two models going at the same time at different speeds. So I use TMux and I have this layout thing that's built into Amachi where it'll start my NeoVim editor on the left side and then it'll start two panes on the right side.

46:21On the top is OpenCode running KimiK25. And on the bottom is Opus running in Cloud Code. And then at the very bottom, I have a strip of terminal. And almost everything. I started in one of the agents. And I tell them what I want. Then I hop over to NeoVim. First, I do a space GG to look at the lazy git diff on it. What is this changing? If it looks correct, I'll just commit. We're done. Great. And then sometimes it doesn't look correct. Then I'll go in and also decode myself. But the ratio and how quickly the ratio changes is still astounding. I went from early November last year. I'm code first everything.

47:04I started the editor. I'll spend whatever long it is. And then at some point, if I get stuck or if I want a second opinion, I'll go ask my friendly clanker to give me a second opinion. That's just not how it is anymore. Now I start with the agent. Now it'll give me the draft. I'll review the draft and I'll make alterations if need be. And then just recently, I flipped it even further. So we're working on a CLI for Basecamp so we can get full agent accessibility for Basecamp. It's astounding. First, actually, let me rewind. As soon as I got pilled on how good the agents were and how capable they were, I immediately tried to raise my gaze up towards the end of the road and think, do we even need MCP?

47:50Do we even need CLI? Do we even need anything? Can't the agent just figure it all out? This was when I installed OpenClaw. So I installed OpenClaw on a VM. And I thought, what should I do here? Let's see how far we can push it and what it can do by itself. So I thought, I want this claw in Basecamp. I want this claw in Fizzy. Let me just try to invite it as it was a human. So I just wrote it. Can you sign up for Fizzy? I'm not giving you any tools. I'm not giving you any MCP. I'm not giving you a CLI. I'm just telling you, it's at Fizzy.do. Go sign up. And you see it, chuck along. And then, yeah, I've signed up, but it's asking for an email address or I'm trying to sign up.

48:27It's asking for an email address. I'm like, oh yeah, right. You need an email address. An agent doesn't have an email address. Hey, go sign up for hey.com. I'm like, it's going to fail this one. And it's chuck, chuck, chuck. I've signed up for hey.com. Here's the password. Write it down somewhere safe. I'm now also signed up for Fizzy. I got the confirmation email in my inbox. We're all good. What do you want me to do? I'm like, what? Are you telling me that you could one-shot signing up through a browser to these things? Now, maybe that shouldn't be surprising. Maybe that was already possible with Sonnet 3 or one of the early models.

49:03I don't know. But when you experience it yourself on your own damn claw, that you're 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 step I went, well, if it can sign up for Hay, it can sign up for Fizzy, let me invite it to Basecamp. So I sent 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.

49:39I see you're all excited about these things. And you just go again, what? What? But, 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, too, the speed aspect of it.

50:17But 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 going to build it for Hay. We're going to 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.

50:47It'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 a 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 in GitHub, come up with a pull request, post a comment back to Basecamp when you're done. And now we have a central write-up in Basecamp where we're following the work as it's going on while we have an agent doing work, looking things up.

51:27And again, when we try to talk about it and relay 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. And then also a little bit anxious about where the talking to go. And it's in that tension that I and probably anyone else who's been pilled on this live, right?

52:09Wait a minute. If we're already here, what does 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's the next three months look like? What 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 lived through ever and said it will continue forever. And then it broke, as we all suspected it would. But then it found another way.

52:39I think it's a good point about the Moore's Law, right? It broke for individual cores. Yes. 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 went into power consumption and size and all of those things. So, yeah, but it's harder for me to also just to say, oh, it's going to stop here. because we've seen it grow. We know the approaches that they're taking is larger and larger training sets and it's been working so far. And there's also the bitter lesson, which I think is such a short paper that it's just so worth reading.

53:14I think it's one of probably the most popular papers outside of academic circles because it just plays out this thing that we don't want to believe that. We want to believe that our knowledge, our understanding is superior, that 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 not as special. What's interesting actually is like right this second, this snapshot in time, a little bit is. And this is a funny verification that's happening junior versus senior developer, is that the most successful and applicable agent acceleration that I've seen at 30-time signal has been from the most senior people.

53:52The 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 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.

54:35Therefore, their 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 going to 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 insight and history and overview of the architecture. How does it all fit in?

55:08Is this going to work? Is this not going to 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.

55:54There's something in that equation that's in play right now, and it's not clear how it's going to 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.

56:36We 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 caveats. 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, I just got details on how they're adopting AI.

57:10And they have all these tools, cloud code and all of these things. But what we realized as well, when you just put it in there, they have all these internal monorepos. They have their ticketing systems. They have their slag. 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 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 NCD's agent harnesses. And now they're working better. But, you know, where we are right now is there's, and this is why if you're a senior engineer in one of these companies or a staff engineer at like Uber and you move to Google, suddenly you're not going to be as valuable or as efficient for a while until you learn all the systems.

57:55Right. So I wonder if just like with self-driving, you know, self-driving works great as well. I was in SF and in LA and Waymo, they drive so nice. My Teslas was driving in LA, driving us to the airport every time, the whole family. I sit peacefully, watch the road, but do not steer at all on that entire journey. Well, except my Waymo got stuck because a truck was parking on a narrow street and a car had a bike shed. And I knew that I should not go there, but it didn't know. So a human operator came in. But anyway, but even with Waymos, you know, like there's things like they drive in pretty good weather.

58:32They've been mapped out. So I wonder if in software engineering, I wonder if this has these parallels where we have all of, you know, like these companies have their specialized landscape. And once you map it, once you do all the tools, once you figure out these things, and with self-driving, it took 10 years, right? Like I was at Uber when they bought the self-driving thing and we were hearing in the news that, you know, next year it's all going to be over for drivers. And no. Yes. There are not going to be steering wheels anymore, which, by the way, is an amazing anecdote because it just shows Elon's total faith in his mission.

59:06Because in 17, when he made that proclamation, it was an AI. It was 500 ,000 lines of hand-coded C++. Right. Like that model was never, ever going to get us to the full self-driving. But he had just total faith in the vision. And then eventually, hey, here along comes AI. And it's so good. And if you train it on billions of hours of road use, it actually can do it. And it can do it better than most humans. In fact, I'm a pretty good driver, I'd like to say. I'm not the best chauffeur because my, I don't know, impatience have a tendency to provoke the throttle. That's not always as pleasant for passengers as it is fun for me.

59:46And when I let the Tesla autopilot drive, it's just the best chauffeur in the world. It's just perfectly calm. Better than you. Better than me. Better than the Queen's chauffeur, I think. It's throttle actuation and deceleration is godlike. It's actually AGI-like or ASI-like in its application within that narrow domain. And of course, when we get these anecdotes and these examples of, holy smokes, it didn't take 10 years for the self-driving. It took 10 years from the proclamation, but what they were doing for seven of those years had nothing to do with what they're doing with FSD now, because the FSD that's based on AI hadn't been running for that long.

1:00:28But the infliction point of, I think it was 13.1, FSD 13.1, like the first version, you're like, wow, this is pretty good, but I better pay attention. 13.2, 14.0, 14.2. Over the course of 18 months, we went from, yeah, it's pretty good, but I'm going to pay attention here, to why is there a steering wheel? And that acceleration in that short period of time, of course, is something people look to when it comes to programming and go like, well, if we're here now and senior programmers still have to review it because otherwise you're going to get all your, whatever, four severity, eight downtimes at AWS because some AI pushed out some nonsense, what is it going to look like when they take the jump that FSD did over the same period of time?

1:01:11Now, I also think you can go completely crazy trying to just sit and soak in all of that. This is what I tried to do over the past year, go, I'm really excited for where this is going. But I'm also going to deal with what's possible today and what's enjoyable today and what we do right now. I'm not going to try to plan what my life looks like 12 months from now when maybe we do have AGI or we don't. Now, there are other people who do that very well. I just watched an interview with Leopold on Duwakesh from last year. He's thinking like, what does 2030 look like? What does the whatever 10 gigawatt data center look like?

1:01:44I'm like, I'm very glad we have individuals who put thought into that because that's not my favorite spot to be. And I think most people are not that good at polishing the crystal ball. No, well, I mean, this is a little bit unsettling as a software engineer in the sense of like, clearly, this is where the industry wants to go. This is where a lot of effort will be put. There will be a lot of businesses, software businesses built on this, a lot of VC money raised on this, by the way, who are going to tackle this and they will either like succeed or die. That's what these companies do. But today, what you see at 37 Signals with software engineers, you of course have mostly experienced engineers, although you did hire junior engineers as well.

1:02:24How is their kind of work changing? How is their satisfaction with work changing? Because that's also a thing, right? We keep arguing about like, is it making us more miserable at these things? Is it what we want to do? And how is it changing for you, right? That's the biggest revelation, actually. More than even the capacity of the agents is my enjoyment running them. When I was on that Lex interview last summer, I was talking about, you know what? I don't want to be a project manager for agents because I had the mental model of a project manager of humans. And I thought like, that's not what I enjoy.

1:02:55I don't want to be that far away from the production. I want to be in the mix. I want to have my hands in the code. What I failed to realize at the time was that running a bunch of agents feels less like being a project manager for agents and more like stepping into this super mech suit where suddenly I don't just have two arms. I have 12 and I can now look at seven screens at the same time running five keyboards. I'm still the one doing it, even if I'm not typing this as a keyword in a program. I have been hyper accelerated as a programmer. It's a different kind of programmer, but it still has the same affinity to aesthetics, at least when I'm producing Ruby code.

1:03:37And I'm able to combine that while being vastly more productive on a bunch of things. It's also like getting an incredible brain upgrade on even assessing issues. One of the... One of the pilling moments I had was before the release of Omachi 3.4. I went into GitHub and we had, I don't know, 250 PRs pending. And I kind of just sighed a little bit and like 250 PRs. If I spend, I don't know, 15 minutes on each PR, like how long is it going to take before I get to the end of it? And I thought, you know what? Let me try something else. Let me just try to ask Claude to, I'm not even doing anything with a system.

1:04:21I just do review URL and the URL is the issue or is the PR. I'm shocked. In 90 minutes, I think it was, I processed 100 PRs. And it wasn't that I merged all of them. In fact, I'd say I merged a small minority, maybe 10 % got merged as is. then maybe 20 % got merged, but with Claude's implementation. The programmer had correctly identified an issue, but hand-rolled some code that I could see I didn't want to keep. Or sometimes I couldn't even see it. I just asked Claude and they said like, ah, it's not quite right. And then I just asked Claude, can you just clean room this? This is the right problem.

1:05:02Let's fix it, but let's do it right. It would do it right away. In exactly the style, as I would have written the rest of Omachi, Now, this isn't the high code of something. It's mostly just bash code. But there's still a shape to bash code and how you want it to look and can feel coherent with the rest of the project. Agents, opus in this case, we just nail it. And then the second half of it was split 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.

1:05:33We 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. Well, not dream to be. But it was in that moment. No, but you would have not put in there. I would not have done it. This was why the PR sat in the first place. In many cases. Because you knew that. I think there's something here, but then I now have to read up on this debus thing.

1:06:21I 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? But you probably didn't delegate it because you probably knew that it wouldn't make it faster or better. So I wonder if there's a part of AI because we talk a lot about 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.

1:07:07That'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 P50, P95, P99. Jeremy, one of our most aging 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, it still matters.

1:07:50And he just went like, we're going to do P1. We're going to optimize P1, And literally the fastest 1 % of requests were going to make them even faster. He took it from, I think it was four milliseconds to less than half a millisecond. He 10x the performance that 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 P1 project, I maybe misremember.

1:08:27I 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. I've never heard anyone do P1 because it just, it feels like a vanity project. Exactly. It makes no business sense. I mean, this is not true, right? Because everything adds up. But you know what I mean, right? I know exactly what you mean. And this is exactly why the explosion of the pie suddenly lets us look at problems we would never have contemplated looking before.

1:08:57It's funny. I remember this scene from Terminator 2 where they found this ship from the Terminator in the first movie. And he goes like, this thing gave us ideas we would never have investigated before. And 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 thousandfold. I do this all the time now, too. I'll give it some vague, crappy instructions just because I have this fleety idea.

1:09:36I haven't even crystallized it into a neat prompt. I just want to see something. And then I go like, oh, yeah, delete, as in revert code back to normal. 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 could just go like, show me a draft. I feel a little bit like a king where you just go like, show me the analysis of the far-frung regions. Where are we with the tax recipients? And this boy is like, this servant is like, yes, I shall do so. And we'll return in three weeks.

1:10:12Except 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 was actually a great idea. And you go like, wah-ha! I did this with Omachi. I haven't even pulled the trigger on it yet. But one of the things with Omachi 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 play games, I can just do it on the PC. It's not a me problem.

1:10:45Yeah. I totally get what 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 was one of the reasons I didn't want to engage with it. But secondly, it's a little finicky if you want Lux encryption on the Linux partition, but the Linux partition doesn't own the whole drive.

1:11:19It'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. I asked Opus first, like, come up with a plan for this. It thinks for minutes and minutes and then to come up with a good plan. And then I kick it over to Codex and 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, going, yep. that's a good plan. We should totally do that. And I can't wait to kick that one off and just go, yeah, now Omachi does dual boot.

1:11:50Not because I did it, but thank your helpful clinkers. That level of ambition is still something I've yet to internalize. Like even just that, that like, hey, here are these hunches or demands, projects that I would like to do and maybe someday. And you could kick it up on a hunch while you go to lunch. That is a new world, which is also one of the reasons I think a lot of people are thinking, well, the model continues to improve. But even if we somehow hit a wall tomorrow, the bitter lesson is no longer true. There's actually a limit. It's 19 trillion tokens. That's how much they can learn. Not true at all.

1:12:28But if it was, and we had to be stuck with these models, we would spend the next decade just getting more and more out of them, learning how to use these tools. You see this actually with vintage computers. So the kind of games they were able to make on the Commodore 64, when that was released back in 81 to 85, I think was the main run. I know they made it a little longer, but then the Amiga and other machines came out. They were great games. I mean, I got interested in games from the Commodore 64, Yier Kung Fu and all that stuff. The stuff they were able to do 20 years later when someone had just noodled all the secrets and tweaked the one megahertz processor.

1:13:05When they're building games for the old. Yes. are so much more technically impressive because we just know so much more about the... I mean, same thing with the... You look at the PlayStation. First games come out on launch. Last games, before we go to PlayStation 2, they're like from different generations. We could totally continue to do that with the models, but we're not going to have that particular enjoyment because there's a new model dropping in three months. But this is interesting because if we just run with this thought, like, of course, we know new things are going to come. But the point is, like, we will be spending so much time learning, applying them, building either our internal systems, changing how we build things, taking on new projects, like if we're an existing team.

1:13:44Now that people can do more work and more ambitious work, how are you thinking of the team taking on more work, launching more products? Are you thinking of potentially growing the team or keeping it as is? My best assessment for our setup is that the same people can do much more. Let's internalize that, but that's also enough. already we were doing enough. Already we had margin that we could hire way more if we had enough good ideas for that. So all this extra productivity we're getting out of the team allows us now to do things like P1 and these other projects that are awesome. And they're going to improve the product faster too.

1:14:22Of course they are. The old way of thinking like it's going to take two months to deliver a major feature. I mean, that's out the door. Of course, there's going to be rapid acceleration. That's going to filter all the way into our software methodology process. Like ShapeUp was built on two-month cycles. That doesn't make sense in the same way at all anymore. We have not fully rewritten those scripts yet because the acceleration is still so fast. No company really has rewritten the scripts on all of that. When you're shipping that much faster, you need a way to control what goes live and measure whether it's working.

1:14:54This is a good time to mention our presenting sponsor, Statsig, experimentation feature flags for teams that ship fast. Statsik built a unified platform that enables both experimentation and continuous shipping. Built-in experimentation means that every rollout automatically becomes a learning opportunity with proper statistical analysis showing you exactly how features impact your metrics. Feature flags let you ship continuously with confidence. And because it's all in one platform with the same product data, teams across your organization can collaborate and make data-driven decisions. To learn more, head to static.com slash pragmatic.

1:15:29With this, let's get back to the shift about the head developers. But I still think software developers are delusional if they do not think a shift is coming where before they were the constraint on how much could be produced and therefore could command the salaries that flow to the constraints. If suddenly those constraints now loosen, especially if we fast forward a little bit where the product manager is actually able to produce changes that can be shipped and work, things are going to change. I do actually think if I was going to bet we've seen peak programmer. In terms of the learned guild of programmers who went to either school or spend oomph-teen hours getting really good at it, we're not going to need the same number of them to do the same amount of work.

1:16:24Now, Javon's paradox, where as the price of something goes down, you get more of it or you get more demand for it, is true. But that doesn't mean that all programmers are going to get bailed out by it just because more software than ever is going to be produced. That's for sure. By the way, I think GitHub has gotten a lot of slack or flack lately. A lot. Justifiably so. I saw a chart saying they had a 92 % uptime, which sounds insane. I'm not sure exactly what that was measuring, but I feel it. I have a little bit of sympathy in that. I also think there's some mistakes were made, but also that the amount of software that's currently being produced is on a rocket ship.

1:17:03We are producing as a civilization globally, way more software than we've ever done before. I mean, OpenClaw itself, I thought he said it was 400 ,000 lines of code. That used to take 10 years and 2 ,000 people to get to that. Well, not 2 ,000, but yes, it's a, I mean, a long time, right? You look at, I think, the main monolith that Shopify has 3 million lines of code. That's 20 years. And if you collectively sum up all programs that have worked on that, probably like 20 ,000 people. Yeah. Big shifts are coming right now. Lots of software is being produced. I can see why it's creaking a little bit over there because like the pushes are just going to accelerate, right?

1:17:42And we haven't even seen anything yet. If you look at AI adoption curves, basically no one's using it. Like we all in our little bubble in X are like, oh, everyone's able to. No, they're not. Most companies in the world are just not doing it. Notwithstanding that, I think, ChatGPG got to 800 million users very quickly. Obviously, there's adoption, but nothing on the scale of what the companies that are furthest along are doing and how much they're accelerating with it. So I do think it is correct for the average programmer to think maybe we've seen the best of the golden days. Certainly, there will be pressures on price because one thing are companies like ours that have essentially unlimited scope to come up with new features and do more.

1:18:28And we can then plow in all that additional productivity into just do more. There's also a lot of companies who just need to do a thing. And if they can do that thing at a 10th of the cost, that's actually their advantage, right? They just need to do this thing. It's very neatly scoped and defined. It's a cost center. Anywhere where software development is a cost center, which is actually probably the majority of software development in the world, they're going to face these pressures. Sounds like if I'm a software engineer right now and I'm worried about like, well, you know, I just want to make sure that I'm at a place where things are going to be better.

1:19:03You want to be at a place where you want to either get out of a cost center or become really valuable there. Obviously, you know, brush your skills. And also I'm wondering if the shape of software engineers who will be hired will be changing. Because if I just look back from like the 90s, right? Even if you look at the movies, you saw the stereotypes. They were the nerds who didn't talk to anyone, but they knew how to code. They knew how to do assembly. And then we went in the 2000s. It was still based on languages. And over time, I think in the 2010s, startups started to not hire for languages, but just hire for algorithms because you could learn the stuff.

1:19:37And now I'm seeing companies, some of the latest VC-funded companies, hire for product engineers where they're actually asking for empathy, communication. on top of, it's kind of a given that you know how to code or whatever. So I wonder if I'm just looking at just this curve, right? If I'm just painting it up, like you're starting to get people, oh, and the developers I meet at all these companies, they're all really pleasant. They're all just very communicative. Oh, and they talk with customers, most of them. Just, it's not even a drag. It's like more and more of them love doing it. That's the constraint value now.

1:20:11The constraint value is figuring out what should we build, how should it be built, Which customers should we be talking to? Where should we be focusing? It's product management. It's so funny for me too, because historically I've not necessarily had the highest esteem for product management as a function. I thought there was a lot of bullshit and I thought it was a lot of people who maybe didn't do as much, right? And one of the reasons was that they couldn't because the constrained resource was the implementation, was the product manager could find out that they wanted to do something. I want to do this feature.

1:20:41And then they had to wait four weeks for some very expensive programmers to make that reality happen. And in those four weeks, I mean, I guess they could go talk to them. They were underutilized. They were not the constraint, right? The constraint was on the implementation. That absolutely is going to switch. And now pure implementation is going to be solved at some point. I'm not claiming it is right now. And anyone who is, I've not tried to just deploy five coded stuff with no review to major code bases. but as the lesson of last summer on Lex I'm not going to put my heart on the block and say that's not going to happen before next summer again this is just like common sense but implementation one implementation will be solved for a general use case for the edge cases it will take longer and for some cases it will not make sense same thing as I don't know self-driving is fine for like these size of cars but for like trucks it'll either take longer or if you're special as you do but the point is like there will be pockets but those pockets will be smaller Yes, I do think the stereotype of, I just want to sit in code, you have to be John Carmack levels of good to retain that privilege.

1:21:51I just want to sit in code. And even John Carmack. Yeah, of course, he's also super AI appalled. But also, he also saw some trends that he could do. For example, just the type of games that people would buy. He needed to have some business skills or just surrounded by people who did that. Totally, totally, totally. But 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 put out a job for both a software engineer and a designer.

1:22:35And actually, I want to interview your designer who you hired. And because you publish 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 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 30 Summit Signals? 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?

1:23:11Incredibly 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. 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 37 siglins over its entire lifespan. What's that going to be? Like, I don't know, 100, 150 at the most? I haven't even thought about it. How big is your team right now-ish? We're 60 people at the entire company, and we are, what's that going to be?

1:23:40Like, 20 programmers, something like that? Yeah, that's probably about right. Oh, so what is the other 40 folks? We have designers, probably like 10 of those. Wow. 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, it's probably about 100 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 long term.

1:24:21I'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... Half of you go through all of it, because you have a really long and thorough process. You put 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 all sorts of different hypotheses. Well, can we predict employee outcomes on the basis of Ivy League education background, on GPA, on all of these things?

1:25:01The conclusion was basically like, we know nothing. We can't predict it on any of these things. We can't predict it on lead code. We can't predict it on any of these metrics. 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.

1:25:40And that can sound really boomer, crudgy, very quickly. but it's also just the reality of trying to get a job. Like you 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 gets the job. So that 0.1 % chance. No, it's not. Not at all. With that math, you had 0 % chance.

1:26:21Yes. 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 happen 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.

1:26:56Then 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 going to use your submission to a code test. I'm going to deploy it 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.

1:27:27Okay, I get it, but there's no way around it. Because if you have it in your head, did 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've hired, sir. I don't know if that ever existed, but certainly it does not exist. today. It never accepted 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 typical... 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.

1:27:59And often it goes both ways where it's very risky. And then you say like, this buddy of mine, I work with this person for two years straight. I would like trust him with my eyes closed. So that's actually the black pill on the 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. It 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.

1:28:34And 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 then got hired and how many then didn't work out. Like, Jesus, there's only like a handful left from starting 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 hit rate there is really high. But how does that help anyone? Right? Like that's not a very actionable advice, except as to say, get as good as you can get and put in as much effort as you can and work with someone.

1:29:09because 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. 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.

1:29:50There is no shortcut here. You 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 harries people to further raise the bar? This is total cope. And it's cope both on the side of I work at a shitty place and never I don't want to put things in. You can be annoyed. I'm not telling you you have to love your boss. I'd actually say the majority of people I used to work for, I didn't have the warmest feelings about them.

1:30:24I still tried really hard. For my own edification, for my own education, for my own sense of I'm the kind of person who shows up and does a good job. It's just that I will be ready. when the opportunity arrives, when all my talents are needed and all my skills are honed, right? Well, was this not how you ended up at 37 Signals where it was just a contract job or something? And on a contract job, you have no ownership, but you showed up and - Correct. And Jason ended up realizing, okay, this punk better get some equity. Otherwise he's out the door. Now that's a seminal story and you shouldn't extrapolate everything from that.

1:31:01I mean, all founder stories, by the way, are seminal stories in that regard. But the fundamental principle is still the same. Show up. Do as good as you can. Learn more. There also was, to my chagrin, to some extent, I perhaps contributed to it a bit for a while, which was this notion that you can be a great programmer and not really like programming. That you don't have to ever care about programming outside working hours. Was this what you thought of? Well, I thought of it mistakenly because I was pushing back on the overwork 100-hour week, 120-hour week maniacal obsession, which, by the way, never was my experience.

1:31:42We did not start Basecamp that way. We have worked on a 40-hour week rolling average over those 25 years. But also, as I said at the very beginning, I really like computers. So I play with computers in my free time. I look at computer things in my free time. It's not work in the sense that I'm, whatever, shipping features to Basecamp customers, like just 24-7. That's not what it is. But I am playing with computers. I am looking at new things. I am exploring new systems and whatever. And I think there was, for a while into 2010s, a misconception that you didn't have to do any of those things. You could just show up and do your work, and you would be so sought after.

1:32:23because programming was such a valuable activity and there were so few people who could do it that they'd take anyone, even people who barely gave a shit. And I think that's over if it ever was true. And I think it was true. The boot camps were the perfect catalyst or they were the canary. Which also, by the way, is how the economy is supposed to function. When salaries are really high, it means that there's not enough supply of labor. Therefore, we should get labor into the pool. Exactly. And so I'm not, I don't even have any qualms about it. I'm just saying like, that's over. No, I think looking, you know, we're talking about like, is the golden age of the programmer, heavy class PEAP programmer.

1:33:02And I wonder if PEAP programmer really meant that almost anyone who wanted to get into the industry and was willing to put in some effort, a few months or maybe a few years could do it. You could learn how to code. You could go to either college or to a bootcamp or put in the hours and you could get hired at a place because the interviews were, the references were not needed. We didn't check. And it's probably coming to an end. You do need references. You more, I think more and more companies will be doing reference checks as part of our thing. And it's not just going to be, have you worked there?

1:33:31Like, would you, I've had these calls from like Databricks is famous for reference cards. They don't really check for references. They drill you, not just, would you work with this person again? What were their weaknesses? Right. Where would you hire them? Et cetera, et cetera. No, I understand it. The weird thing is, peak programmer sounds like this is something that affects all programmers. It does not. The best programmers, or not even the best, as in like it's 10 people around the world, really good programmers are currently more valuable than ever because they're the ones who are able to get the most out of the AI acceleration.

1:34:08And this was the kicker for me in changing my perspective on this, is that I've also found, and maybe it's not universally true, but certainly within 37 Signals, in my own experience, I'm enjoying my time as a programmer more than any time since early 2000s when I just discovered Ruby. This has the, I just discovered Ruby feel to it, that it is so satisfying to be able to move this fast on so many levels at the same time, to be able to explore the P1s, to be able to think about dual booting Amachi, to do all of that stuff that the work itself has gotten vastly more enjoyable. And I've seen the same thing for the most AI forward programmers that we have.

1:34:49Maybe they also have some of these anxieties, but they're kind of pushed to the side just out of sheer enjoyment working with the new capacities. So there is a bifurcation here where we should all feel like, well, we don't know what's going on. And for some people, that's going to produce some degree of anxiety. I understand that, especially when it's your livelihood and you're like, well, I'd also like to be able to pay for my kid's college in seven years. What does that look like? I get it. You're not going to be able to manifest that anxiety into anything productive unless you just plow it into leaning in, right?

1:35:19Because if you just sit and spin around and try to think about what the world's going to look like seven years from now, you're wasting your time. So that's the only path. The only path is to either get excited about this, which I don't even think takes that much effort. As we said, if you sit down with these models, you pull out one of your hobby projects from the closet. That you never finished. You never finish. And you just give it a try. I don't see how you really like computers and not find that experiment enjoyable. And I've seen this with people who are getting into it. Ken Beck is such a great example.

1:35:52He's been a programmer for 52 years. And he is saying, he loves doing it. And he found this balance between using the agents to build something ambitious that he always wanted to build. He's building a small talk server, which used to take forever. And now it's getting closer and it's still taking a long time. And then in between, and he's chilling at his, he has his house on the lake and he just goes and like, just looks at the birds for two hours and then gets back to it. It's beautiful. Kent is, by the way, one of my all-time heroes. This was right when I got started in programming. Right when I, before I was picking up Ruby, I saw Kent speak at a Danish conference in 2001 on stage and I was completely mesmerized by his command of both the material, how bold he was and how great of a speaker he was.

1:36:37And this was after having read Extreme Programming and many of these other things. Small Talk Best Practices is my number one recommendation for any programmer who want to learn the nitty gritty of how to structure a method and a class and the rest of it. Small Talk Best Practices, which is Kent's book from 95, I think, or 96, is to this day my favorite book of all time on tactical programming patterns. So it's wonderful to hear him. being agent pilled while also enjoying the birds. I mean, I try to do that too. And this is actually, there's a bit of a tension right now is that most of the people I find who are all in, they're working harder than they ever have.

1:37:15And I've seen that with myself now too. When you can be this effective and impactful on an hour of supervision of these agents, it's really intoxicating. If you have an active dopamine lube up there that gets triggered when something is shipped, it is just hyperactive right now. And I need to go, do you know what? This is not like a limited sale. Like AI is going to be here next month and the months after that. Like I cannot just operate as though it is a limited sale and I need to get all the dopamine harvested within the next two weeks. That I actually think is the main challenge right now for the people who are furthest along and most pilled on it is like, remember that this is as bad as they're ever going to be as the cliche goes, right?

1:37:57You damn well better find a way not to get consumed entirely about it as exciting as it is. And yeah, there's this consuming is a big deal. Like it was Steve Yagy. He was he looks a bit more drained than you can see on the video. But he is he's honest, like he's 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 stepping away? You know, like I know you've I think you previously talked about the importance of sleep. Apparently, you don't have an alarm. Correct.

1:38:28I 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 going to be awake for, in that case, 18 hours. What is the drag I'm going to 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.

1:39:08I 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. There's nothing that's going to be more important if you want to keep sharp up there.

1:39:46that 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 going to be dealing with for like, slow down, buddy. Like it's not, again, a limited sale. The next 10 years, we're going to see more and more. It's going to 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.

1:40:27You 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, kick back and like listen to birds. What is it that keeps you doing, keeps you building, getting up every day? And before AI, you would open your terminal. I think you shared you would go and write. Now you're doing with agents. What drives you? And looking ahead, 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.

1:41:05I 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 going to 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 moving them around. Spectorio. 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.

1:41:47I think that's the other big misconception that some people have about wealth is that they conceive of it as some sort of checkpoint. Once you've made it, then you can just kick back in leisure as though that was happiness. We simply have 100 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 going to cut it. It's not going to be a 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?

1:42:23Because 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 going to continue to do that. And I'm going to 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 want to play with computers. I want to continue to do that. And then even more specifically, after the last three months, I'm leaning in hard now with agent accessibility.

1:43:03For example, this is what I've been doing the 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 want to lean into all of this. How can we use this as much as we possibly can?

1:43:32And 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 want to know. I want to know. I want to 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.

1:44:11And 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 this 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.

1:44:42And 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.

1:45:20Finally, 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.

1:45:58Also check out the show notes for related to pragmatic engineering 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.