Tecnología Informal

So all these old, annoying practices that felt unnecessary, the LLM really, really, really likes because it's very easy to build something simple for the average person. That just does not work for a team of 10 or 50 or 100.

Programming has gotten a lot more enjoyable. I'm spending a lot more time on the parts that are fun and challenging and a lot less time on boilerplate.

---

Introduction

Okay, so this is a very exciting episode of Tecnología Informal. This is actually the first episode I do in English. I wanted to invite someone who has a lot of weight in the technical community. I've been following Dax Raad on Twitter for a long time. I like his takes on open tooling, his Twitter fighting, his opinions on career, on the future of work. I think Dax brings lots of new ideas and deep thought into an industry very used to soundbites right now, especially post-AI.

He's now founder, co-founder of SST. I don't know the exact story there, but SST is one of the most important platforms today to do infrastructure as code. You can use it with JavaScript. So, if you hate Terraform, use SST. Definitely that.

Dax, please introduce yourself.

—Yeah, I mean, that was a great intro. I'll try to live up to it. I think you covered mostly everything. I am a founder. I've been building things for developers the last four or five years, kind of when I started to be a little bit more public. I spend a lot of time in this space, so I tend to talk a lot about what developing looks like today, try to figure out where it's going to go. I get to spend a lot of my time building open source, trying out everything. That's one of my favorite parts of my job. It is literally my job to try out all new technologies as deep as I can. So, yeah, it gives me a pretty good perspective on what's going on.

We'll get to talk a lot about dev tooling, but I do have one very important topic to discuss first. I see you on Twitter talking about steaks all the time and that there's an Argentinian butcher in your life. So, I need to know what you think about steaks and about Argentinian beef. I need to know.

—Okay, so, for context, I have always loved steak, and I spent roughly three months cooking two steaks a day. And when you do that, you get to experiment with all different variables and really fine-tune everything and figure out what you actually like. I live in Miami, and we are very fortunate that there's a place called Graziano's there. I think they're originally from Argentina, and they settled here in the 50s, and they established basically a supply chain between Miami and Argentina. And now they have several locations. They have their own steakhouses, but they also have grocery stores where they just sell beef. So, for American prices, I get a pretty good deal for the quality, I would say, through them. That's not the only place I go. I also get all other kinds of steak as well. But, yeah, I'm a big fan of... I mean, I'm very jealous of your guys' barbecue situation. One, it's so cheap, from what I hear. And two, I've seen pictures of the big enormous spreads. So, definitely jealous of all of that.

—Oh, yeah. It's really, really cheap. But it doesn't have as much infrastructure. We don't get huge fridges. It's a very common thing from Argentina. I like reading books, of course, and I read The Wealth of Nations by Adam Smith. He actually has a section talking about Argentinian beef.

—Oh, really?

—Yeah, imagine, 200 years ago, the guy is talking about the American Revolution and why beef is so cheap in Buenos Aires. Literally, he talks about that. It's been a thing forever. We have so much land, and it's just like the cost of going and getting the cow. That's his thesis. It's so cheap to raise cattle here. So, that's why it's so cheap.

—Yeah, that's awesome.

---

Founding Journey

Let's go to the main course, then. I like that, in your introduction, you mentioned very quickly that you're a founder, that you're an entrepreneur, independent. What's your path to this decision? Did you always want to be a founder, or did you work developer experience at some company and then said, hey, I want to work on this?

—Yeah. So, I pretty much was a founder from the beginning. My history is, I started working out of high school. My dad's a software engineer, so it wasn't that crazy for me to start doing that stuff from a young age and get into it professionally. About six months into that, I ended up starting a company with a friend. This was in 2012, I would want to say. This was kind of when, at least for me, I was learning about the concept of a startup, the concept of a tech company. I lived in New York at the time, and there's a lot of that stuff popping up there. So, it was a very exciting time. I was very attracted to the idea of founding a company and selling it. That seemed like such a crazy dream. Worked on that for about a year and a half. We did end up selling it. Nothing crazy. It was like an acqui-hire to another company. Ended up leading engineering there for about two to three years. Then left and decided that I wanted to be a consultant, mostly because there's just a reality in software where you can get very good at software engineering. If you learn the right tools and you're effective with them, you can be multiples better than the average person. But a normal job doesn't really compensate you in that way. You'll maybe earn 20% more than the worst person on your team, but you're not going to earn twice as much. My dad spent a bunch of time as a consultant, so I was like, yeah, I'll just be a consultant.

So, I spent a bunch of time working for a bunch of different companies, mostly startups. That was a break for me to try to understand everything that's going on around there. Ended up founding another company. This one did better than the last one and was going really well, but then ended up going not so well and actually ended up being fired from that company. But it's where I met my wife, so I did get some kind of nice exit.

—Was it a product company or a consulting company?

—No, this was a product company. We were building software for healthcare and transportation space, just trying to solve some problems that existed there. The product itself worked really well. It's just a classic situation where I focused a little bit too much on engineering and offloaded growing the company to the CEO. He was very young, much less experienced than I was. He just made a bunch of critical mistakes that created a massive split in the company, toxic over time, and eroded everything that was working. I knew I was going to get fired because at one point I was just refusing to work and just buying time for my engineering team to find new jobs. It was kind of a disaster at the end.

Again, I went back to consulting. Somehow ended up as director of engineering at a company that was growing pretty quickly. My first role as a middle manager anywhere. Interesting experience. Ultimately, I just knew I wanted to continue founding again. I had a lot of time to experiment with stuff, so I ended up playing with AWS technology. I've always built in a way that was agnostic to the cloud, so I was like, let me flip it around and try to really learn the cloud and see how that feels. I was learning a bunch of AWS stuff, realizing the tooling was pretty bad. I was working on some of my own tooling, which was okay. Obviously, you can't build great tools at the beginning of your journey learning something new, but I was trying anyway.

Ended up coming across a project called SST, which was just launched very early, barely anything. Started using it, started contributing to it. There's a company behind it. I ended up investing in the company—they were raising a round. Then a month later, they were like, hey, do you want to join the team? Then I was like, that's awesome. Yeah, that sounds great. They gave me my money back, except now I owe taxes on it. Don't invest and then join the company. Go the other direction. Just figure that out ahead of time. I've been there since then. It's just been the three of us for the past five years or so.

—When did you become part of the founding team of SST?

—This was in 2021, I think. It's been four years. They were right at the end of doing YC when I joined the team. They started the company prior to that, too. They were actually working on something else. Going through YC, and YC is very good at this, got them to work on a bigger idea that seemed more implausible. One of the best reasons to do YC, they'll push you to do things that you don't believe you can. That's when I joined them. I didn't go through YC personally, no.

---

SST and Infrastructure as Code

I like this idea that YC pushes you to aim higher or bigger. What was the switch? If it was already a tooling for vendor-agnostic infrastructure?

—SST didn't even exist at all at that point. Prior to then, there was an existing framework called Serverless Framework, which was popular back then. They built really good CI tooling around it. If you were a Serverless Framework user, this is a really great option for you to ship stuff to production. It was a great product, and it was making money. They even got to break even. If you really think about the underlying dynamics, it's like you can only ever be as big as Serverless Framework is. The moment Serverless Framework is not doing a good job, your company's dead. It's downstream of that. It doesn't really make sense as something you bet 10 years on. I think YC helped them understand that. They were like, you need to go do your own framework. Try to be bigger than Serverless Framework and try to fully control your full destiny there.

How do you view the market positioning of a tool like SST versus using Pulumi directly or using Terraform? I'm using SST at Silver.dev right now. I'm not coding every day now, but I see how it works. It's way more readable. I hated Terraform. I used it a little bit. Just random files. But I want to understand, what do you think is the vision of SST in an environment where there are so many other infrastructures?

—We did not invent infrastructure as code at all. This has been around for quite a bit of time before us. I would say infrastructure as code is a great idea. I think every software team should be using it to some degree, whether SST or Terraform or whatever. It's just generally a good idea. It mostly found success within the DevOps part of the world, people that were responsible for managing infrastructure. If you look at tools like Terraform, they're really oriented around that. It's more config-oriented and not tied to a specific language. I think they've done a great job capturing that part of the world. That part of the world is still tiny compared to the overall software engineering market.

If you think about someone, we try to build tools for ourselves. We've always built startups, early stage companies. We don't have a dedicated DevOps team. Us as software engineers building product, we need to also do the infrastructure and make decisions there. As time went on, to be a good software engineer building product, you did need to understand infrastructure because these are things that you can take advantage of to solve problems. As those two roles started merging, that's where SST sits. We're trying to bring these ideas of infrastructure as code in a package that makes sense for software engineers. If you're building a front end, you're likely using TypeScript. It's nice that the infrastructure stuff is also in TypeScript. We also talk in terms of high-level components. We have components for Next.js, for CanStack, for SvelteKit. These are things that product software engineers are thinking about.

The way we're designed is on day one, you can use SST without knowing much infrastructure because it's very high level. We take quite a bit of care not to provide brittle abstractions because on day 100, on day 1,000, you're going to want to dig into the infrastructure deeper and configure some of these underlying levers that you have. SST is built in a way to progressively disclose all the way down to that. You start on day one not knowing much. Most of our users become pretty good at infrastructure as time goes on. The idea here is companies start out the same, but as they get more mature, they all need weird, different configurations. They do things that are more complex and do things that are more unique. That perfect, little, simple platform that you can build for them on day one just doesn't work as they grow out of it. That's how we're designed.

—Who would be the biggest infrastructure that's being handled with SST right now? How big is it? How many computers does it have? How many resources?

—We know of teams of hundreds of engineers that are entirely building with SST. We've had a funny history where most dev tools start, like indie devs like them, and then you try to grow to a point where bigger enterprises can use you. We've had a weird opposite direction. I think because we were so focused on AWS and big companies use AWS, we got the big companies first. We had Comcast using us. We had AWS themselves using us. We had a lot of these big initial customers, but our experience wasn't very good for the individual. So our journey was like taking this enterprise-y tooling and bringing it down to the average person. That path was difficult, but what's nice about that path is once you succeed, you don't have to worry about trying to go upmarket, which is very difficult because it's very easy to build something simple for the average person. That just does not work for a team of 10 or 50 or 100. So we went the other direction, which I think was painful at first, but long-term works out better.

—But do you get people that use Terraform to say, hey, from now on, the next infrastructure, we are going to build it with SST. Do people migrate?

—So the tricky part is at companies that have DevOps teams, they're not going to want to switch to SST. One, probably don't even like TypeScript. It just seems random for them to use that. And they probably have years of Terraform that they've written. The format we've seen though is where incentives are aligned is the DevOps team wants to control things like networking, things like firewall policies, things that are shared across a whole org. They don't really want to get into the weeds of, hey, SvelteKit needs these exact cache headers in our CDN. They don't have the perspective for that. So what we tend to see is the DevOps team continues to deploy these shared resources like VPCs, subnets, all the firewall rules, with Terraform, whatever tooling of choice. And the application-level developers will import those into SST, but then deploy things like their front-end queues, maybe even their own databases using SST. So it tends to be a little bit side by side.

—Okay. So what I will say as a compliment is that it definitely worked for us. We have only a single software engineer and an intern right now, and he chose SST. And he was like, okay, now I understand all these parts of the infrastructure. We have this weird requirement where we need to sync with another database somewhere else and bring the data and sync it with our ATS and stuff. And then he built everything on SST and I can read it because I can read TypeScript easily. So it's good. So it's definitely working there.

---

Dev Tooling and Open Source Business Models

I want to share my perspective on the industry of dev tooling and open source, and I'd like to know what you think about it or what's your take on working on this industry. On this podcast, I have a series where I explain a little bit about what's unintuitive or unique about each market. And I think dev tooling is a very particular space, and that across time you've got thousands of people, I don't know, putting a lot of effort into tooling they make no money off. They make jQuery plugins and stuff like that. And then you have all the issue on how to monetize that. Monetizing that code is really hard, but I've seen the one big thing that really works is when you have a tooling that has reverse churn. Like when a company starts with SST like us, Silver.dev grows to Series B, it blows up, and then now costs go out of control and everything goes up. And then I think that's the business of AWS. Part of me truly believes that a great part of Jeff Bezos' fortune is developers being very negligent with our infrastructure. And I've always found that big companies, people using millions of dollars of unused resources and stuff like that.

But regardless of that, it's like building a tool that becomes really cheap and accessible first for the first users. And then as the business grows, then that's how you make money. When corporate buys millions of computers. And the same happens with AI. Everything that's happening with AI right now, even the applications like Cursor and stuff like that, they work because they are easy. And then a company says, okay, everyone has to use Cursor and pays for everyone, and then everyone has that. And then the more people join the company, the more people use the tool. So I get the feeling that success here is marked by that capacity to go to become really easy to adopt, and then get like a very natural working vendor lock-in, and then you make money when it blows up.

—Yeah. So that's pretty accurate. And I actually think this is why most DevTool companies fail, because it's actually a B2C company. So you're right that the monetization is like, it's technically B2B. And everyone looks at DevTools like a B2B space, because obviously your customers are businesses that pay you. But what's tricky about it is that's not what it is on day one. On day one, you need to market a tool that is widely used, so widely used and easy to use that people can just sneak it into their workflow, that it eventually makes it into the companies and grows. And also, it doesn't make the companies outgrow it. And this is like such a crazy set of things to try to get right. Which is why most DevTool companies don't work out, which is why I tell people like, don't build a company in this space. It's really, really hard. We've just seen so many companies die out. And we kind of face some of our own challenges as well.

The second thing that's hard is if your product is open source, you have to actually build two good products. You have to build a product that is open source that people love, that gets adopted by a wide percentage of the market. And then you need to build a complementary product that is also really good. And some percentage of people upgrade and pay for that. And there's been so many companies that have done one thing, but they couldn't do the other thing. And even big successes like Terraform, their situation is funny because they have... Terraform was so successful that their complementary product, the bar was pretty low on anything they built would have made a decent amount of money. But they didn't do a good enough job where there's two other companies building similar products to Terraform Cloud that are also very successful. So it's so hard to be the winner in both. So yeah, it's a very, very difficult space.

And I think the B2C aspect of it is funny to me because developers are attracted to DevTools because they're like, I'm a developer, I understand developers, build what I know, and that makes sense. But I think most developers are actually really bad at building B2C types of products, because you almost have to think about it like a social product. It needs to be extremely easy to use. You have to get to the aha moment really quickly. It can't be this thing where you're like, well, you should know how to use this, or you should be smart enough to configure this, you know? That's what the mindset developers tend to have. But it just doesn't work for something that needs to be... The scale you need to have a successful DevTools product, it's no different than launching a competitor's TikTok or something. It's pretty similar.

—It's a very demanding user because you need to get into their day-to-day. So they actually are very picky and low tolerance for BS.

—Yeah. And even just getting them to understand what you're doing, like why your thing exists, and them having a good experience right away. And the reason that's important is people aren't starting new projects every single day. Like, they might hear about your product, they'll probably give it a quick spin, and it needs to leave enough of an impression on them so that six months down the road, when they are starting a new product, they remember to go back and try to use your thing again. So yeah, it's very hard, and I don't really recommend people build DevTools. It's a challenging space.

—The famous phrase, I'm not doing this because it's easy, because I thought it was easy, right?

—Yeah, exactly. It's true of every single space, probably.

---

DevTools Companies and Business Models

I have two questions here. One of them is, what companies do you think are doing a good job in understanding and executing this, in saying, hey, I first need to charm my developers, and then I'll build a product that will work for them, right? And instead of this question, I'll put one company that gives me a strong impression, which is Bun, right? As a developer, I look at Bun, and it's like the value proposition as a developer is so obvious. It's like, it's going to be faster, and a bunch of things. And then I say, how am I going to pay you? I want to pay you something, and I don't know how to. It's like, it doesn't connect.

—Yeah, it's funny you say Bun, because that's actually my answer, too. I actually think Jared is the best DevTools founder right now. So I think he has this very unique, pretty incomparable crossover, where he's obviously deeply technical, but he comes from building mass market social apps. It's not his first time being a founder. He's launched things before. And he's launched things that have gotten millions of users and have gone viral. So he looks at things from that perspective, and almost no DevTools founders think that way. They're very more like B2B, slow growth mindset. Whereas Jared is like, anything that makes this incrementally more viral, I'm going to do, and it's our job to do.

If you look at the trajectory of Bun, it's so funny, my personal trajectory of using it, they were like, Jared was like, okay, I'm gonna make Bun a good package manager. And I was like, okay, that sounds like a good idea, but I'm not sure. And I was like, okay, I guess I'll use it. It's pretty good. It's pretty fast. Then I'm like, okay, I have these scripts I need to run every once in a while. I'll use Bun for that, too, because it works for that. Okay, now I have this internal Docker container I need to run. It's TypeScript. I don't feel like figuring out a build process. I'm just gonna use Bun for that. It's not a big deal. It's internal, right? So it just kept sneaking in. And this is brilliant execution from Bun, where I was skeptical of using it in a tiny place. And before I know it, it's taken over my whole workflow to the point now where OpenCode is literally a Bun single file executable. So that's masterful execution. You don't really see that from a lot of people in this space. Again, they have a long way to go before they truly can claim success, but this kind of execution, you don't really see that often.

—And how are they going to turn that into a sellable product? What's your plan?

—I have talked about this before in a few other places. I think the part here that's counterintuitive is everyone looks for the business model early, but it's really difficult to even envision the winning business model early. So an example I always give is, if Google didn't exist today, and they launched today, and they got really popular, like a bunch of people are using them, not the whole world, but early adopter, they captured 2 or 3% of the world. Super hyped. Everyone's like, this is awesome. Google is amazing. How are they going to make money? What is every single person going to say? They're going to say, give everyone 50 searches for free and charge them $20 a month for Google, right? That would have been everyone's go-to monetization plan. It would have made a lot of sense. That's probably what they would have done. And they would have missed out on becoming a tool that every single person in the world uses. And turns out, when you hit that, there's this crazy ads business that you can attach to it. That is literally a trillion dollar business. So it's really hard to envision these things. And you have to take goals one at a time. The goal right now for Bun is to become default for JavaScript. Any other goal just kind of doesn't matter, because if you fail that goal, there's no point on monetization. There's nothing really to do here. If you become default for JavaScript, I think we'll start to see business models that we couldn't really imagine until that happens. So I don't know what it is. For me, the question right now is whether or not can they flip the default from Node to Bun? That's still a big question, right? How are they going to do that? But that's kind of why that's their singular focus. And I guess everyone on the outside, it might look like, oh, they have no plan, and they're not going to make money, and they're going to implode. But it's more just like, you need to do this thing first before you do the other thing. And there's no point doing the other thing without the first thing.

—Okay. I have two observations. One of them is that I agree. I had the same experience with Bun. When they announced it, it was like, this is super incomplete. I'm not going to replace Node or my production environment with this. No way, no how. But I'll run my unit tests with this. And then I already had that. It was already in. It's like letting the wolf in the hen house, right? Now it's easy that, oh, it comes bundled with Redis. So I don't have to install Redis for this little component. Okay. And so it's a good observation. It's actually pretty deliberate that they do this.

But I have one counter argument to the idea that sometimes you don't know the business model and you just want to have market share of attention or something else, which is that if you don't charge, you don't know the exact value proposition you're giving, right? So you don't know sometimes that if you, you might say, hey, I'm going to do a corporate service somehow that I'm going to make your CI in JavaScript cost one-fourth, because this is way more efficient, right? There's some value there somehow. But maybe when you do that, people say, hey, you know, it's true, but I don't want to pay for this. I don't care. I'll just tell my DevOps team. So sometimes having no price at all does open the window that you're not sure if you're giving the right value proposition to people. Personally, my way of doing product is I always like to charge people. In fact, I want to add zeros in the numbers, right? Like I hate it when people come to me and say, oh, I'm going to make a JavaScript Bun something and you'll get a special version for 10 bucks a month. And I'm saying, no, start with a thousand dollars a month and then see what people ask you for that. And then go from there, right? You know, pricing, you have no idea. People don't reveal their preferences.

—Yeah. I mean, that's definitely true. It's a true dynamic, but I would say the difference here, this is that, this is the reason I tell people not to do DevTools, because they have to do two products. This is their first product. They're never going to charge for Bun. Like it makes no sense. Like that's never going to be the viable path. Their second product, which is the one they actually decide to like take a swing on is how we're going to make money. Yeah. They need to charge for that right away. I think that's exactly what you're saying.

---

Auth0, Vercel, and Next.js

So Argentina has two very famous DevTooling companies, right? One of them was Auth0, very B2B authentication. I would say Okta, very corporate. And then we have Vercel, right? They hit it with Next.js. That was an example, right? An open source product. And then they monetize it with their infrastructure.

I've seen your spats with Guillermo Rauch on Twitter. Sometimes you say, hey, I built OpenNext. And then the Vercel people don't maintain this package very well. Then you say, hey, I actually connected with Vercel. It was kind of fine. I'm going to say like, okay, let's go real. Like what's your actual take on Next.js as a package?

—Yeah. I mean, the history here is just, it's pretty straightforward. We built a tool that was decently successful for AWS users. Our users kept coming to us for literal years. We ignored them being like, please help me deploy my Next.js app. Like it's so hard. And like, I don't know how to get this working. There's so many features and whatever. So eventually we begrudgingly put together a package that helps deploy Next.js efficiently on AWS. And that involved us like reverse engineering a bunch of stuff, like figuring out where the gaps are, figuring out where the bugs are. And there's a crazy long tail of problems. And this is, whenever I talk about this, there's always some guy that replies being like, you guys are all dumb. Like I just deployed, I'd have like five Next.js apps running on a server. Yeah. It's easy for like a simple case. But if you're thinking about like thousands of companies deploying Next.js with all the features it has, there's quite a long tail of stuff. And it's pretty hard to get something working across the board.

For a while we were like on our own trying to figure that out. And it was funny because none of us are Next.js users. Like I'm not, Frank isn't, Jay isn't. None of us really like Next.js. So we just weirdly became experts on how it worked under the hood. But like, we're not users. So it was this funny situation that was there. And we always had the position that like, we don't want to be doing this. We're only doing this because like we have some like, it was community to serve. Ideally, like this just isn't a problem at all. Painful distraction for us.

Thankfully, after some time, it became more community run. There were like some great, great contributors that stepped forward and like made the project really mature and kept up with all the changes and stuff that broke. And eventually we did end up connecting with the Next.js team and Next.js team merged directly with the maintainers. They've patched a bunch of stuff within Next.js to like eliminate like large portions of open code from even being necessary. With a long term goal of it being like 100% unnecessary. And I've always said from the beginning, like I think whenever I talked about this, people have thought I was implying that they were making it difficult on AWS on purpose. I've always tried to be clear that I'd never believe that was the case. I think what happens is they have a framework, they have an infrastructure product. When their users have a problem, they can either solve it using infrastructure or an open source framework. The ideal solution tends to be a little bit of both. But then, you know, that's not very portable. So I think it's like a natural side effect of that structure and then trying to solve problems. Obviously, they're going to prioritize it working well on their platform first. And now they are eventually getting to like try to close the gap. But it's always going to work best on their stuff. I think that's always going to be true. But you know, it was never like a malicious, I want to like force abuse of my thing type of thing.

—You do mention that maybe you don't like Next.js or you don't use Next.js. What do you think is...?

—I don't like Next.js. Yeah, I think it's... So I'm going to, I guess what I will say is it's the default. If you're building anything, you're probably gonna use Next.js. That's fine. That makes sense. It's like one deposition. I basically have never had a reason to use it. I tend to build productivity apps that people spend hours in. And the architecture that I need for that Next.js can technically do, but it more gets in the way than helps. So I think it's a little overused, especially in like SaaS products. I think it's very optimized for, really optimized for where a lot of Vercel's customers initially were, which tends to be like big public facing e-commerce type businesses that have like lots of users, short sessions, maybe not many of them return. Those traffic patterns look very different to like a productivity tool you're selling to businesses to do their work. Like the users come, it's not a lot of users, but they show up every day and doing work in there for hours every day. So I think the architecture for me is never matched. And to me, there's also like a there's an approach thing. I think they, I just don't jive with their approach. I think they tend to try to make all this crazy stuff work out of the box, like all the crazy optimizations, all the craziest like, you know, things you could do. And I find that tends to be pretty brittle. Like when I want to have a little bit of control, it like breaks and I'm like sucked into thinking in terms of Next.js. I'm not thinking in terms of the web. So that's like a personal thing for me. Like I don't, I just don't, it just doesn't click with me. But, you know, we spend a lot of time supporting Next.js and helping people deploy their Next.js apps.

—So when you say you would use like a different architecture for power users, do you mean like an SPA? And what do you use as a framework? Do you use like a Vue, Vanilla, React or what?

—Yeah, so I found very little need to graduate out of an SPA. Like we've needed a couple SSR things here and there. And we found that most of the stuff that we build, it's like 95% SPA. Some SSR stuff is like a nice little bonus. So orienting entirely around the SSR side just never made sense for us. So we still stick with Vite. I switched to SolidJS like three or four years ago. So I haven't used React in quite a while. But, you know, that part doesn't really matter. That's just like a personal thing. But we pretty much only build SPAs. We've been doing Sync Engine stuff for probably four or five years now. We've had like three products that are fully on Sync Engines, gotten better at using them with each iteration. And we find this to be like a really great setup for producing really good feeling apps.

—Wow, that's interesting. I'm a front end engineer. So I'll tell you a little bit about my story with Next.js. And I want to talk about the Sync Engine thing. I used to do like Ruby on Rails full stack development back then. And then, you know, React came about and you had to configure it client side. And I remember that around 2015, 2016, was it? I remember that you had Gulp and Bower, you had Webpack. You wanted to build a page and it took you hours of configurations of like very weird models. And then Next.js show up and it's like, okay, your default works. That was magical. That cut down like hours and hours of configuration that was really painful also. And I remember, so I did all the migrations from Next.js 1 to 15. I did all of them across multiple companies. I know the history, right? And it's like, yeah, we have this new concept, getInitialProps, and then you do it this way. And then it's like, hey, but how do you do authentication with this? That's unsolved yet. And then, you know, you have to do a migration and it's like the migration had like paradigm changing things. Like it wasn't just like incompatible. It was like, this is a new paradigm, right? So it was pretty painful to do like many, many migrations.

But the cherry on top was when I worked at Robinhood and OpenSea, both companies wanted to use SSR and could not use Vercel, like as an infrastructure. By policy, legal, we don't want to build something else because we could leave. And then I had to face this issue. Okay. Time to host Next.js on my own. And that was pretty painful because I didn't know, right? Like you look at the documentation, it's like middlewares. Okay. You put it, it works. You deploy it. It blows up. It makes no sense. Middlewares are supposed to go on an edge. They're not supposed to run in your server. And it's like, it's a different runtime. And so I think I share a lot of that pain of like how hard it is. I also don't think it's malicious, but I do think it's just a mere incentive. Like I will be a little harsher than you were because I think it's simply that, you know, they make money on the infrastructure. So they have to, they don't have any incentive to prioritize like Next.js being an independent product. And I think that's lots of people in the open source community that I talked to like started feeling that in 2021, 2022, which is, it's not the approach you said. There's an open source and a business. Now it's kind of merging into one thing. And it's like, now you want an alternative and you have all that, those issues.

—Yeah. And I think that's actually the right way to look at them. It's there. And there's so many products in all sorts of the world that follow the shape. It's a vertically integrated product. There is a framework that is integrated really nicely into the infrastructure. You should buy that whole story, right? Like if you are buying into Next.js, you should be buying into Vercel because that's when you're going to get the full capabilities of it. I think people were into trouble when they like tried to buy into one half and not the other half. You might as well just use a framework that is oriented around deploying everywhere because they're going to like care about your use case a little bit more. I think the gray area is Next.js is a default. So when people are choosing it, they're not like consciously thinking about it in this way. I think people understand a little bit better now just because it's been talked about a bit more. But yeah, people always think that I'm like going around trying to get people to move their stuff off of Vercel. Every single conversation I've had, when someone comes to me being like, hey, we're thinking of moving off of Vercel, I'm like, are you sure? If it's working, just pay the price because it's not going to work as well outside of it. And you should have a really, really, really good reason. And whenever someone comes to me with Next.js, I just tell them, just go use Vercel. That's where it's going to make the most sense. Deal with it when it's a problem later, not ahead of time. But yeah, it's interesting. And that's roughly similar to like we see this everywhere, right? Like Apple is crazy vertically integrated. That's why their products can be so great at times. Because every part of the stack like works together all the way down to the CPU to the software. But another time you need flexibility or we don't fit perfectly into their bubble. It's like a nightmare. It tends to be I think most industries fall into these two versions of product. And you have to make sure you're consciously choosing one or the other.

---

Sync Engines and the Future of Frontend

So I want to pull the thread on the sync engine. My experience was that in 2021, I looked at Linear. I had my first experience looking at Linear. I was like, what the hell is this? I was shocked. It was like, how did they build these things, right? Literally I had that experience. And then I look at it a few years later and I say like, hey, this is like going back to building desktop apps, right? Like just like how did you build with all your data locally, fast, quickly. And then that kind of like an idea I have. You mentioned that you've been working on sync engines for some time. Do you think that's going to be like the future of it? Like is it going to be a default? What do you think is going to happen here?

—Yeah. So it's funny because I also had a similar experience where I use Linear and I was like, this just makes everything I've ever built feel awful. And for two reasons. One, like they're just very good at product. So like that is just something that you can't replicate. But then the other half of it is architecture, like you mentioned. And I was so confused for so long. I'm like, how is the whole industry just going about their day when this thing exists? Like, why are we all talking about like SSR and like edge rendering and all these like for years, that was like the focus. We're obsessed with like these stupid little incremental optimizations. When Linear was sitting there, basic React SPA with like styled components, like just out of the world experience. So I just was like so frustrated being like, why does nobody care about the sync engine thing? But after I saw that, I'm like, I gotta do this. I gotta like figure out how to do this thing. So I went on my whole journey trying to figure out where I should land on there. I did everything from having a JSON API connected to this library called Orbit, which like syncs it locally, ran into issues there. So okay, let me try the GraphQL space, try the GraphQL space. They have Urql, which also can replicate things locally. But again, like every iteration has got a little bit better, but it wasn't, there was something missing. And then I found RepliCache, which I think has the right mental model around it. They spent so many years working on sync across several companies. So they like really understand the problems that you run into. RepliCache eventually became Xero. And this is what I'm using across the board for everything now.

—Cool. Yeah. So, you know, there was one thing about the experience for the end user, which is fantastic. But about the developer experience, like my fear of someone, I'm not coding every day anymore. Like that's my reality, but I can make a decision. I could say, hey, I can tell my developer, just do everything on sync engine now, like go for it. And is it like, is it like sending him to kill windmills? Like, is it crazy? Does it have particular like edge cases? Is it particularly complicated? Like, is it a new paradigm? What's your experience working?

—Yeah. So I will say it's a totally different mental model and I'll tell you some of the experience of it. On the plus side, it makes front-end the dumbest work ever. Like it is, because most of front-end, the annoying parts of front-end is like mutating data, sticking with the server, like making those calls and like, you know, orchestrating all that correctly, loading states and all that stuff. All that is just gone now. So your front-end is just assembling markup, styling it. And the data is just always there and you can query it locally. And to illustrate how good this is or how simple this is, me and my wife have been working on a product. She's been like a PM forever, not a programmer. The past year, she's been actively working on our product, like programming it. I mean, for the help of AI as well, but she's able to do so much because all the data is just there. She's not figuring out like, okay, like I need a new REST endpoint. Like how do I talk? Like all that stuff goes away. So it's purely, I want it to look like this. I want it to behave like this. It's like pure UI work. That's a plus side.

Like with any new tech, it solves some problems and introduces new ones. So the new problems here are you got to make sure that your app really fits nicely with the sync engine. There's problems like what if the overarching data set is massive? You can't sync like a terabyte of data into the browser. Does it make sense where like the user only looking at certain windows of data at a time so we can rotate stuff in, rotate stuff out? Xero gives you really good tooling to do that easily. It wasn't the case with RepliCache. It was a lot more manual then. But these are like five problems. Like we were working on previous products where the full data set did not fit locally. So we had to come with strategies like, okay, for anything you've looked at, we'll keep it around for a week. And after a week, it gets evicted. So if you open it up again, there's a little bit of a loading delay. Some of the permission stuff is a little bit different. So there's new problems that show up, of course. But man, does it make front end really easy. And to be honest, it was like I've been chasing this Linear thing for so long. And finally, I'm able to build stuff like Linear. But then I was like, shit, now all that's left is being good at CSS and design. And there's no buying that. I can't just get that. So now that's where my bottleneck is to build something as good as them. So I'm working on all that stuff now. So I will say overall, it's good. Again, make sure your product, like productivity tools, like tools for work, makes a lot of sense for this kind of setup. If you're building like an e-commerce site or something like public, it's like you can make it work, but it's like you're kind of forcing it at that point.

—Yeah. This is going to be a dumb technical question, but suppose you have like on a typical website that you fetch per page, right? You have page, your profile, and then you go and look at your, I don't know, your public profile. Let's say you have a private profile and a public profile. How do you usually, how do the sync engines actually keep all the information like when you switch from one to the other? Because in a typical website, you go to one, you make a fetch, you get the information, you navigate to the other one, you make a fetch, unless you have some cache or something else. Like with sync engines, when do you do, when do you pull the information, all the information together?

—Yeah. So like the dumbest approach is you pull all up front when they first load. So like I'm just going to download everything I possibly need. Some apps it makes sense for, for a lot of them it doesn't. What's nice is the natural behavior of the user and like how your components load on the front end actually mirrors what they care about, right? So if you have a home page and there's like some kind of query for data that you know is needed for the home page, that's going to start being synced. So just the query for that for that page to render. It's not the whole data, just that data is synced. Then they click into another page, again another query runs the first time, you know as a round trip with the server, but then in the future it's going to stay synced. So if they go back and they navigate back or they refresh, it's now loading from local. So over time, based off of how the user explored the app, more things are marked as being synced. And you can add TTLs to these, so you can say like okay, like get rid of this after seven days.

---

Side Projects: OpenCode, Terminal, and More

Yeah, so you recently relaunched OpenCode. So this is actually a bundle question, because you mentioned working in healthcare, I see you working on Terminal as well, then you have OpenCode. So we have two topics here, like what are all these side quests? How does OpenCode fit into all of it?

—Yeah, so just to like list out everything, so I primarily work on SST, which is a framework, and SST Console, which is like our monetized product associated with the framework. I work on Terminal, which is like, I don't even know how to describe it anymore, it's technically a coffee business, but we just try to do crazy things for developers. You've probably seen our stuff online. I work on Radiant, which is a product with my wife. We haven't launched that yet, this is a personal finance tool, we pivoted away from the healthcare thing we were doing before. And now I'm working on OpenCode. It is crazy, and I'm probably gonna have to like reassess some of this stuff at some point. I tend to work on like one thing at a time for a period of time, and then once it's in a good place, I'll rotate. But right now I'm focused on OpenCode, so some of the Terminal stuff is suffering a little bit. So it's not like I really work on everything together. That said, it is a little crazy at times. But these things just kind of feed into each other. Like the work we do at Terminal is so wide-reaching, and it's seen by so many people, which allows us to launch something like OpenCode, because it's the same audience that we've built. OpenCode itself brings us to a new audience, which then sees Terminal, which then sees SST, which then sees... It's like an ecosystem that kind of feeds itself.

—And is OpenCode part of SST, or is it like a different endeavor?

—Yeah. So we're going to figure out the structure at some point. It's in limbo right now. The goal right now is just we want to get it so every developer in the world is using it. Once we get there, we'll figure out what structure makes sense for it. But my work for it right now is technically being paid for by our SST revenue.

—And to your pitch, I tried OpenCode yesterday, so beware. Beware about the promises you say here. I'll keep you in check. But to your pitch, what's your vision? You're competing with maybe Cloud Code, or Cursor, and a Terminal. What do you think is the placement of this product, et cetera, et cetera?

—Yeah. So basically over the past year, like everyone, we're all trying to figure out how are we going to incorporate LLMs into our workflow. I am a big advocate of the Terminal. I literally have a company called Terminal. I do all my code editing in NeoVim. I quite like that experience. LLMs are not at the point where I never have to edit code anymore. I still have to edit code quite a bit. There's some tasks that I literally have to do completely manually. So I was trying to find, OK, how do I use LLMs in a way that works nicely? So the dumbest way, obviously, is just to go open up your browser, ask questions, copy-paste code back and forth. That's like, while we're doing that for a while, stuff got more integrated. The most popular one, obviously, Cursor. I don't want to use Cursor because I'm not trying to switch my main editor. Editing is still very important to me. I want to have a powerful editor. I like mine. Also, I've discovered that there's two different workflows. There's the very active autocomplete type workflow, which Cursor is phenomenal at. We have something similar called SuperMaven in the NeoVim world. That's one category of thing. But there's a newer category where you're able to kick off a task to the LLM and have it work in parallel while you're doing a different portion of the task, and then combine. That's a very interesting workflow that I find a lot of success in. It's been pretty shocking how good it is. It doesn't need to live inside your editor. It can live near your editor.

We tried out Cloud Code. We were pretty impressed by how capable the LLM was. We were like, we should have built this. How do we not see this? This is a great way to package this product. You don't have to switch editors. You don't have to do anything. It just works. But we didn't like the actual experience. It's not built by people that love the terminal as much as we do. That's the idea with OpenCode. We're trying to build the exact tool that people understand the terminal, understand its capabilities, understand how the workflow is would build. Also, we're trying to make it completely agnostic to any LLM provider. Because this is such a competitive space, Cloud is doing great right now. Gemini just launched their CLI today, which means their models and the prompts are updated to really be good at this tool calling stuff. If Gemini ends up being really good and you're stuck on Cloud Code, it's an annoying process. The idea with OpenCode is let's do one really good CLI experience that works with any provider. The only way to make that work is to make it intentionally open source, so that people that really love a certain provider can build optimized prompts for it, optimized tools for it. People are using local LLMs. We're seeing all kinds of crazy experimentation. That's roughly the pitch. If you like the Cloud Code type thing, this is our attempt at doing a version of that product.

—Yeah, I was actually pretty shocked. I used to use the terminal and Vim back in the day, like 15 years ago, but then I joined the company. No, I actually stopped using that in 2020, I think, when I joined Robinhood, I think. Then everyone was using VS Code, and it had so many configurations to the company. It was like, that's it. I have to let go of this terminal workflow. Then I installed OpenCode yesterday, and it's like, hey, you can do models inside the terminal, and you have these pop-ups. It's like, holy crap, I didn't know you could do this. This was new to me.

—Yeah. We knew it would land well, because most people aren't aware of that, understandably, because why would anyone be aware of that stuff? We're really excited to have people open it and be like, what the heck is this? I've never seen anything like this. But yeah, you can do quite a bit. You're not really limited too much. I actually like the constraints. They're simple constraints. You can't change font sizes. It's all one font. You can only change color or boldness. You have to be a lot more intentional about your UIs. It's also kind of nicer, because you're not fewer degrees of freedom, right? I like just playing in that little sandbox of constraints. I think it leads to pretty good results.

---

LLMs, AI, and the Future of Software Engineering

One of the recurring themes I have on my community, and also a bit on this podcast, is how are LLMs and AI in general impacting either workflows, lists, or jobs? I don't believe in the doom scenario, right? There are a lot of jobs out there. But I do care about how we are supposed to put it in our workflows, right? So I'm going to tell you what I do, how I've used it. I'm going to share that. And I'm going to tell you some observations I have. Because even though I'm not coding anymore professionally, because I now run a business, I do sales, do lots of stuff, I do stupid things, right? So for example, I wanted to build a CMS. And I went to Drive, Google Drive. And it's like, oh, how do I navigate this API? And it's like, screw it. Just go to LLM, build me a prototype, paste it, 80% there. Then it breaks, unfix it, I don't care. That worked a lot. But then I had a bug two weeks later. It's like, hey, I don't actually understand this code at all. It's like, I have to read down what the hell is going on and debugging it. And I was really concerned about that change of flow, right? Because now, I think LLM gives me good code, very good default code. But it's code I don't understand. And that's a little scary to me.

And the second thing, my second observation is that I do lots of technical interviewing. So I represent companies and companies still have, most of them still have legal style or just practical programming challenges. But there are live coding exercises, right? And you can't really use LLM on those because many times it one-shots the entire challenge. So you tell them, hey, how would you code it? And people go into a complete blank. There's a good percentage of people that forgot how to write code. So what's your take on including LLMs in the workflow? What do you think is happening? What do you think is going to happen?

—Yeah, I mean, just like everyone else, I'm trying to figure it out. And I feel differently every week, depending on what my experience was the previous week. So I think where I've landed is, and I can only speak as someone that has, I'm going into this with 15-ish years of experience professionally. So my experience of it is quite different than someone that's new. But as someone that's experienced, I think, I love the auto-complete stuff. I think that's like a no-brainer. It's effectively, I like know the code I want written in my head and it's just jumping ahead and printing that out. I think that should be very controversial.

In terms of LLM writing large chunks of code, I have taken the approach that I do not use it for zero-to-one projects. It's fine for throwaway stuff. Like with Terminal, we make a bunch of joke stuff all the time. That's awesome because we made a balls.yoga website for Prime. It's like a fake website where it looks like it's selling yoga balls. I don't want to spend time building that. That's the perfect thing for LLM to just shit out. We'll do it. It'll be funny for a couple of weeks. And it's done on arrival. It's done after the joke. It's actually really awesome to make these fun little projects.

But if anything's serious, if you look at OpenCode, we've been cranking crazy for the last month on it. Almost none of it is generated by an LLM because of a few things. You would never have a new project and be like, hey, junior developer, establish the whole architecture, patterns, everything for this project. You would have someone more senior do that. And once it's in a good place, then it's ready to be iterated on by people that are more junior because they're working within established patterns or working within guardrails, basically. So that's how I tend to use it. I will still do my normal programming job for getting it to a certain place. And once I feel like, oh, now we're in iterating mode, we're just implementing features here and there, we'll issue that to OpenCode and have it implement features. Anything where I feel like, OK, this is a feature that doesn't look like something we already have, I need to do it manually. One, to make sure the implementation comes out right. But two, implementing it is the process of me figuring out what to do. So that's obviously still very important.

Again, building OpenCode zero to one, it was us figuring out what is the architecture we want, what kind of patterns do we have, what type of scenarios are common. It just can't do any of that. And I don't really believe it will for a long time or ever. I had this funny thought yesterday where, like you said, there's so much moping about, oh, our job's coming to an end. Is this going to ruin everything? Is the economy going to crash? There's another funnier perspective, I think. For years, software engineering has been just such an easy job in a lot of ways. You get to sit at your desk and just type stuff. And you can do it from home. You don't have to put on pants. And you get paid. That's like, wow, what an amazing job in all the jobs that exist. Wait, and then now you're telling me we can just have the LLM do work for us? All the boring stuff? We can just sit there and watch YouTube while it does the work? It's going to get even nicer. Do we deserve that? I think that actually, an optimistic view is that's where it ends up. Practically, for me, programming has gotten a lot more enjoyable. I'm spending a lot more time on the parts that are fun and challenging and a lot less time on boilerplate.

Oh, you know what I absolutely love? I was designing the output of a CLI command yesterday. I was like, I have three different ideas for how this can work. In the past, I would spend a lot of time thinking about the three ideas and just try to bet on one. Yesterday, I just had to implement all three ideas. I saw it in person and was like, okay, definitely, I want to go with this one. I was a lot more confident. That is so fun. Being able to try all your ideas and not have to compromise. For me, programming has just gotten so, so, so, so, so, so much fun. It was already too good of a job and now it's way, way, way better.

Again, for junior engineers starting from zero, I do not know what the heck this stuff feels like. It seems impossible. How are you supposed to do anything? How are you supposed to know when to use it? What meta skills are you going to develop? People keep telling you you're losing this meta skill, but people are often wrong. They think a skill matters and it ends up not mattering a year from now. That part of the world, yeah, I have no clue. It seems like complete chaos.

—I remember a tweet you once wrote, which was something like, I don't know how junior people or younger people can handle all the distractions without the experience. Something like that you wrote. That's one. The other one I remember reading was that you were considering that with LLMs, some core assumptions or important assumptions about what you thought was a good practice maybe changed. How do you change the code base now that you know an LLM can read it and solve kind of issues? Maybe sometimes you had a pattern that was very... I talk about this because some clients have code reviewing sessions. It's very interesting to have a code review session because you dump code into an LLM and it tells you pretty good ideas. It's pretty good about this. It's not that important to know this stuff right now because now it's much easier to fix. But then if people are not reading it, the LLM is reading it. Who are we writing this code for? I don't know what you were thinking about when you had that assumption.

—I think I would say broadly here's roughly how things have played out. Pretty much across all my code bases and probably most people's, there's a bunch of stuff that's not exactly perfectly clean or older patterns that we never fully cleaned up because I'm working with pretty competent people and they can compensate for that. They're like, okay, I get that things are a little messy here. I know I can ignore that because this is a better pattern I'm going to follow. I work with pretty good people so we can get away with not having as many tests, not having as much structure, not having as much consistency. We trade that off for being able to work a lot faster. The moment I started using LLMs more specifically with OpenCode, all of a sudden, all these low priority items shot to the top of my list because the LLM was getting tripped up on that because it's dumb. It doesn't know that these things are... It's getting confused like, oh, we used to do dialogues in this way and now we do it in this way. It doesn't understand that. We had to go and clean up a bunch of old stuff to really get performance out of it. The annoying thing is all the annoying patterns you can get away with when you have a fully senior team are now stuff you have to implement because you now have an idiot on your team basically. It's worth having them on a team because they don't cost much and they don't sleep and they can run in 1000x parallel and they have perfect memory. But now you're like, okay, we do need more tests because that helps the LLM. We can get away without great type safety before, but type safety really helps the LLM. All these old annoying practices that felt unnecessary, even some of the more enterprise-y practices like domain-driven design, going heavier into some of those things, the LLM really likes. That's how some of my code bases have changed. This is maybe the part where I'm like, fine, I'm not super excited about it, but it is logically worth it.

—Very interesting. Technical debt now hurts your LLM productivity.

—I think it's a perfect mirror. I actually don't think this is anything new. If you are a really great engineer, that means you can create code bases that junior engineers can be really effective in. The teams that have been doing that well are naturally excited for LLMs. The teams that don't do a good job at that, where it's like, well, for every change you have to ask this one guy because he's the one guy that knows exactly how everything works, those teams are going to suffer more. So if you're used to building stuff for other developers and creating good experiences for other developers, that's all the same stuff that you would do for an LLM.

—So now you have a very small team. What do you think happens when you have a massive team, like Google? Google has infinite resources to throw these code bases. They have very strict guidelines on how to put code. Is it very beneficial for them? Have you talked to Google engineers about how they use it or something else? Do they have people that actually go and say, hey, these code bases, we need to fix all this random crap because of the LLM. How is it affecting a big organization?

—I would guess that they are pretty well set up. They're so optimized around, we got to make sure we can hire thousands of people that aren't the best people in the world and still get good outcomes, to the point where they create languages like Go, the design goals of Go are entirely around that. So I imagine that slotting LLMs in has worked really well because I bet they have almost no code that doesn't have a test behind it. I bet they have very strict patterns on where code goes. I'm sure they have technical debt and sloppiness as well, but all the bureaucracy and pain that exists in these big companies that make them sucky to work at because you can't move as quickly are probably good for this LLM world. But I will say, again, this is just a portion of the work. New products, new ideas, an LLM is not going to help you too much there.

—Yeah. You mentioned this idea that software engineers are a privileged job and now it became even easier to do. Isn't that unfair? And I'm like, okay, it might make sense, but big corporate software engineering, having this boom, that one hurts me. That one's not supposed to, they're supposed to suffer. That's the whole point. As you were saying, that's way too good of a job now. They were doing five hours of work a week and now they're doing one hour of work a week.

—Yeah, no, incredible. Incredible. That's true to have there. Yeah. Because it's this thing, I was joking about this yesterday. I'm like, there's a shot trying to happen where they're trying to take out engineers, take out the need for programmers. If you miss, this is the worst outcome because now all the programmers are like, fuck you. You guys tried to take us out. We're still necessary. Look how important we are. Also, our jobs are easier than ever and you can't get rid of us. We're just all going to be so insufferable. From now on, I'm going to work half as much and get paid twice as much just because you made that comment.

—Yeah, exactly. I think that's a potential outcome of all this.

—I also do think maybe this is like a last opinion or observation. I had a whole podcast episode about AI and lots of people come to me with the AI anxiety about what is the impact on the industry, et cetera, et cetera. I said, okay, so let's look at open source. When I joined the industry, I'm 40 years old. I've seen before GitHub existed. GitHub started showing up and it was the whole thing. Open source code is developers working for free taking our jobs. It's like, I'm supposed to get paid to build this logging system from scratch. It was actually a topic of conversation. Is open source reducing the value or the wages of several engineers or not. If you think about it from first principles, you will say yes, because people are giving for free something you will need to get paid for. But empirical observation is the exact opposite. Now, I do six months of work in installing an NPM package, and that's it. It's done. It's actually getting people more money, not less money. Salaries are up. Engineers are up. Open source code is up. Everything is going up. I think it will make sense that if AI actually does make people more productive, which it has to in some degree, I don't know how much, but it has to in some degree, then salaries will still go up and the demand will still go up because there's an infinite amount of things to do.

—Yep, exactly. That list is infinite. I mean, even outside this stuff, people make this mistake all the time. They work on things that are not that important at their job because they don't realize there's an infinite list of more important things. There's always more stuff to do. There's always new stuff to do. There's always new problems. There's always scaling up what you're already doing. Yeah, so I think some of the stuff is counterintuitive. I think the way I would try to make it intuitive is if you have a factory and you're outputting X products a month and your cost goes down, are you just going to keep producing X products a month and pocket the difference or are you going to double your input and produce twice as much and sell twice as more? So as long as the demand is there and as long as you can find ways to monetize stuff, you end up investing more in more employees, more whatever. It's always scary in these shifts, but yeah, the open source one is a really great example. I totally forgot that was a thing, but yeah, it is very similar to the conversation that's happening now.

—Yeah, I think there's other dynamics going on right now where there's other economic issues and it's getting intertwined with the AI thing. A lot of companies are like, we're letting people off because of AI. It's like, that's not really what's happening. If your company was doing great and AI was making your cost go down, you would be hiring like a madman. We've seen that to a negative degree where people hire way too much when times are good. So the explanation is probably not it.

---

Closing

Yeah, so I think this is a good moment to wrap up the interview. I think we hit our like an hour and 15 minutes mark. It's been great to have you here. I hope you really enjoyed the conversation. I definitely learned a few things and thank you for being here.

—Yeah, of course. It was fun. Appreciate you having me.