Building OpenCode with Dax Raad

Daxrade is a co-founder of OpenCode, the most popular open source coding harness. He's also a very down-to-earth one comes AI, which can be a bit surprising when you consider that he builds such a widely used AI tool. Today we talk about the rapid growth of OpenCode to closer to 10 million active users in less than a year. The mental Dax sent his team admitting they were shipping too many features, taking out too many hacks, and AI usage not helping them move faster. Why Inferent is one of the most profitable businesses in tech right now, and why even OpenCode is bottled by GPU supply and many more? If you'd like to ignore the hype on social

media around AI and instead talk about where it helps or hinders productive engineering teams, this episode is for you. This episode is presented by Intysysysus. Verify your systems correctness without human review or traditional integration tests, and avoid bugs or outages. I'd also like to mention our seasons sponsor, Trobover. You've probably heard someone say RAG is dead these days, but it's not.

It just doesn't mean what it meant in 2023. Back then, retrieval is pretty straightforward. The human asked the question, your code embeds it, you've got a vector database, top K results come back, those get stuffed into context, and the LMS. Look at what's actually happening inside something like OpenCode or any serious agent product in 2026. A human sends one prompt on orchestral agent. That agent fans out to subagents. Each subagent is hitting separate systems. A vector index,

a full-text index, grabbing the file system, running CLI commands and seeking against OLTP and OLAP stores, reading and writing a memory system, reranking results, looping and calling more tools. One human prompt turns into dozens, or even hundreds of searches across totally different shapes of data. In practice, this means a lot more complexity, a lot more cost, and a lot more potential performance issues, especially when you need to scale up the system. This is exactly what Trobover is built for. It's a ridiculously scalable, fast and cheap search engine. It's built on top of

object storage for a reliable and scale, with smart caching on MVMESDs so it's very fast. It's priced so you can let agents lose with proper RAG in 2026 without seeing your bill explode. Check it out at Trobover.com slash pragmatic. That's welcome to the podcast. Yeah, thanks for having me and thanks for coming all the way to Miami. I wanted to jump in to something really interesting about you. You're building one

of the most popular AI engineering harnesses, OpenCode, which is speeding up how people write code and just turn out software. And yeah, you're claiming that this itself is not enough. This itself will not get us to better software. I've always said the easiest product, the one you can use yourself. And obviously we built OpenCode so that our team can use it and it's like we are the customers of the product. So we use it aggressively as much as anyone else can. And of course, it is,

we build it so we think it's useful. And we use it every day as a critical part of our workflows, but all the old problems that I've always struggled with are still there. I'm working as hard as I ever have. I'm struggling as much as I ever have. So a lot of the job has become easier, but yeah, it's a weird feeling. It's objectively stuff has become easier. But then why am I

like thinking as hard as I ever have? You know, it's a weird feeling that both those things be true. And it's interesting because a lot of the people who are decision makers, CEOs, often hands-on people, like hands-on CEOs, CEOs, founders, and companies, they kind of think, oh, look, we've got these tools coding used to be the hard part, right? Like objectively, it took us so much time and it still takes to get into the zone if you're going back to going by hand. So if that's faster, because that's where we use this most of our time, it should be faster. Like everything should be faster.

But why do you think this is not the case? Or like, what is getting in the way of like, just like shipping high quality software faster better, right? Yeah, I mean, there's different life cycles, different companies. There's like pre-product market fit. There's actually probably market fit, which is kind of where we are. And there's companies that have like,

have had probably market fit for like a decade. And I imagine that things look very different across these three. For us, pre-product market fit, to me, it doesn't really help that much because you're trying to figure out what you should be doing. And yeah, like maybe it helps you swing a lot, but I've always thought it's better to think a lot. And so I was swinging a lot. I think you can eliminate

a lot of ideas or directions just by spending a lot of time in your head and with your team talking. Obviously, I just didn't speed that part up. We're at the phase where we've achieved product market fit. Now our task is to kind of hit the potential that we have. And the issue for us is there's a million different directions we can go in. There's all the obvious stuff we can do.

There's all the stuff that our users are telling us that we have to do. There's stuff that our competitors are doing. And it's very easy to just one to one do each one of those things. Because we have a problem prompt agent. Competitor has a feature prompt agent. User has a problem prompt agent. If you add that up,

you think, oh, we should put thousand features now that adds it to a good product. It actually adds it to a horrible product. Nothing's cohesive. You look in there. You shouldn't have shipped this.

The moment you ship something, you're stuck supporting it forever. And by supporting, it means any future feature you build is going to interact with it. So you still have to be very conservative with what you put out there. It's hard to undo anything. Just because we can ship 10 times more doesn't mean we have 10 times as many good ideas to ship out there. So in a lot of ways, my struggle has

now been, how do I slow everyone down? And understanding that, yes, our process can look very different. But should it look very different? We've done in the past six months, we've kind of operated very differently than we ever have. A lot of stuff went wrong because of that. So now we're pulling back

and figuring out what from the old world still makes sense. We're figuring out what we should be doing. And I definitely don't feel like, oh, yeah, we're killing our competitors. We're using AI. So we're doing everyone else. And by the way, none of our competitors are crushing us either.

Like, no one out there is using AI so well that they just, like, we can't even compete, right? And we're in the coding engine space. Our competitors are super in AI. So you would think in our space, there would be like a huge gap that there isn't. So I want to rewind back to the very beginning of how, you know, before AI, before a lot of these things, how did you get into tech and software engineering?

Yeah, so I grew up, I kind of, I appreciate the story. I grew up programming as a kid. My dad was a software engineer, so it was a little bit easier for me to get into than for other people. Then just started working out of high school, founded a company, thought it was cool that I knew what I was doing, looking back in hindsight, like, wow, I didn't know what I was doing at all. That eventually got aqua-hired as a small aqua-hire and ended up in like the real tech industry.

Bounced around as a consultant, founded a few companies, and then ended up doing open source pretty much the past six years full-time. But going back to the very beginning, I found or saw some references. Do you working on Minecraft Minecraft servers? Back in the beginning, can you take us back a little bit? Yeah, so Minecraft, I was never known as Minecraft is. And again,

it's another pre-shaste story. You talked to a bunch of people in tech, there was a modding framework for Minecraft that came out. I ended up working on the framework itself, I ended up making a bunch of mods with it. I found that I liked creating interesting sandbox. I never like, I played the game a little bit, but I didn't play the game that much. I had a server

that like 100 people would play on, and I would just use these mods to create interesting situations to try like understand how people behave under certain scenarios. And I found that fascinating. But yeah, that required a lot of programming job and stuff. What's interesting is that community, obviously I was like very new to programming. It was all done over IRC, or community existence on IRC. But there were some very senior, very good programmers in there. The people there, I felt like

were people that weren't particularly career motivated. They were probably in a comfortable situation where they worked like two hours a day, and they were talented, but they didn't have any desire to like, career chase at all. They funneled it into the Minecraft stuff, and I got to talk to them and learn from them. So I think in like the couple months I was doing that, I learned a lot. And then you went to the start-ups, you found the start-up. And then after being the founder at

Iron Bay, I saw looking back at the first week, you became a head of engineering at Right Health. Yeah. Can you tell me a little bit about what was that was in 2017 or so, like pre-cool bit? Yeah. So that was a company in the transportation and healthcare space. It was me and the co-founder

originally. And that company grew to like, 20 people or so. That was my second swing of doing a startup, I would say. And it got further than my previous attempts. But it kind of ended up in a disaster. I did end up meeting my wife there. She was head of product. I was head of engineering.

We got together after a year. So better than a startup exit, I would say. Definitely learned a lot. But yeah, it was one of the situations where everyone was super young in their 20s. And I think there's this stereotype of startups that only has a bunch of super young people, building stuff. After that experience, if I ever end up investing in companies, I'm not going to

invest in companies with a bunch of young people. Because our brains weren't fully developed. We were all insecure about various things still. And I played out with company politics and dramatic stuff. So yeah, that cliche of like, oh, yeah, it's a bunch of young people. I think that's

like the exception, I would say, looking back. So a bunch of people succeeding is probably the exception. Yeah. And of course, we have famous stories of that. But on average, for me, I felt like my brain didn't have been developing until I was in 26. I think. But prior to that, I don't know if I

really should have been running a startup. And when you say it's self-developing, is it just kind of getting enough experience to understand how a business actually works or professional relationship? Yeah, I think for me, it's like the startups are so intimate, because it's just you and a few people, and it's very intense. Like you are, this is the thing you're doing. Like you're not really, this is your hobby, it's your job, it's kind of everything. If you're not like fully developed as

a person, like if you're trying to prove something to the world, if you're so insecure about certain things, all that shows up at work, especially in such an intimate situation like that. So fighting, conflict, all that stuff. The way I perceived the situation, you might understand what was going on, just basic like how to be a person and live in the world. I think I think for guys, like it takes a while for their brain to fully settle. I want to do it, I felt like day and night, I was a different person, but it definitely took a bit. And now you can look back at the time and just kind of look like,

oh gosh, what was I doing? Everything was just so magnified and way more intense and way more emotional than it needed to be. So the people who knew the DAX back then might be a little bit surprised. I think so. That's when my wife met me. So something was right there.

Did you, in your first few years, you found out a startup, then you kept going out like very early-day startups, either as a founder or an early founding engineer or so. Did you ever consider larger companies at that time? Yeah, I think that was always there because for me, this era was early 2010s or mid-2010s. The big tech companies are very prestigious at that point. Everyone you met was trying to get a job at either one of the big tech companies or one of the hot unicorn startups at the time. That was the thing to try to do if you weren't doing that. You basically

were going to stay on tech. So I felt like some kind of pull from that point of view, but I also just couldn't get my shit together to do that. I knew what it takes to, there's a set of things you have to do to be successful there. I just couldn't even do that. So yeah, I could say like, oh yeah, I chose not to do it, but really I just don't think it was. What do you think the things were back then?

I mean, there was a very structured interview process for these things. You know, you have to do certain programming problems, whatever. I think I was a good programmer. I think I'd done some interviews that were like that and I told them I even did well in, but the level of competition and people study for it, people focus on it, just randomly swinging at it. I don't think I would have landed anything. So yeah, I was into building stuff. I was into more practical things.

And I just struggled to do anything outside of that. And then how did you transition into open source? Well, serverless stack was a big project of yours. It was a toolkit for building full stack AWS applications. Yeah, that was kind of our initial focus was. Yeah, I just

had a down to open source. So after ride health kind of ended up in disaster, I took a job at a series B stage startup. At that time, for me, it was the biggest company I ever worked at. And I eventually got put in a direct role, first time being like a full time manager with no other like no like active programming tasks. And I still wander a lot. So I ended up exploring a bunch of open

source things at the time. I had like three or four hours of manager meetings every day, but outside of that, I had time to explore with source things like that. And I started to build my own kind of crappy stuff and I came across SST, which had just launched, it was maybe a couple months old. That was Frank and Jay. They both kind of created this thing originally, started contributing to it.

They were raising a series, like a raising around, they were kind of getting out of YC, raising around. I invested in that round. And then a month later, I ended up joined the team, and they gave me the money back as salary. But now I had to pay taxes on it. So if you're going to invest a company, make sure you're not going to join them. It's a bad use of money. And then

you did SST and then you did some other stuff as well on the site, right? Open Next. So Open Next, I think was probably the thing that blew us up initially. This wasn't even a thing that we wanted to build. We were serving people in AWS space every single day, some would come to us and be like, we like what you guys are doing, but we really need help to deploy Next. AWS. And over and over

over a year, people were just nagging us about this. And we didn't want to do it because we weren't Next.js users. Very tedious. You're actually a very complex framework, trying to recreate the right infrastructure for all that. And it was a lot of work digging into JavaScript, bundling Next.js internals, not very fun, not very exciting work. So we made Frank do all of it. So he basically

slogged through that and figured out how to get it all working in AWS. Our goal from the beginning was this project shouldn't exist. It's just a weird gap because the Next.js team is focused more and for sale. It wasn't like a malicious thing or anything. It's just where the attention would actually go. So we're like, let's fill this gap. The end ideal stage should be that, you know,

Vercel eventually just manages all this and there's no need for this. So we built that. It annoyed Vercel a bunch. But yeah, it was very useful for people that were trying to deploy on other places. Eventually, we rallied some other providers that had problems with Next.js as well.

So CloudFlare and Netlify, Microsoft got on their venture to Google, got on their eventually, and they built stuff for OpenX. And eventually, the Next.js team had time to make an official Dapper's API. And in the past year or two, it became a much more collaborative thing. And I think they need for OpenX is slowly going away. And then how did OpenCode come about? Because that's

a pretty recent story. It started sometime in summer of last year, summer 2025. Less than a year. Yeah. Yeah. Back in February, our company, we were basically doing a push to

hit the pay profitability. So with SST, we had a monetization path for that. Basically, for like three or four months, we're running out of money, and then our revenue was going up. And then in February, we had one month of money left. But then we also broke even at the same time. We

believe that we were all able to come about it. It just felt like something would work out. And it did. So that gave us time to kind of take a step back and think about, yeah, we can technically do whatever we want now, like what we want to be doing. And for a while, we're like, obviously, AI is a thing to work on this decade, especially if you're working in DevTools. We've been through

waves before where like there's a thing that happens. And whenever a thing that's happening, it seems like it's not making a lot of sense. Because whenever something that has a lot of potential, it tracks a lot of investment. But it's a nature. Most of investment doesn't make sense. So it's

very easy to look at anything exciting that's happening. I think none of that makes sense. I'm not going to participate in it. But usually what happens is a few things in there make a lot of sense. And if you just completely sit out, you just miss out on that. I think we've been through a few

waves of kind of doing that, where we saw the AI thing and we're like, okay, a lot of stuff is stupid, but there's definitely a real value here. We need to be doing something in it. And we took a few swings at a few ideas and a lot of them didn't even fully launch because we discovered it didn't make sense while we were working on it. And then eventually we started to use Cloud Code as a team. It was a first AI coding tool that stuck for us. It directly saw some of the workflow annoyances

that we had. And this is great. Obviously, this should exist. At some point I asked, why weren't we the ones that built this? We should feel bad about that. And then we realized, okay, maybe there is

like so an opportunity to do something given our experience as an open source. We kind of saw, I think, what I was saying earlier, you don't have to just ship a million products to figure out some networks. If you sit and think, you can figure something out. And we kind of looked at it from a positioning point of view, like there's a market, there's a bunch of coding agents out there. For some reason, no one has grabbed the open source territory. There was no coding agent that was

like, we are the open source option. And that obviously is a super valuable territory. Every single dev tool we use, whether it's databases, compilers, whatever, eventually the open source option becomes this option, right? That combined with the fact there's heavy, heavy competition for models. Like, sure, Claude was popular, but there's billions and billions of billions of dollars invested.

They're not just going to let anthropic wind. They're going to be pushing open AI to be pushed from the open source side. So given that we saw that chaos, we saw that's really valuable to have the open source positioning that tries to work with all the models. So the initial push for us was to kind of ignore whatever was going on the market and just make sure that we claimed that open source spot, which we were able to do. And then yeah, our numbers have been pretty crazy since then.

Can you tell me about the growth? Like you launched in June 2025, how the growth was both for usage, but also for the team. Like when you started, how big was even the team? Was it most of the existing start and mainly labs working on this or just the small? Yeah, no, so we were just three people at a time. So it was just three founders. Yeah. And then we hired

one of my friends who was also interested in organizing, and he helped us build like the initial thing. So he joined. So it was four and then we convinced one of our really good designers that we had always wanted to work with the joins as well. And that was after we launched. So that was more like in the fall. But yeah, so we launched and the growth was really good immediately. It was

better than anything that we'd ever done. But by December, we hit 650,000 monthly actives. And at that point, we were like, wow, this is great. We back in the fall, we kind of were telling people our goal was to hit 1 million by next year. And we thought we were crazy. Like that was like, oh, okay,

sure. Then in January, we did 2.5 million monthly actives. So like one from 6 to 2.5, last month, we're at 6.5, I think this month, we're still having some mental matter, maybe close to eight. Our next goal, my zone was 10. There was a massive jump. So we went to 650 in December and 2.5 in January.

What was that jump? Is that the winter break jump where everyone started to realize that these models are really great? Yeah. So having been in DevTools for a while, we knew that in January is always a bump. Because like, I think people take time to learn new things in December of the time off and they have time to try new stuff. So we, what we typically see is we see a dip into the holidays and like a giant

spike in the first week back. For this, we saw growth into the holidays, which we never seen with any other product before. But like despite the fact that people were off, it was higher usage than ever. And January came around and anthropic helped us a lot by, you know, they wanted a band and topic subscriptions in Open Code that blew up into like a huge thing. We barely even commented on that, but like just the user base was so upset. And probably accidentally put us and them in like the same

sentence, which we don't deserve because they're a bunch of bigger, more sales company. But that week, that kind of happened by accident and that like spike numbers like crazy. So I guess in 9 seconds, what happened is, and traffic silently banned being able to use cloth code subscriptions inside of Open Code, which was every tool that Google Open Code did that because it was a bunch of other third parties, but they didn't allow Open Code to do this. And then this led to this like outrage. The thing with them is they're kind of new to working with developers. It's okay to do things

like, of course, you need to do what you need to do to make your business sustainable is totally fine. But randomly dropping a block at like 9 p.m. at night, that just sets you up for like people to hate you. Doing like a phase, communicate a rollout over a month, I think they would have been giving a heads up. Yeah, yeah. I think people would have said, of course, everyone's gonna be up 10 no matter what,

but it wouldn't have been this concentrated moment of like everyone being really annoyed. This reminds me of what we were talking about how AI allows you to do things really quickly and fast. Do you think in this case, and Tropic might be, you know, stepping in this trap of they can do things really fast and they do things really fast. But for example, in this case, they can just implement a block like this, you know, like the PR probably took like what, like a few seconds or a few minutes. Whoever did that might have knocked off through the implications. I think it's just a consequence

of any kind of fast growing company. You forget the amount of leverage you now suddenly have. Like you do one small action in Ripple's through millions of people. Like we're doing with this ourselves. Like we've never worked at this scale before. We put out a bug the other day where

almost everyone has a terminal dark mode and we open Open Code, it opened Open Light Mode. So we like flash bang the bunch of people. And I'm like, in the past, I would have been like 100 people we hit. But like I did this like a million people this week. So yeah. But but inside this block,

obviously we know it worked out well in hindsight. But when it happened, I mean, at the time, Opus 4.5 or 4.6 was the most powerful model out there best recording. And you saw that on Dropout just blocked, you know, like clock host progressions before you knew that this rest would happen. Like, was it seems reaction was it just like, they call them keep going? Yeah, what's weird is we knew this day would happen at some point. And for some reason when it happened, we all just felt excited

because I think we were kind of like thinking about this for a while. And we knew this would happen. We also knew that like we live in this crazy bubble, like especially on Twitter, where everyone has a $200 call max description. At that point, we were at 650,000 monthly active. There's no way 650,000 of them have called max descriptions. Like it's crazy for the average person to spend $200 a month on

anything. So we knew it was like a smaller subset. And also at the time, we had been working on deals with pretty much every other company to officially support this, their subscription and open code. So the previous week leading up to that, we got Microsoft degree for a copilot to be officially blessed by open code. We got a bunch of different companies in the works we're not announcing them yet.

And the big one we hadn't gotten or we haven't even approached was OpenAI. So when this happened, that night, I remember exactly when I got like 100 tags on X being like, oh, they banded, they banded it and I was like, all right, it's go time. So I messaged OpenAI being like, hey, tomorrow, everyone's going to wake up and everyone's going to be really angry at anthropic. You guys have a chance to score like a PR win by taking the opposite stance and officially supporting open code. The next morning, they confirmed like, yeah, let's do it. So in the morning, everybody was like, oh, anthropic block

open code. They're screwed. I saw a bunch of people being like, they're worth nothing now. Like they're going to go to zero, whatever. I was like, laughing at myself, I'm like, okay, just wait until the end of the day. And then we forgot integration, we implemented it. And then the day we announced

like OpenAI is a foot supported in open code. We knew what was going to happen. And like going to all the backs that open next thing, right? The strategy that we know how to play really well is to pick one temporary bad guy and galvanize all their competitors to push something forward against them. So I thought it was unfortunate in that position. So we kind of got the rest of

industry to, you know, support open code to support like access at these models in different places, because they were all competing with it with the topic. So these are like nice strategies that you can run in these situations, even as a small company. I'm starting to get a sense that that past 10 years of building dev tools or like at least like five of open source and understanding dynamics is really helping you. Because even when you told me about how you were thinking of OpenCode, you're talking about strategy about how there was this gap. And there's all these competing model providers and with an open alternative over time, in a lot of ecosystems, the open one wins and the vendors compete, for example, with Linux, Linux is open source, but the distributions are for public companies, Red Hat, Ubuntu, or Canonical, and so on. And they all compete and they make it

better. So even in this case, it sounds like you, you know, like, it all goes back to you actually had a strategy that you expected that players play the players play as they play, it will make sense. Yeah, exactly. If you get your positioning, right, the world just keeps handing you wins that you didn't even expect. So like we never predicted the exact scenario, but like our fundamental position was right. Like if there is a neutral party, all these companies with billions of dollars

will kind of use a neutral party to advance their own company's interest. So it's beneficial to be that thing in the middle. Yeah. And then right now, Codexing forward, they saw it as a way to increase brand awareness usage. Right now they're sharing how much is growing and I'm sure logically at some point, they might turn around at some point, say, let's say they win the market or they become market leaders, they might do the same thing. Okay, we no longer want to support this thing, but

at that point, there might be other players as long as there's multiple interested parties. Yeah, exactly. So at some point, maybe OpenEye becomes a bad guy that we have to kind of galvanize everyone around. So it's, I mean, it's why competition is good. This is kind of exactly how competition plays out. I think the thing that people maybe underestimate is we're a small company,

we're not like a huge company at all. You can apply, if you apply pressure in the right places, you can actually make things happen. We get a lot of criticism and like anger from people being like, oh, you had to be so mean to anthropic. They criticize the way we approach things, but these are a billion dollar, you know, huge companies, you know, like us being able to apply any amount of pressure to get something to happen. It's very difficult. And this is what it looks like.

People might think that it's, you know, they're above it or whatever, but having more access to these things, having more people to be able to use the tools they want is a good thing that you can love Cloud Code be like, I'm never switching out Cloud Code. That's great. You should probably still be into the fact that people can use other tools that they like, right? And going back to why Open Code is so successful and that there was a gap using what you've learned about depth tools in general, like why was there a gap? What do you think was the difference that you did outside of just, you know, like writing the tool to start with? The biggest advantage to

in depth tools is the fact that everyone working at depth tools is a programmer and programmers are horrible at B2C products. They don't realize that tools are B2C products. You basically treat to see other business of code zoomer. Yeah, exactly. So like you treat them, like that most extreme mindset to have is like you treat them as well, you're launching Instagram or social media app, something like that. Yeah, you can do a top-down process and there's plenty of companies that do like an

intense top-down enterprise process and that works and that's great. But the depth tool products that are like massively adopted to the point where they're basically standard, they're all bottom-up, like they're in the developers are to use them, so to like them and kind of creep into companies and they grow in that direction. And to do bottom-up, you have to basically think like consumer company and programmers generally are very, very bad at thinking this way. So we very much focus on the moment you open Open Code, it should feel very different and better than some of the other options. And to do that, we have to build like a ground-up terminal rendering framework. That's not what Cloud

Code did, that's not what any of these other coding thermal coding agents did, they just used ink or whatever and they made it work for what they need. But we invest it on the upfront because from the moment you use it, it feels like something different. It might not be for you, like maybe you don't like the overwhelming experience, maybe it feels like too much, but you still walk away thinking the people that did this are competent probably. So immediately getting people a good feeling and then immediately getting them prompting without any layers of friction. So we focus on just reducing that friction as much as possible and focusing on things like, I'm going to lock down enterprise laptop. How do I can I use Open Code? Optimizing for all of those things and our

harness wasn't very good for like the first like five months of Open Code, but it was good enough. It was good enough that most people couldn't really tell the difference. And once we wanted to share, then we went back and like tried to make our harness look good and smart and optimized and all those things. But it was inverted from what everybody else was doing. Everybody else was being like, you have to build a smart harness and that's how you win. We have like a mid-level

harness, but we are most used. So now we're able to like, you know, creep up and actually have the best harness and are also the most used. So I think it was an inverted strategy that we did that other people didn't fully understand. And to get into the infrastructure to the technical level, like you launched with a framework called Tori, right? Oh, that was our desktop app. So the desktop,

I would say, I would even say that was, that was mostly a mistake on our part. So I love terminal stuff. I do all my work in the terminal. So our numbers are, so we're going to hit like 8 million months out of users. I don't think 8 million people should be using the terminal. I think it's a little

over, we have like too many users for what the product is. I think a lot of them would probably have a better experience on on a GUI. And we understood that very early. And so we were kind of experimenting with like a web app with a desktop app. And so we're like, this is probably going to be a direction of things go. Unfortunately, we were right. Like that is like where things are going, but we didn't

like read that project. We should treat it a lot more seriously and try to get it like out there way faster and it's all a bit harder on the technical stuff. So yeah, we just kind of picked stuff and we didn't like too hard about it. And it also was a mistake and we're moving back to Electron now. But OpenCode is growing amazingly fast. Interesting enough, there's this growth hack

that some partners are doing. I was like, growth hack where in the PR and GitHub, they actually put which partners that at Cloud Code is doing it, GitHub Cloud is doing it, some others are not doing it. And OpenCode, you are not doing it, even though this could be like almost like free marketing. Yeah, so initially we had, because initially we were effectively Cloud Code. If Cloud Code did it, we did it. So we had that, like with the committee, we would say, you know, committed with OpenCode

with our own GitHub. And then we got a bunch of people being like, hey, can I just have an option to disable this. And I thought about it. And I was like, this is so late. It just felt lame to me.

I'm like, you can be like a Cino, right? Because Cino just tries to trap you in there with every little trick to like you to say. That's the extreme of doing a consumer product. I feel like we didn't have to go to that extreme. It felt like a little bit lame to like try it. It's like too obvious of a

growth hack, right? Like everyone sees it and everyone knows why that's there. Yeah. So I just wasn't a big fan. And so instead of having the option, we just turn it off by default, you know, you're still running a company that is a for-profit company in the end or you need to make bankroll. What is the

business model behind OpenCode? So we have two lines of business, basically. So initially, when we first launched OpenCode, a big problem that people had was, or that we had again, thinking about reducing friction. They had to connect something. They had to connect it on a drop-out account. They had to

connect it on a network account. At that time, when you sign up for an author, you can even get enough rate limits to even use something like OpenCode. So a lot of users couldn't even use it. So we're like, okay, we have to at least build some kind of inference service that like you can sign up for and get access to all the models with the rate limits you need. So we built that and we called it OpenCode Zen. And we initially just built it as an onboarding thing to smooth out onboarding.

But that grew like a ton. And with the amount of open source models are becoming popular, we also found there's a ton of difficulty in hosting open source models correctly. So Zen has become a place to aggregate the best model. I mean, of course, from two models are easy, but then the best inference for all the open source models, all that became really popular. That business is growing a ton. I think a couple months ago, we announced that that hit 50 million run rate

within like five or six months. And the margins there can be pretty good because open source models you can host at a decent margin. That is growing like crazy. We don't really expect that, but that's a big part of it. The other side of it is extremely boring. If you are a company

that's using OpenCode and you have a thousand engineers, you can't just tell them all to go download OpenCode and add an open API key. You need some kind of control plane to set up all the providers, permissions, budget controls, rate limits. We have a product there. We're going to make that publicly available soon, but right now it's just been enterprise deployed. So if you're a company that's using OpenCode at scale, you need some administrative software to run it. You

can't practically use OpenCode at scale without something like that. That's also open source, but most people just pay for our hosted version. The other thing is, I think the time is finally come where people are looking at how much they're spending on LM. And they're like, what are we doing? Are we actually getting anything anymore done? So companies are now looking at their cost and

trying to figure out how to optimize it a little bit. It's great timing because Open Source models are now very competitive. They are 10x cheaper. Blending that in and having good inference for Open Source models is becoming part of business as well. So these big companies, they need a control plane, but then we kind of just give them inference access as well to these other models.

And they end up just kind of naturally starting to use it. If that ends up being a main part of our business, we might stop charging for the control plane itself and just charge for the inference. DAX was just talking about the boring but essential work to get enterprises onboarded. SSL permissions, control planes, all the stuff every series company eventually needs, which is where I need to mention our season sponsor, WorkOS. Sooner, rather than later, you'll need to get around building these enterprise features, not just control planes, but things like all for apps and agents. WorkOS handles it. SSL, skin, fine-grained authorization, build for how agents actually operate.

The fastest growing AI companies and Tropic, OpenAI, Curse, or Perplexity, they already trust WorkOS to solve these problems. Check it out at WorkOS.com. I'd also like to talk about a presenting sponsor, Antisysys. We just talked about slowing down to speed up, thinking hard about what to build so you're not sprinting to the wrong destination. But quality is part of the destination too. You don't want your product to flash bang a million people like

the team at OpenCote did at one time. Antisysys is a property-based testing platform that enables you to express the properties your systems should have, then verify that those properties will hold in the chaos of production. With Antisys, specification and thorough revocation becomes a seamless workflow, giving you clarity so you can deliver quality. Check out Antisys.com slash pragmatic to learn more. And with this, let's get back to DAX and OpenCote. We had a recent tweet about how

inference is actually really, really profitable. You were quoting someone who was saying, oh, these AI model providers are having financial difficulties. Can you explain to those of us offer engineers? We don't do inference. We use these models and we just assume that this must be our business. How can it be profitable? Why is it profitable? What are you seeing?

Yeah, so I think this is a different part of business. If you look at the pure inference part of a business, what's the floor on the cost? The floor is a cost of electricity. There's a capital cost that acquires the hardware. Once you have it delivered token, the cheapest it can get is the electricity power. Obviously, there's other infrastructure. There's operations staff, there's stuff like that.

But we have seen models that we look at the sticker price of it and we know because we rent DPs at scale to run the models. And we still use middlemen, by the way. So we're not going all the way down to the floor. Even for us, there are some models, the sticker price, and the cost of 80% margin in there. And I think the other thing that people don't notice is the prices have gone up. It's confusing because it

seems like they haven't. But they've gone up from the point of view is we used to all use Santa as their default because Opus was too expensive. Then they made Opus cheaper so that we started to use Opus as their default. But it was still way more expensive than Santa. So the prices have gone up and the cost of the hosties models haven't changed. So that's one aspect of it being

be profitable. And anthropic, of course, they have an open AI crazy scale. They have the biggest GPU deals that they've done. So I wouldn't be surprised if they're looking at 90% margin at current prices. I don't think that's a defensible margin long term. That's crazy to be able to make that much with the

amount of money going through as well. It's interesting because when Brian Kentrell was on the podcast, he used to work at building a cloud service that I have compete with AWS. And he said that back then this was the same thing. AWS backed and hid their financials. Everyone thought and they told everyone the cloud was a terrible business. And it's like you're a red blood everywhere. And then he

started to do it. And he said like, actually, it's a really freaking profitable business around a cloud. But it's kind of a wealth of secret because why would Amazon or any other provider advertise the business that is printing money? There's always negativity that exists for any business getting hyped. They have no sense of the correct it. So again, it's complicated because I know that training calls

are a big part of it. The R&D department is hugely expensive. But long term inference makes sense of business. I think it always will. This being said, you also said something in public about GPUs about you quoting you. There are just enough GPUs as crazy that even a company R-size being bottleneck

files. What does that mean? Yeah. So across the whole stack of GPUs, everything from producing the GPU to supporting hardware to like labor, everything is like super tight right now. The demand for inference is growing. So like, I don't think it's linearly growing. I think it might even be exponentially

growing. But we haven't made our production of GPUs grow exponentially. That's a kind of a linear process. So as those lines intersect, there's going to be tightening. So for us, we have GPUs that we need to reserve. It's going to be a lot up front. Everyone is now hoarding because everyone's

kind of expecting this crunch to kind of continue. It's very hard to get capacity for inference. And the other thing that's crazy, I think I posted about this. We see things like, oh, a company has raised $2 billion or whatever to do something in AI. And that feels like a crazy amount. That's

a huge amount. You have to be like a crazy start to do that. The big tech companies are spending like tens of billions in a year. Amazon, Meta, whatever. They dwarf anything that's happening in this startup space. So they are just vacuuming up like all the demand. Any company that is in the supply

chain, they don't want to talk to you because they're busy trying to get something with Amazon or Microsoft or Google. So yeah, it's very hype times. I think it'll get resolved. I think any of my 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 it'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 the AI agents are giving to engineering teams and the reality. And you wrote a very heavily quoted tweet, which was all quotes on parts of it. Everyone's talking about their teams. Like they were at peak efficiency and bottle like by the ability to produce code.

But the way things actually look like is and you listed a few things like your team, your or greatly has good ideas. People are not using AI to be 10x more productive. They're using mature now 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 something to mention to this.

I think I was talking about that post is the majority, again, we forget how big this offering engineering industry is. Every company that wrote employees to offer engineers, does 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 doesn't 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 have no reason to be above and beyond motivated, you're not going to really use that to push your organization harder. Yeah, these tools may make you more productive, but be really realistic about your employees.

Like where are they going to like cash in those games? Obviously some companies are not like that or the employees are motivated. They're compensated in a way that makes sense. But most places aren't like that. And the problem with that is usually in those environments, it's like there will be a couple people that are irrationally motivated because they love the work they do, etc. You know,

the rest of the company isn't as motivated. They're usually the ones that are trying to make sure everything's in quality, push everyone to try harder. They're all now overwhelmed by like slop yards. And we've had a few people on our team that are joined and their previous company was like this. Like they were the person that still cared. The rest of the organization just like

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 like emotions, all that stuff is still a big factor in all this. How do you think companies like let's say midsize company, even a small company might have to rethink kind of motivation, compensation, thinking about work now that, you know, like I was talking with Steve 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. And if it's well directed, that could be better business results.

But it does come at a huge cost and energy. And again, if you're 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, and I started up, I guess, it might be a bit easier. I mean, obviously for us, you're right, it's easier for us. We're in a

very exciting space. The people that join our company are very competitive. They want to get in and 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 pre meaningful for them at some points. I even pre AI, I feel like,

I can only speak for startups. That's where my experience is. I 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 tell you why just hire one person to combine a salary, you'll get someone that'll like meaningfully change the direction of your whole life. People start showing up at

that level. So we've always been willing to pay quite a lot. We don't need to hire a thousand people. We need to hire like 20 good people. So generally, I think good salaries still go a long way. But yeah, at bigger scales, I think it's just hard. When you're coming to a certain

size, there is just no good reason for someone to do much more than what their job strictly has some force. 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? How will their workflows change the type of work, even the roles, right? What does this offer engineering even do in terms of, okay, of course, they prompt AI to write code, but what about all the other things? Yeah, yeah. I mean, 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 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% my time actually doing it. So yeah, it's a good 20% improvement. But day to day, it feels as hard as ever. Another observation you

made is had a lot of companies and you will, I guess, see the second hand from Open Code, which being being used as 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 that area? Because this is happening. Yeah, so I think with every technology, there's a phase of 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 is like, no chance of getting a catch up. And they're all bragging about how much they're spending. So there's like, right now, there's a push to be like, each

engineer is spending 10,000 a month. And that's like, that's all 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 that's fake, that'll go away. Then there's a real

narrative of like, yeah, these companies hire 1000 engineers, if they literally cost $1,000 extra a month, that 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 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 going to say go by the typing out the code. It's also an interesting dynamic where there's also the pressure of, well, whenever else is doing it, even if we just stick with the happier analogy and let's assume that the quality of the output overall wouldn't change. If 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 fair tools because we're one of those companies, like it will look silly if we said like, oh, you can only use, I don't want to get top co-pilot, I don't want you to get whatever open code or clock code or whatever else that is, because we like our best people will leave. Yeah, that's a real thing. It's kind of like, I mean, again, it depends on if you have someone that's really good that has different opportunities, using Jira is a risk because they're going to be, I hate using Jira every day and they're going to leave. And I know people that have literally have done that, but that's like always a dynamic. So that will be at the top of the market. Yeah, exactly. Yeah. 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 these companies, it is just use co-pilot, just plug co-pilot, open code, that's all you get and like your limits are limited 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, et cetera, but 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 Open Code team, which was on the topic of saying, 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 LM's. Number one is shipping features, not for shipping. Number two, when

integrating on features, sometimes the original design is often a force to do something hacky, but the LM can deal with the hack and ask a number three is we need to spend more time cleaning things up. How did you get to these observations and what's changed since you and how did it see respond? So the first thing, right, features that we shouldn't have shipped, so easy to respond to a problem by shipping a feature. So having more restraint, and like, so we try like flush that out a little bit more, like here's a type of stuff that we want to ship, you just have a stuff that like we'll wait on until we have more clarity. There's a bit more restraint there. The thing about

shipping hacky stuff, that one is I think the probably 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 for first principles redesign it so it supports that feature or just absorb the hack for temporarily. And you can make a judgment call on which one you do depending on how bad the hack is, depending on how valuable it's a company it is to get the feature out. You make the judgment call. That judgment, that ability to have that judgment is so disordered 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 to and refactor to make it more flexible. So I think our judgment is off. Does this have to do with 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 about it. I feel bad. But I do it anyway. But,

you know, I spend time thinking about it. It's kind of like a little bit of a prickle there. And then when I do a second hack, I remember the first one and I feel even worse about it. And I can still justify it. But after a while, like there's feelings that especially when you're someone who cares about the reason you have an experience you've been burned, you know, you're placing line mines for someone else, maybe even for yourself. And it's just that the agents,

I mean, they just do it. They don't have feelings and they also surprise the effort, surprise of thinking they don't even tell you I'm doing. I doesn't even know what's doing a hack is just following whatever the training they does, which is pretty low quality code on the internet, right? Yeah, exactly. I think way is exactly right. That prickle, that feeling that you get, it's

like muted now because someone else is kind of like you made someone else do with the problem. The problem is still there and the lamb is just going to blow up on you eventually. But like, you don't feel that bad feeling as much anymore. So your judgment is skewed. You're not getting that feedback loop. I guess it's like, you know, like there's always this like very really little

story to CEO who just delegates stuff and like doesn't understand why things are terrible on the floor. And then like one day goes down and like 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 where CTO is doing coding in the environment. Like I think stripes, CTO did this like once for a week, every few months, and then felt like, oh, this is painful. 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 users are feeling they need to go base and 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 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 startup, okay, you've just found product market fit, but there's 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. Yeah, it's really hard because every single day we wake up, there is a thousand people yelling at us telling us to do xyz things, there's a thousand people telling us they're doing everything wrong. Every single day, there is a competitive new product that shows up very overstimulating. If we let ourselves just get pulled by those forces, I don't think of 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

in the past, I would realize, oh, there's 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 know, as an agent to go implementing a new pattern everywhere, it's very easy to clean up tech that is very easy to like find new patterns and put 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 result 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 is happy. We feel good.

We feel good. We feel good working there every single day. It's not this thing where it becomes miserable to work there. We can't get anyone good to join us. It's mostly about slogging through legacy stuff. And in this memo after you listed all these things and you were basically saying,

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. 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, I don't know if we actually are going that fast and I don't think we're going any slower than our competitors. We're certainly not going any faster than them. So you're trying to look at productivity. It's so easy to

trick yourself and thinking you're being more productive. And you sit down and really look at it oftentimes. It's not as crazy as you expect. I guess what you're saying is don't be complacent and accept. But just be critical and look at is this working? 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? And 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, especially when it's really trending on social media. Again, you're a lot on access 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 as VC folks that all said, like, yeah, this is what it said, the 24 to 29 year old and you're will soon become the most valuable asset in technology pre because they have pre 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 killing it again. They have no preconceptions of what used to be possible. And you did call BS on it. Can you talk to me? Well, it's funny because like I'm just so tired every single day I wake up and open the

feed and just prediction of prediction of the future is going to be like this if you're just going to be like that if you're just going to be like that, I was 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 of this advantage. It's like everyone is just staying monstrous themselves because the root thing that's going on here is we are experiencing a moment of great change. Everyone 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 face 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 rationalizations 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.

Yeah, I'm just tired of predictions. Yes, we're going to time a great change. I just focus on the next day. What can we do today? What can we do tomorrow?

I didn't know I was working on this a year ago. I don't know why I'm working on a year from now. I'm just trying to do that thing that makes sense right away. This thing about how young people have, that's always been a thing. Young people have a lot of advantages. They have a classic

disadvantage of not having a lot of experience, but having a lot of energy. 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 funny because he like that one's particularly funny because he said 24 to 29. Why not like 18 to 25? You know, just so it's clearly he falls in that age range is why he's saying

that. It just like, yeah, it just made up. I think everyone is like nervous and worried. I think it's good. So just be honest about it. Because it's true. Like, I mean, I'm nervous and

worried as well, just because it's the changes faster than before. And this is talking with like the greats of the industry who have lived through the Kenback, 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 not this one two or three years. And they're all saying the same thing that the change is faster. But yeah, like as you say, like it's very easy to rewrite history and say like it was always

obvious, but it's just hard to tell. No, it's not yet. So on obvious everything that ends up happening is always counterintuitive. There are always people that like see it correctly and like line themselves up properly for it. But none of the obvious things ever happen. It's like it's 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 tools and hindsight. So yeah, predicting is a lot harder than people think it is. So so far with with open code, especially with open code, 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 from the early days or the ones that you've learned and you've stuck to them and it helped make open code successful as well? Yeah, 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's hearing my product to like, seeing the value in it. Very hard to

keep that minimal, very hard to like not let that creep back into a constant thing. So we do this, I do this thing where I have a command that like runs up in the daughter container and runs open code, which lets me experience it the first time experience. I do that like once every two weeks. And 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 better at. I used to be horrible at it. I'm okay at it now. I've probably got another

few decades of getting better at it. That's what I'm focused on. Like how to build stuff that solves problems well. And AI has not helped me even a little bit. What has helped you there? What

has helped you to get this product sense better or like figuring out? Because it sounds like we talked a lot about thinking, about reflecting about having one elegant solution that can solve multiple seeming unrelated problems. I mean, it's just a years of experience in situations with 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 being sure everyone, 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 better. And I take a lot of organizations. It's hard to keep that type of situation as your company grows. I think it's probably impossible. 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 shift something faster, so it'll cut stuff to get it out sooner. The pain is not felt by them. It's about by their support team. The support team deals with angry people and the support team fixes things mainly for them. And the engineering and product team

are like, you know, hey, we did it. We should have the future and they don't realize that there's like a side effect that they created. So yeah, really being in that feedback loop just makes you better. And they're caring a lot about building something for a lot of people. I think it's another thing that you don't have to try to build stuff from them to 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 they're doing it wrong. They think you're

focusing on the wrong stuff. But if you really are going for the whole market, like you just sort of think very differently. Can you let us in a little bit of how the Open Cool 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 figuring this out because we've grown a lot recently.

Like we're at 20 something people now and it's happened in the last couple of 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 everyone is still kind of getting situated and getting up to speed, etc. So we're trying to make the phase as fast as possible. I think for us, we're very, we're not a business company. So which

means all of our code is already public. So we kind of build in public as much as we can. We've been trying to get a good terminology for this, but if we have 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 something a lot of work to do, but at that point, most of us figured out and most just like fleshing out the details. 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 to there as fast as possible. And from there, again, because we're so public because our user is so vocal, people tell us exactly what to do after that. Like once their foundation is there and people can roughly get what they 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 that's like receiving feedback and summarizing it from engineer, they're receiving the feedback, they're getting the GitHub issues, they're getting the replies on Twitter, and they're figuring out the roadmap and the cycle for it. So that first phase is the hardest. But from there,

again, the feedback we've picked 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, motivations are a huge thing, I said earlier, we know it's a long game. If it's a long game, your strategy should be, how can I stay in the longest? The only way to do that is to work on stuff that is exciting every single day, who kind of let the whole team grab stuff that they're excited about. What's the biggest

problem they wanted to 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 the right context of what's going on. So typically people just grab stuff. There's been times where from our team really want to work on something and I like vocally disagree with it, I don't think we should work on that. And they've been right, like a few weeks later, I realized, oh, they were actually corrected about it and I was wrong. So it's really exciting to see your team be able to start

to do that kind of thing. One thing that comes up, we didn't mention it at the single time in this conversation, but elsewhere, it often comes up as taste. There's this notion or idea that one thing that AI is just very bad at and probably will say bad at is having taste and how is engineers taste, taste, product sense, I think that in some extent, in fact, I've even heard that Microsoft and Germany has a training for taste, which I'd love to see that one. What was your take on taste as a whole, 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 to taste and it's like a lifelong, yeah, you want it can be learned. It's like a lifelong thing that you can 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 other things. You can still be successful. When 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 just not going to ship your products. It's fundamentally you don't believe in it. And I feel 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. 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 go out 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 the products. For me personally, I care a lot about it. And I am nowhere near achieving my own bar. I'm like so missing my own bar and what I think what I believe is when you hear me talk about body and stuff, you're like, oh, it doesn't. He's like kind of ahead of what he's saying. That's

because I'm like still trying to get better at it. So I look at products that are really good. I'm so very inspired by them. I still have heroes that I think just kind of do a great job at certain things. And 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 and DevTools, I think Mitchell Hashimoto is like an obvious one. Our company is very similar to theirs and that all the products were open source. They became mass adopted. Things like Terraform

became the default. It's very hard to do something like that. And it's well executed across the board and the microscopic and the macro, the business model, his work with Ghostie has been really great. The architecture of it cares about every little detail and it shows up when he's a product. And he's very good at product. I think he has a, he made a clip that's very

something we're just talking about where every feature you're shaped. It's not about the features of how it interacts with every existing feature and his work as a product person makes sense of all that. And he's very good at doing that. I think he's probably one of the best for being also a good programmer. So I think he's one of the admire line. I hope that we can kind of be as good as that one day.

I sensed as we're trying to talk 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 goalie ads has left to hang on to? Yeah. Yeah. And I think the flip side of it is it's easier never to rot your product. I think it's

with these agents and everything. So you see what big companies, big companies products are rotting fast. Never even started with products. I was saying to their day like, now the product is your old. It's probably already kind of going to shit. And I think it's because of the goal. Please

agent workflows. But yeah, I believe that 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. And that's kind of what quality comes from.

You do a bunch of things and 50% of the things you didn't have to do. And I think very few people are going operate that way. There's a cold logic these days to programming into software and the products. It's like, I'm like a business guy and I care about business, which means I only do things that are hyper-hiperational. And a lot of people think that's what being good business looks like. And of course that can work. But yeah, I think quality is a huge differentiator. I mean,

even if you look at our story, when we first launched Open Code, 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, going on framework is like the first thing that's how you not to do, right? It's like a thing I know engineering you can do. It's irrational. Yeah, exactly. It's irrational. But like, it did, we looked at it and we

couldn't achieve the experience we wanted. Like, we were people that use terminal tools. We look at tools like NeoVim 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 it'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 Genki 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 are actually focused on some of the quality stuff that helped us go up against a much larger product company with a much more funding. What's your work setup? I've now switched

to a framework desktop. That's the one where you can replace the little like, thousands of friends and stuff. Yeah. So that running Arch Linux on a non-ultra, I guess the 5k display. Once I get this way, I'm just a Tying Window Manager, which I've been using for 10 years. And that's roughly it.

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-code terminals, right? Yeah. So I use a,

oh, I guess my setup is actually a little more complicated. So that is my physical machine. But I do all my work on a remote machine. So I stick to a much bigger B-fear computer that has many Tmux sessions going, one for each project, NeoVam as my editor, and then open-code. I usually split half, so like NeoVam on the left, open-code on the right, and I'm going between the two. So yeah, Tmux,

Arch, NeoVam, open-code. It wants 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 your technically leading a team now as well. And also like, when you talk with other, 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. And I think,

and on my hands, it makes sense, I know I have to do sure about it. I think these teams are now looking themselves as, okay, what's a well-of-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? I'm going to guard rail so that don't want to be able to do something.

It's not interesting about like, make sure you make sure your testing story is good. 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 role ends up being more like, how do I set the right guard rails to make it so someone that is using an agent can kind of blindly ship something that works? Well, whether it's another engineer, it could be a marketing team that is trying to ship a change to your website.

How do you make it safer to make changes? And this is like the novel way that it's not looking at engineering teams. The thing that I find interesting is that's not novel. It's 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? It's all the old stuff that we've always wanted to do. I would love to be able to hire a hundred engineers and have them be effective, but there's limits to that. We never really figured that out. And some companies did to some

degree, some companies 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 it's using code agents that's maybe how to design or ship stuff like that. So in a lot of ways, I think it's the same problem as always, which is how do you make databases that are easy to work in, scalable, flexible requirements. I think a lot of the old patterns from your coming back, we've always been like a big domain-driven company. We did it in a very lightweight. We're now doing it a much heavier way because we find

that these like kind of boring, enterprisey patterns end up being pretty useful because you have a bunch of 80s on your team now. The coding agents are a bunch of idiots and they are going to work 24 seven and they're going to like ship a lot of stuff. So you need way more garbage roads than you used to. And then 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're very verbose and going 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 explore that more and kind of enjoy that. Yeah, I wonder if design patterns might make their way back. Remember the 2000s or like mid 2000s, they were a huge thing of like, again, for structure, it helped junior engineers not mess things up. Yeah. And it was very verbose. So I 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 all the ways. But now like, you know, agents don't have training wheels to get them back on. Yeah. And what advice would you have to

more experienced engineers who again have been pretty good engineers until now? And they're like, I just want to stay with it, keep my game high and you don't have the skills and build up the experience. So like, 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 wanted to start up.

So the naly automatically a little bit weird too, 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 it generally applies to everyone. I think the most I could say is, and I've always believed even pre AI is a software engineering is a skill that can be applied to an industry. And you can just be a great software engineer. And that's totally fine. You could create doing that. But you if you also become an expert in a specific industry,

that's like a deadly combo. If you are like, just pick any interest, let's say, farm it's like, you want to say 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, 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. That's so exciting. I think software engineers are curious people. And it's just so fun to be able to like deeply learn an industry in that way. And eventually you'll find something that clicks they can stick with and being a good engineer and also be an injury expert. Like it's very easy to become a unicorn person that way. And then 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. Like 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 giving a task to like add something to the UI and like not your opportunity as a entrepreneur is you get to be in any company in the world and learn about anything and you just kind of like to get into that. I think it'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 changed how you think? Yeah, it's funny because I do not read books at all or reading recommendations. So I mean,

it's kind of expand that my wife is an 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. I got by the book. I did have a reading phase earlier on and it kind of helped help me understand like a lot of how the world works. I'm a big fan of these are like boring recommendations, but I'm a big fan of a bunch of Teles work. I think he's basically got like a couple of good ideas and it's maybe hard to read a whole book because the book is just one good idea and so book. But these are just fundamental true things about the universe that you can just see

play out everywhere. So he's kind of like a sub-expanding game. Obviously black, small, and super popular. A lot of this stuff that I found to be very influential on myself is the idea of emergent properties. So almost everything great in the world is came not through like top down design.

It came through a bunch of smaller entities operating together randomly and it's something kind of great comes out of that. And you see that whether it's in like robust software or like what makes a city great, what makes a neighborhood walkable, what makes like an organism like capable surviving disease. So it's all like bottom up, first top down in terms of design systems. There's a few books that talk about that. It's one of them. And I feel like I see that everywhere.

Like once you kind of understand ideas, you realize I can't underpin the whole world. Dax, thanks so much for this conversation. This was fun. 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 prequel. 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. 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 appreciate 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 started 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. And if you'd like to support the show, leaving a rating or a review really helps. Thanks for listening and see you in the next episode.