Building OpenCode with Dax Raad

39:43I think it'll get resolved. I think in my whole career, anytime I've seen any kind of shortage, there was a tense period and it was met with like crazy oversupply. It might be different this time, but generally that's how I see things go. But right now it's tight. I want to talk about the hype of what productivity gains these AI tools, specifically AI agents are giving to engineering teams and the reality. And you wrote a now very heavily quoted tweet which which was i'll quote just some parts of it everyone's talking about their teams like they were at peak of efficiency and bottleneck by the ability to produce code but the way things actually look like is and you listed a few things like your team your your org really has good ideas people are not using ai to be 10x more productive they're using to turn out their tasks with less energy to spend and so on so like this was a few months ago i think two or three months ago when you wrote it yeah i think there's so many dimensions to this So the thing I was talking about in that post is the majority, again, we forget how big the software engineering industry is.

40:43Like every company in the world employs software engineers to some degree, right? The majority of these environments aren't like the most motivating, exciting environments. Most people there are trying to do their job, go home to their kids, like have a reasonable life. You give them a button that lets them do their work faster. the natural place for them to do is hit that button as much as possible do the same amount of work and just cash in that extra time right which makes total sense like if you're not if you have no reason to be above and beyond motivated you're not going to really use that to like you know push your organization harder yeah these tools may make you more productive but like be really realistic about your employees like where are they going to like cash in cash in those gains obviously some companies are not like that their employees are motivated they good reason to be they're compensated in a way that that makes sense but most places aren't like that uh and the problem with that is usually in those environments it's like there will be a couple people that are irrationally motivated because you know they love the work they do etc even though the rest of the company isn't as motivated they're usually the ones that are trying to make sure everything is good quality make kind of push everyone to try harder they're all now overwhelmed by like slot prs and we've had a few people on our team that are joined and their previous company was like this.

41:56They were the person that still cared. The rest of the organization just hits the button and gets their tasks done. And they're drowning in just garbage. And they're getting burnt out and they're leaving. So motivation and team and people and humans and emotions, all that stuff is still a big factor in all this. How do you think companies, like let's say a mid-sized company or even a small company might have to rethink motivation, compensation, and thinking about work. Now that, you know, like I was talking with Steve Yeggie about this on how an engineer could, if they're super motivated and they put in the task and energy, they can produce a lot more output.

42:38And if it's well-directed, that could be better business results. But it does come at a huge cost in energy. And again, if you're just being paid by the same paycheck, it doesn't necessarily make as much sense to do so. So I'm wondering, like what kind of early thoughts you have so far and of course for you guys in a startup I guess it might be a bit easier I mean obviously for us you're right it's easier for us um we are in a very exciting space the people that join our company are very competitive uh they want to get in there they want to win so that's like a big driver everyone has equity that if we do our jobs right like it'll be pretty meaningful for them uh at some point I even pre-ai I feel like uh again I can only speak for startups as like that's where my experience is i'd always see startups post jobs where they're like we're hiring two engineers and they post two salaries and these are like okay salaries i always thought like why just hire one person and combine the salary you'll get someone that'll like meaningfully change the direction of your whole life like people will start showing up at that at that level um so we've always been willing to pay pay quite a lot we don't need to hire a thousand people we need to hire like 20 good people um so generally i think good salaries still go a long way.

43:49But yeah, at bigger scales, I think it's just hard. When your company hits a certain size, there is just no good reason for someone to do much more than what their job strictly asks them for. So I don't have any good ideas here. And I wonder if it's a thing where it is hard to retrofit this technology and the way of working to existing structures, which have been, and I guess the question goes back to how much will the AI native startup, like yours or ones that are starting today change, like how will their workflows change, the type of work, even the roles, right? Like what does this software engineer even do in terms of, okay, of course they prompt AI to write code, but what about a product?

44:25What about all these other things? Yeah, yeah, I mean, yeah, I think the bottlenecks are still there. They're still figuring out what you should be doing. You can spend a year just figuring out the right thing to do. And then once you figure it out, maybe it's fast to actually build it. But yeah, like I think the joke I made was pre-AI, I would spend 95 % of my energy thinking about what to do and 5 % of my energy doing it. Now I spend 96 % of my time thinking about what to do and 4 % of my time actually doing it. So yeah, it's like a 20 % improvement, but day to day, it feels as hard as ever.

44:56Another observation you made is at a lot of companies, and you will, I guess, see this secondhand from OpenCo, which being user companies, that the CFO is now going, what do you mean each engineer costs extra$2 ,000 per month? What are things you're hearing about in that area? Because this is happening. Yeah, so I think with every technology, there's a phase of like flexing where there's so many companies now that want to be seen as like, we're so future facing. We're like, our process is ahead of everyone else's like, you don't know, chance you're going to catch up. And they're all bragging about how much they're spending.

45:32So there's like right now, there's a push to be like each engineer is spending like 10 ,000 a month. And that's like, that's so worth it. Like, our business is so successful and so useful and so efficient that any amount of money is worth it. and there's a lot of that narrative then there's like and then that's fake that'll go away uh then there's a real narrative of like yeah these companies hire thousands of engineers if they literally cost a thousand dollars extra a month that like breaks your whole budget like that's not a thing you can kind of casually do we're in a temporary period of like we're experimenting to see what's possible and and everyone's learning i doubt this is going to be a sustainable thing like these companies were already pretty tight on what they could afford especially if they can't directly point to clear results of here's the issue right the net result of this i'm not saying this is the case but there is a world where the net result of all these ai coding tools is the same amount of work gets done but all the engineers are happier because their job is easier that's not good enough for a lot of companies so they're just going to say go back to typing out the code it's also an interesting dynamic where there's also the pressure of well when everyone else is doing it even if if we just stick with the happier analogy and again let's let's assume that the quality of the output overall wouldn't change.

46:43If everyone else is doing it and you're like, okay, well, it's not worth it. Let's stop it. Then your best engineers will leave. So I'm also hearing some CTO saying like, well, we're giving access to better tools because we're one of the best companies. Like it would look silly if we said like, oh, you can only use, I don't know, GitHub Copilot. We're not allowing you to get whatever open code or clock code or whatever else that is because we, like our best people would leave. Yeah. No, that is a real thing. It's kind of like, I mean, again, depends on if you have someone that's really good that has infinite opportunities, you know, using Jira is a risk because they're going to be like, I hate using Jira every day and they're going to leave.

47:16And I know people that have literally have done that. So that's like always a dynamic. But that will be at the top of the market, right? Yeah, exactly. So it's, again, I think at the scale we're at, we're just so exposed to like how big the world truly is. And the world we typically play in, it's so small compared to everything else that exists. And at most of these companies, it is just use Copilot. Just plug Copilot into open code and that's all you get. and your limit's your limit and that's what's there. And there's some narrative being pushed that these companies are going to die because they're going to fall behind, etc.

47:50But I don't know. I just don't think it's that straightforward. Another longer post that I paid a lot of attention to is the one that you sent out to your team, to the OpenCode team, which was on the topic of saying, all right, we should do three changes. I'll quote you. Basically, we have the following challenges. None of them are new, but I think they're turbocharged by LMs. Number one is shipping features not worth shipping. Number two, when iterating on features, sometimes the original design is off and it forces you something hacky, but the LM cannot deal with the hackiness. And number three is we need to spend more time cleaning things up.

48:26How did you get to these observations and what's changed since you, and how did it seem to respond? So the first thing, right? Features that we shouldn't have shipped. So easy just to respond to a problem by shipping a feature. So having more restraint, uh and like so we try to like flesh that out a little bit more like here's the type of stuff that we want to ship here's the type of stuff that like we'll wait on um until we have more clarity there's probably more restraint there the thing about shipping hacky stuff that one is i think the probably the biggest challenge because forever has been a problem where you have a system that's doing a bunch of stuff you need to add a feature to it the system doesn't exactly support the feature so your options are rethink the system from first principles redesign it so it supports that feature or just absorb the hack temporarily.

49:14And you can make a judgment call on which one you do depending on how bad the hack is, depending on how valuable to company it is to get this feature out. You make the judgment call. That judgment, that ability to have that judgment is so distorted right now because the agent will just do the hacky thing for you. The agent will kind of deal with the hacky problems that come down the road. And it's way easier to be like, oh yeah, it's a temporary fix. So we're shipping way more hacks in places where we should have just rethought the whole system from ground up or like redesigned it and like refactored it to make it more flexible.

49:49So I think our judgment is just off. Does this have to do that when I as an engineer, you know, pre-AI, like I'm making a hack. I know I'm making a hack. I'm thinking about it. I feel bad about it. I feel bad. Yeah, exactly. But I do it anyway. But you know, I spend time thinking about it and there's kind of like a little bit of prickle there. And then when I do a second hack, I remember the first one and I feel even worse about my and I can still justify it right but after a while like there's feelings that especially when you're someone who cares about the reason you care is you have an experience you've been burned you know you're placing landmines for someone else maybe even for yourself and is it just that the agents I mean they just do it they don't have feelings and they also suppress the effort suppress the thinking they don't even tell you I'm doing hack doesn't even know is doing a hack is just following whatever the training data is which is pretty low quality code on the internet right yeah exactly i think waypr is exactly right that prickle that feeling that you get it's like muted now because someone else it's kind of like you've made someone else deal with the problem the problem is still there and the landmines are still going to blow up on you eventually but like you're not you don't feel that bad feeling as much anymore so your judgment is skewed you're not getting that feedback loop i guess this is like you know like there's always this like very relatable story of the ceo who just delegates stuff and then like doesn't understand why things are terrible on the the floor and then like one day goes down and like and gets into like doing the actual work and realize oh my gosh these conditions are terrible exactly versus the ceos who are hands-on and they try to stay in touch and do i don't know simple stuff like or cto's doing coding in the environment like i think stripe cto did this like once for a week every few months and then felt like oh this is painful let me do that yeah exactly like you need to i mean just like you need to be using your own product you need to be also like You need to feel the pain that the users are feeling.

51:35Same thing with your code base, same thing everywhere. So yeah, I think all of life is about having the proper feedback loops in place. And it's very easy for those to go away. And then the third thing that you said in this memo was related to this one is we need to spend more time cleaning things up. How do you deal with that? And I mean, because you're also a founder, how do you justify it? Because, you know, there's this thing of like, especially when you're a startup, okay, you've just found product market fit. But there is this pressure to move quickly. and cleaning things up, it will not get you more customer love or revenue or any of the stuff that you care about as a business.

52:09Yeah, it's really hard because every single day we wake up, there is a thousand people yelling at us, telling us to do X, Y, Z things. There's a thousand people telling us we're doing everything wrong. Every single day, there is like a competitive new product that shows up. Very overstimulating. If we let ourselves just get pulled by those forces, I don't think it results in anything good and I think what's also cool is cleaning stuff up is easier than ever like you think of a new way in the past I would realize oh there's like a new pattern that we should be using and we would just start to use that stuff for stuff going forward but it was too much work to clean up all the old stuff but now you can clean up all the old stuff it's like you can ask the agent to go implement a new pattern everywhere it's very easy to clean up tech debt it's very easy to like find new patterns implement them across the code base very easy to clean up like dead old patterns and yeah you're right that there's no like direct uh result of of doing that i think you can be a successful company without ever doing that the way i think about it is there's a million ways to be a successful company there's all these different companies that are successful out there if you had your pick of any company you could work for you probably wouldn't pick 99 of them so i want to make sure we build a place that we're happy to work at five years from now our day-to-day is happy we feel good we feel good working there every single day.

53:24It's not this thing where it becomes miserable to work there. We can't get anyone good to join us because it's mostly about slogging through legacy stuff. And in this memo, after you listed all these things and you're basically saying, all right, we're shipping a bunch of stuff that we don't need. We're not cleaning it up. We're not thinking. You actually said something really interesting. I'm quoting you again. The worst part about all of this is I don't think we're trading this off to move faster. I think we're moving at a normal pace. Right, yeah. It feels like we're going fast, but then I look back and I'm like, Like, I don't know if we actually are going that fast.

53:56And I don't think we're going any slower than our competitors, but we're certainly not going any faster than them. So if you're trying to look at productivity, it's so easy to trick yourself into thinking you're being more productive. And when you sit down and really look at it, oftentimes, like, it's not as crazy as you expect. I guess what you're saying is, you know, don't be complacent and accept, but like, just be critical and look at, is this working? Like, should we slow down to speed up? Should we focus on the invisible stuff? Those kind of things. I really believe in just like preparing a lot and like setting the foundations right.

54:27And then when you spring, you spring with like so much more force than you would if you just forced it earlier on. One thing I like about you is you do call out BS. It's a BS, especially when it's really trending on social media. Again, you're a lot on X. This happens a lot specifically. And here's a tweet that I'll read to you that you'll remember. It went very viral. so many people you know VC folks all said like yeah this is the future and this is what it said the 24 to 29 year old engineer will soon become the most valuable asset in technology because they have pre-AI principles and post-AI speed and it's an undefeated combo and people are saying like yeah this is the future like this generation who is not too old have the old things they will be killing it again they have no preconceptions of what used to be possible and you did call BS on us can you talk don't tell me like who you're thinking well it's it's funny because like i'm just so tired every single day i wake up and i open the feed and just prediction after prediction of the future's gonna be like this if you're just gonna be like that if you're just gonna be that and we're just like making stuff up right that one's funny because that's a very classic post where it's like person like me has all the advantages person like not like me has all the disadvantages it's like everyone is just saying mantras to themselves because the root thing that's going on here is we are experiencing a moment of great change.

55:48Everyone is very nervous about what that means for their own position in it. A defense mechanism is to confidently assert a future in which you're a winner. And that's almost what every single prediction that you see is happening. You almost always trace it down to companies like mine will be successful. Other companies will fail. My job won't be replaced by AI, but everyone else's job will be replaced by AI. And everyone has some rationalization for this, but the root thing that's happening here is everyone is scared and worried and not sure about where things are going and we are just bombarded with predictions and protecting their own psyche um yeah i'm just tired of predictions like yes we're gonna have time of great change i just focus on like the next day like what can we do today what can we do tomorrow i didn't know i was gonna be working on this a year ago i don't know what i'm gonna be working on a year from now i'm just trying to do the thing that makes sense right away uh this thing about like how young people have that that's like always been a thing young people have a lot of advantages they have the classic disadvantage of not having a lot of experience but having a lot of energy uh i have a lot of experience but not as much energy as a 20 year old so it's just the same thing it's always been like you know it's and it's funny because he like that one's particularly funny because he said 24 to 29 why not like 18 to 25 you know it just told me it's clearly he falls in that age range which is why he's saying that it's just like yeah it just it just made up i think everyone's just like nervous and worried i think it's good to just be honest about it Because it's true.

57:07Like, I mean, I'm nervous and worried as well, just because the change is faster than before. And this is talking with, like, the greats of the industry who have lived through the Ken Beck, Martin Fowler, Grady Booch, and they're all saying that they have seen change like this, like, for example, when they went from mainframes to microprocessors, but it was throughout more like a decade, not a matter of a year or so, or maybe we're now at this point two or three years. And they're all saying the same thing, that the change is faster. But yeah, as you say, it's very easy to rewrite history and say it was always obvious, but it's just hard to tell.

57:42No, it's not. Yeah, it's so unobvious. Everything that ends up happening is always counterintuitive. There's always people that see it correctly and line themselves up properly for it. But none of the obvious things ever happen. It's like, it just, the end state we're going to end up at, it's going to be so weird from our point of view now, it's going to make total sense in hindsight. So yeah, predicting is a lot harder than people think it is. So far with OpenCode, especially with OpenCode, you and the team have reached really good success. What are the things that comes to building products and your engineering principles that have not really changed from the early days or the ones that you've learned and you've stuck to them and it helped make OpenCode successful as well?

58:25Yeah, I think for us on the product side, like I said, it's very simple. You probably only have one good idea in your whole product. Get the user to experience that as fast as possible. it sounds so easy but if you go try every single product out there you will see a million accidental steps they introduced from the user hearing about your product to like seeing the value in it very hard to keep that minimal very hard to like not let that creep back in it's like a constant thing so we do this i do this thing where um like i have a command that like runs up a new dark darker container and runs open code which lets me experience the first time experience i do that like once every two weeks.

59:01And I'm always catching stuff that we've messed up in that process by accident. The job of product isn't to just receive a problem and ship the immediate solution. It's to absorb all the problems and understand that there's one solution you can ship to fix 50 different problems, right? That is hard. That is difficult. That takes experience. That takes thinking. That takes talking to users. That takes talking to your team. That takes understanding your code base. A product is a way to abstract a solution for like many different issues, right? That's always going to be hard and that is a skill that you can infinitely get get better at um i used to be horrible at it i'm okay at it now i probably have another few decades of getting better at it yeah that's what i'm focused on like how to build stuff that solve problems well and ai has not helped me even a little bit what has helped you there what has helped you to get this like product sense better or or like you know figuring out because it sounds like we we talked a lot about thinking about reflecting about having one elegant solution that can solve multiple seeming your unrelated problems i mean it's just uh it's years of experience in in situations the right feedback loop right when i mess something up i get a literal human yelling at me and like saying horrible things about me when i design something poorly i have to slog through the code base and like do something that should have been easy that's a lot harder now yeah so for us it's all about making sure everyone on the team has those feedback loops no one is insulated when you're in that type of environment even for just like a couple months you just get so much so much better and i think a lot of organizations uh it's hard to keep that type of situation as your company grows i think it's probably impossible um so if you mostly worked at larger companies this is probably the thing that you've never fully experienced i've been at companies where the product team would want to like ship something faster so they'll cut stuff to get it out sooner the pain is not felt by them it's felt by their support team the support team deals with the angry people and the support team fixes things manually for them and the engineering and prior team are like you know hey we did it we shift the feature and they don't realize that there's like a side effect that they created so yeah like really being in that feedback loop just makes you makes you better uh and then caring a lot about building something for a lot of people i think this is another thing that uh you don't have to try to build stuff for millions of people i'm not saying you have to do that but it is very interesting to have that perspective of and make something that works for the whole market it's so hard to do that there's so many different environments people workflows preferences constraints if you adopt that mindset the stuff you work on makes no sense to anyone else observing things they think that everything you're doing is wrong they think you're focusing on the wrong stuff but if you really are going for the whole market like you just start to think very differently can you let us in a little bit of how the open code team today works like tell us how many people there are what kind of setup and maybe we can walk a recent feature that you or someone else launched or like was it even team and how you also get this like immediate feedback yeah so we're still freaking this out because we've grown a lot recently like we're at 20 something people now and it's happened oh awesome congrats thank you yeah it's happened in the last like couple months like three months or so so we're still very much in the phase of getting everyone settled we're in that horrible feeling phase where we have more people than ever but we're like going slower than ever because like everyone is still kind of getting getting situated and getting up to speed etc so we're trying to make it to that phase as fast as possible i think for us um we're very we're an open source company so which means all of our code is already public so we kind of build in public as much as we can um we uh we've been trying to figure out good terminology for this but if we have like a thing we're trying to ship or make happen there's a phase where you're trying to like push it up the hill and that's like a painful phase because you're going from zero to making it exist and there's a point where it's definitely not done there's definitely a lot of work to do but at that point most of the stuff is figured out as most just like fleshing out the details uh so our team really tries to focus on getting it out of that first phase into the second phase as fast as possible we kind of put a milestone of like this is a demo that we want to show people let's try to get it to there as fast as possible and from there again because we're so public because our users are so vocal people tell us exactly what to do after that like once the foundation is there and people kind of roughly get what they what what the feature is they'll tell us what else they need they'll tell us like where else we need to make it work they'll tell us what sucks about it and it gets very easy from there they're on and whoever worked on it they do that full cycle there's no one that's like receiving the feedback and summarizing it for the engineer they're receiving the feedback they're getting the github issues they're getting the replies on on on twitter and they're figuring out the roadmap and the cycle for it.

1:03:36So that first phase is the hardest. But from there, again, the feedback loop kicks in, things get better over time. One of the things that we try to do is, like the founders, we try to make sure that the whole team has perspective on everything that we care about, the market, our competitors, what we're trying to do, our position in it. If they properly understand that, they naturally land on their own priorities. For us, motivation is a huge thing I said earlier we know this is a long game if it's a long game your strategy should be how can I stay in it the longest the only way to do that is to work on stuff that is exciting every single day we'll kind of let the whole team grab stuff that they're excited about what's the biggest problem they want that they think is the worst thing that's hurting us they're just going to grab that and work on it they roughly end up having good judgment if we're doing a good job providing them like the right context about what's going on so typically people just grab stuff there's been times where our team really want to work on something and I like vocally disagree with it I was like I don't think we should work on that and they've been right like I think like a few weeks later I realized oh they were actually correct about and I was wrong so it's really exciting to see our team be able to start to do that kind of thing one thing that comes up we didn't mention it a single time in this conversation but elsewhere it often comes up is taste there's this notion or idea that one thing that AI is just very bad at and probably will stay bad at is having taste and and how as engineers taste taste product sense they're i think synonyms to some extent uh in fact i've even heard that microsoft insurance only has a training for taste to get better at taste which i'd love to see that one what what is your take on on on taste as a whole as as as a concept so i think fundamentally it's a good idea there's something that makes sense there i think with good ideas they're very simple and so everyone kind of repeats the idea but good ideas are simple very very difficult to actually live so it's very difficult to actually have good taste and it's like a lifelong yeah one it can be learned uh it's like a lifelong thing that you're gonna work on forever i think the root issue is a lot of people will say that the whole taste thing but do you actually believe it like do you actually believe that your product has to be good there's so much like there's so much out there now that's like the code doesn't have to be good the product doesn't have to be good like nothing has to be good it's just this other thing you can still be successful and they point to companies that have crappy products that have crappy engineering but still make a lot of money right so there's like a thing in the air about maybe all that stuff doesn't matter the moment that gets in your head like nothing like you're not going to have you're not you're just not going to ship good products it's fundamentally you don't believe in it and i feel like the number of people that like vocally believe that craft is really important making an irrationally good product is still something that you're going to do uh because most great products they could probably be like 50 less good and have no material impact on it but it shows up in other ways that are really hard to directly draw a line it's if you start to be lazy in one place you start to become lazy everywhere it's like an infection so my thing with the whole taste thing is like yeah you're saying taste matters but do you really believe it it's like a very very high bar to be someone that says I really care about good products for me personally I care a lot about it and I am nowhere near achieving my own bar like I'm like so missing my own bar and what I think what I believe is when you hear me talk about quality and stuff and use my products you're like oh it doesn't he's like kind of ahead of what he's saying that's because like I'm like still trying to get better at it you know so I look at products that are really good I'm still very inspired by them um I still have like heroes that I think uh just kind of do a great job at certain things.

1:07:12And I know I have a long way to go to get there. Can we talk about these heroes, the products and the engineering teams that you look up to and why? Yeah, yeah. So I think in my space in DevTools, I think Mitchell Hashimoto is like an obvious one. Our company is very similar or trying to be similar to theirs in that all their products were open source. They became mass adopted. Things like Terraform became the default. You know, it's very hard to do something like that. and it's well executed across the board in the microscopic in the macro the business model uh you know his work with ghosty has been really great the architecture of it cares about every little detail and it shows up uh when you use a product so um and he's very good at product and i think he he has a he made a clip that's very similar thing we were just talking about where every feature you ship it's not about the features about how it interacts with every existing feature and his work as a product person is to make sense of all that um and he's very good at doing that.

1:08:08I think he's probably one of the best for being also a good programmer. So I think he's someone that I admire a lot. And I hope that we can kind of be as good as that one day. I sensed, as we're talking about taste, we started to talk a lot about quality. Could it be that quality is one of the last few things that these days, a startup, a small company going up against Goliaths has left to hang on to? Yeah, yeah. And I think the flip side of it is, it's easier than ever to rot your product. I think it's with these agents and everything. So you see with big companies big companies products are rotting faster than ever even startups products i was saying this the other day like now the product is a year old it's probably already kind of going to shit and i think it's because of the goal please agent workflows so yeah i still believe quality is a huge differentiator it's not just something you can decide to do i think it needs to show up every single aspect of your company from like you have to do things that are irrational i mean that's kind of what quality comes from like you do a bunch of things and like 50 % of those things you didn't have to do.

1:09:09And I think very few people are willing to operate that way. There's like a cold logic these days to programming into software and to products. It's like, I'm like a business guy and I care about business, which means I only do things that are hyper, hyper rational. And a lot of people think that's what being good at business looks like. And of course that can work. But yeah, I think quality is like a huge differentiator. I mean, even if you look at our story, when we first launched OpenCode, uh cloud code was the only other real thing we were going up against a big initial differentiator was that our terminal experience just felt better we spent a lot more time on like we built our own terminal framework like building your own framework is like the first thing they tell you not to do right it's like the thing that no engineering team should do it's irrational yeah exactly it's irrational but like it did we looked at it and we're like we couldn't achieve the experience we wanted like we were people that use terminal tools we look at tools like neo them and enjoy them and know what is possible like i mean again going back to mitchell like he worked on making terminal stuff as good as possible like he knows what's possible with it once we know what's possible how are we going to ship something that's like not pushing those capabilities to the max right and very initially a lot of the reason people were using us when people were talking about us compared to cloud code was how janky cloud code was or how much it flickered or how much it did whatever and it didn't matter like they're still a hugely successful product but we irrationally focused on some of the quality stuff that helped us go up against a much larger product company with much more funding what's your work setup a work setup i've now switched to a framework desktop nice the the one where you can replace yeah the little like tiles in the front and stuff yeah so uh that uh running arch linux on a non-ultra i guess it's a 5k display it's one 5k display I use a tiling window manager which I've been using for 10 years and that's roughly it yeah got my SM7B as well the mic and I use my iPhone as my camera about it yeah and then you use mostly terminals of course open go terminal right yeah so I use oh I guess my sidebar is actually a little more complicated so that is my physical machine but I do all my work on a remote machine so I ssate to a much bigger beefier computer that has many Tmux sessions going, one for each project, NeoVim as my editor, and then OpenCode.

1:11:31It's usually split half, so like NeoVim on the left, OpenCode on the right. I'm going between the two. So yeah, Tmux, Arch, NeoVim, OpenCode. I wanted to ask you how you think engineering leadership has changed with AI because you've been an engineer, founding engineer, then you've let teams before you're technically leading a team now as well. And also, like, when you talk with other, you know, you're not talking with a lot more, like, CTOs and like-minded folks. What's different is, are people being more hands-on? Is that even a good thing? Yeah, I think I'll tell you something that I've heard.

1:12:09And I think, and on one hand, this makes sense. On the other hand, I'm not too sure about it. I think these teams are now looking at themselves as, okay, what's the role of an engineer now? If you're not going to write the code, what do you do? Your role maybe is to figure out how to make it easy to ship code that is to safely ship code right um set up guardrails so that someone prompts an agent to do something it's not introducing a bug like make sure make sure your testing story is good uh make sure there's like proper conventions and patterns in your code base that agents can follow so they're not like adding something that's really crazy so your your role ends up being more like how do i set up the right guardrails to make it so someone that is using an agent can kind of blindly ship something that that works well whether it's another engineer it could be your marketing team that is uh trying to ship a change to your website how do you make it safer to to make changes and this is like the novel way that everyone is kind of looking at engineering teams the thing that i find interesting is that that's not novel this has been the thing we've always been trying to do forever how do we get a junior engineer to ship code safely without breaking stuff right how do we make patterns in the code base how do we make tests like it's all the old stuff that we've always wanted to do like i would love to be able to hire 100 junior engineers and have them be effective but you know there's like limits to that we were we never really figured that out and like some companies did to some degree some companies kind of didn't so it's kind of the same problem as always which is how do i make a less experienced person punch above their weight right and now you know it's using coding agents that's maybe like how do they design or ship stuff stuff like that uh so in a lot of ways i think it's the same problem as always which is how do you make code bases that are easy to work in scalable flex to new requirements um i think a lot of like the old patterns from here coming back we've always been like a big domain driven design company um we did it in a very light way we're now doing it in a much heavier way because we find that these like kind of boring enterprise-y uh patterns end up being pretty useful because you have a bunch of idiots on your team now the coding agents are a bunch of idiots and they are going to work 24 7 and they're going to like ship a lot of stuff so you need way more guardrails than you used to i think what's nice is some of these old patterns we hated because they were very verbose they produced reliable code that was like modular and safe but they were very verbose and annoying to type out but you're not typing it out anymore so now you can kind of get the benefits of these patterns without the downsides so we're starting to like explore that more and kind of enjoy that yeah i wonder if like design patterns might make their way back remember in the 2000s or like mid 2000s, they were a huge thing of like, again, for structure, it helped junior engineers not mess things up.

1:14:42Yeah. And it was very verbose. So eventually people just like hated them and got rid of them. Yeah. And if you're a good programmer, you didn't have to do those patterns. You can kind of like, you didn't need the training wheels in a lot of ways. But now like, you know, agents don't have training wheels. You got to put them back on. Yeah. And what advice would you have to more experienced engineers who again had been pretty good engineers until now and they're like, all right, I just want like stay with it uh keep my game high and you know have the skills and and build up the experience so like i i could work at a place like open code i have a tough time giving advice to people because i feel like i work in such a weird place like my company one's a startup so it's innately uh automatically a little bit weird two like where we do open source which is like there's like five companies that are open source companies really so everything we do and the type of people we try to bring in i don't know if that generally applies to everyone i think the most i could say is and i've always believed even pre-ai is uh software engineering is a skill that can be applied to an industry and you can just be a great software engineer and that's that's totally fine you can probably good good career doing that but you if you also become an expert in a specific industry that's like a deadly combo um if you are like i don't know just pick any industry let's say let's say farming.

1:15:58Let's say you understand the farming industry really well and you're also a decent software engineer. You're probably the top 10 people in the world for that combination that the whole industry will want to hire. So like, and that's what's great about being a software engineer is you don't have to pick an industry. Like everyone else has to be like, I'm going to be in medicine for the rest of my life. You can choose to do medicine for 10 years of your life and like do tech in the medical field and become an expert in that and realize you don't like that industry and pick a completely different industry and just go become an expert in that.

1:16:27And that's so exciting. I think software engineers are curious people. And it's just so fun to be able to deeply learn an industry in that way. And eventually you'll find something that clicks that you can stick with. And being a good engineer and also being an industry expert, it's very easy to become a unicorn of a person in that way. And when we started, we were talking about how software is everywhere. Software engineers are everywhere. And I guess every industry will lack software engineers who are really curious about their industry. Yeah. It doesn't take long, right? You spend like a year in any industry.

1:16:57like you now know it more than like 99 % of people. So I think the trick here is it's very easy to turn your brain off to that side of things and just focus on, I'm given a task to like add something to the UI and like not. Your opportunity as a software engineer is you get to be in any company in the world and learn about anything. And you should kind of like take advantage of that. And I think there's a rational career reason to do that as well. As a closing, do you have any book recommendations, things that you've enjoyed or change how you think? yeah it's funny because uh i do not read books at all okay or or reading recommendations so i mean it's a kind of expand on that my wife is a avid reader and i get to benefit from that because she reads all the books and then she tells me like all the good ideas in it and i restate them like they're on my own idea like i read the book i did have like a reading phase earlier on i think kind of helped uh helped me understand like a lot of how the world works uh i'm a big fan these are boring recommendations, but I'm a big fan of a bunch of Taleb's work, I think.

1:17:54He's basically got a couple good ideas, and it's maybe hard to read a whole book because a book is just one good idea inflated into a book, but these are just fundamental true things about the universe that you can just see play out everywhere. So, huge fan of stuff like Skin in the Game. Obviously, Black Swan is super popular. A lot of the stuff that I found to be very influential on myself is the idea of emergent properties. So almost everything great in the world came not through top-down design. It came through a bunch of smaller entities operating together randomly, and then something kind of great comes out of that.

1:18:30And you see that whether it's in robust software or what makes a city great, what makes a neighborhood walkable, what makes an organism capable of surviving disease. So this whole bottom-up versus top-down in terms of designing systems. There's a few books that talk about that. Taleb is one of them. And I feel like I see that everywhere. Like once you kind of understand his ideas, you realize they kind of underpin the whole world. Dax, thanks so much for this conversation. This was fun.

1:18:56Dax Raad:Yeah, it was good. Thanks for having me. I hope you enjoyed this conversation with Dax as much as I did. Dax is in a rare position. He's building one of the fastest growing AI coding tools out there, going from 650 ,000 to nearly 8 million monthly active users in just a few months. And yet he's the one telling us to slow down. One thing I really liked is what Dax called the muted prickle. Pre-AI, when you wrote a hack, you knew you were writing a hack. You felt a little bad about it. You'd remember it the next time, and that feeling kept your judgment sharp. With AI agents, that feeling is gone.

1:19:27Dax Raad:Now someone else is dealing with the consequences. The landmines are still there, they just won't blow up on you today, and we don't even pay attention to a lot of these landmines being placed by AI agents. Finally, I really appreciated Dax's memo to his team. He basically admitted, we're shipping features we shouldn't, we're absorbing too many hacks, and the worst part is we're not even moving faster. We just feel like we are. That's a pretty brave thing for a founder of a hot AI native startup to say out loud, and I think it's a reality check that a lot of engineering teams need right now. If you enjoyed the episode, be sure to subscribe on your favorite podcast platform or on YouTube.

1:19:59Dax Raad:And if you'd like to support the show, leaving a rating or review really helps. Thanks for listening, and see you in the next episode.