80. Dax Raad: Devtools, LLMs y SST

So all these like old, annoying practices that felt unnecessary, the LM really, really, really likes because it's very easy to build something simple for like 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 like boilerplate.

Okay, so this is a very exciting episode of Technology Informal. This is going to be the first episode I do in English, actually. And, you know, I wanted to invite someone that, you know, has a lot of food in the technical community.

And, you know, I saw Dax on Twitter. I've been following him 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 sound bytes right now, especially post AI. And yeah, 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 in JavaScript. So if you hate Terraform, use SST, definitely that. And yeah, 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. And yeah, I spent 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. I think 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 kind of 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, because 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, of your guys' barbecue situation.

One, like it's so cheap from what I hear. And, and two, I've seen pictures of like the big enormous spreads. So definitely jealous of all of that.

Oh, yeah, it's, it's really, really cheap, but it doesn't have as many like infrastructure. Like, you don't get like huge bridges. It's like, it's a very common thing from Argentina.

Like, I like reading books, of course. And I read the Welcome Nations by Adam Smith. He actually has a section talking about Argentinian beef.

Oh, really? Like imagine 200 years ago, the guy is talking about the American Revolution, and why beef is so cheap in Buenos Aires. It's been a thing forever. Yeah.

Yeah. But it's like, yeah, we have so much land and it's just like the cost of going and getting the cow. That's his thesis.

It's like, it's so cheap to raise cattle here. So that's why it's so cheap. Yeah.

Yeah. That's awesome. Let's, let's go to the main course then.

I like that on your introduction, you talked a lot, you, you, you mentioned very quickly that you're a founder, that you're an entrepreneur, independent. I like, what's your, like your path to this decision? Were you, did you always want to be like a, like a, like a founder or did you, you know, 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. So my, my history is I started working out of high school. My dad's a software engineer that like, wasn't that crazy for me to like, start doing that stuff from a young age and like, get into it professionally.

Um, about like six months into that, I ended up starting a company, uh, with a friend and this was like in 2012, I would want to say, um, this was kind of when, at least for me, I was like learning about the concept of a startup or the concept of a tech company. And, and I lived in New York at the time. And, uh, there was like a lot of that stuff popping up there.

So it was very exciting time, uh, was very attracted to the idea of founding a company and selling it. That seemed like such a crazy dream, um, worked on that for about a year and a half. We did end up selling it.

Nothing crazy. It was like an, uh, an aqua hire, uh, to another company and I'm leading engineering there for about two to three years, uh, 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. Like if you learn the right tools and you're effective with them, you can be multiples better than like the average person.

Uh, but a normal job doesn't really compensate you in that way. Like you'll maybe earn 20% more than the worst person on your team, but you're not going to earn like twice as much. Um, my dad spent a bunch of time as a consultant.

So I was like, yeah, I'll just, I'll just be a consultant. So I spent a bunch of time, uh, working for a bunch of different, uh, companies, mostly startups. Uh, that was kind of like a break for me to try to like understand everything that's going on around there.

Ended up founding another company. Uh, this one did better than the last one and it was going really well, but then ended up going not so well and actually ended up being fired from that company. Um, but it's where I met my wife.

So I did get some kind of nice exit. Uh, so we both, was it the product company or a consulting company? No, this was a, was a product company. We were building, um, software for, it was like in the healthcare and transportation space, just trying to solve some problems that existed there.

Um, the product itself worked really well. It's just cloud situation where I focus a little bit too much on engineering and kind of offloaded growing the company to the CEO. And he was very young, like much less experienced than I was.

And just, he just made a bunch of critical mistakes that created like a massive split in the company toxic over time and kind of eroded everything that was working. Um, so I, I actually, I mean, I knew I was going to get fired cause at some point I was just like refusing to work and was buying time for my engineering team to find new jobs. That was kind of like a disaster at the end.

Um, again, went back to consulting, uh, somehow ended up as director of engineering at a company that was growing pretty quickly. Um, my first role as like a middle manager anywhere, interesting experience. Ultimately I just knew I wanted to continue to founding again, uh, 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 like really learn the cloud and see how that, 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 like, okay. Um, obviously you can't build great tools at the beginning of your journey, learning something new, but I was trying anyway.

Um, ended up coming across a project called SST, which was just launched very early, barely anything, uh, started using it, started contributing to it. Uh, there's a company behind it. I ended up investing in the company.

Uh, they were raising around. And then a month later they were like, Oh, Hey, do you want to join the team? And then I was like, that's awesome. Yeah, that sounds great.

And they gave me my money back except now I owe taxes on it. So it was don't invest and then join a company and go, go the other direction or just figure that out at a time. Um, and then I've been there since then.

So it's just been the three of us for the past five years or so. Yeah. So when did you become like part of the founding team of SST? Uh, this was in 2021, I think.

So it's been four years. Yeah. So they were right at the end of doing YC when I, when I joined the team.

Yeah. So there was kind of getting out of it and they, they, they like started the company prior to that too. They're actually working on something else through going through YC.

Um, and YC is very good at this, uh, got them to work on a bigger idea that seemed more implausible. Um, kind of one of the best reasons to do YC, they'll kind of push you to do things that you don't believe you can. Uh, and that's kind of when I, when I joined them, I didn't go through YC personally.

No. Okay. I like this idea that YC pushes you to aim higher or bigger.

What was the switch? Like if it was already a tooling for, for a vendor agnostic, like infrastructure. No, SST didn't even exist at all at that point. So prior to then the, there was an existing framework called serverless framework, uh, which was kind of popular back then.

It was, it was pretty popular back then. Um, and they built a really good CI tooling around it. So if you were a serverless framework user, this is like a really great option for you to ship stuff to production.

And it was a great product and it was making money. They actually even hit, they even got to break even. Um, but 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.

You're got your company's debt is downstream of that. Like it doesn't really make sense as something you bet 10 years on. Um, so I think YC helped them understand that.

Uh, and they were like, you need to go do your own framework, like try to be bigger than serverless framework and try to like fully control like your full destiny there. And how, how do you view like the market positioning of a tool like SST versus using Pulumi directly or using Terraform? Like I'm using SST at Silver Dev right now. Like I'm, 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.

It was just like just random files. But I want to understand how, what do you think is the vision of like SST in an environment where there are so many other infrastructures? Yeah. So we, we did not invent infrastructure as code at all.

So this has been around for quite a bit of time before us, I would say. So infrastructure as code is a great idea. And I think every software team should be using it to some degree, whether it's SST or Terraform or whatever.

Uh, but just generally a good idea. It mostly found success within the DevOps part of the world, like people that were responsible for managing infrastructure. And if you look at tools like Terraform, they're really oriented around that, right? It's like more config oriented and like not tied to a specific language.

Um, and 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. So if you think about someone, we try to build tools for ourselves.

We've always built, uh, 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.

And also as time went on to be a good software engineer building product, you did need to understand infrastructure because like, these are things that you can take advantage to solve problems. So as like those two roles kind of started merging, um, that's kind of where ST 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, uh, 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 higher level components, right? Like we have components for Next.js, for CanStack, for SvelteKit.

Like these are things that software products, software engineers are thinking about. Um, so our whole, the way we're all, we're designed is on day one, you can use SST without knowing much infrastructure because it's, it's very high level, but we take quite a bit of care not to like provide like brittle abstractions because on day 100, on day 1000, you're going to need to, you're going to want to dig in to the infrastructure deeper and configure some of these underlying, uh, like levers that you have. Um, so ST is built in a way to progressively disclose all the way down to that.

So you start on day one, not knowing much, and most of our users become pretty good at infrastructure, you know, as time goes on. Uh, the idea here is companies start out the same, but as they get more mature, they all need like weird, different configuration. Like they, they sort of do things that are more complex and sort of do things that are more unique and like that, like perfect little, like simple platform that you can build for them on day one just doesn't work as they grow out of it.

So that's kind of how we're designed. Who would be the, like 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, we know of teams of like hundreds of engineers that are, uh, entirely building with SST. Uh, we've had a funny history where most dev tools start like, you know, like indie devs like them.

And then you try to grow to a point where like 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 like the big companies first, like we had like Comcast using us.

We had AWS themselves using us. Um, we had like a lot of these big initial customers, but our experience wasn't very good for like the individual. So our journey was like taking this like enterprising tooling and bringing it down to like the average person.

Um, I actually, 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 up market, which is very difficult because it's very easy to build something simple for like the average person that just does not work for a team of 10 or 50 or a hundred. So, um, we went the other direction, which I think was painful at first, but long-term works out better. But do you get, do you get people that use Terraform to say, Hey, from now on the next infrastructure, we are going to build it with SSD.

Do people migrate? Yeah. So yeah. So the tricky part is at companies that have DevOps teams, they're not going to want to switch to SSD.

Like they one probably don't even like TypeScript. Like it just seems random for them to use that. And they probably have like years of Terraform that they've written.

Um, the format we've seen though is, uh, 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, spell kit needs these exact cash headers in our, in our CDN. Like 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 VPC subnets, like 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 their, maybe even their own databases, um, using SSD. So it tends to be a little bit side by side. Okay.

So what I will say as a, as a compliment is that it definitely worked for us. Like we have a single software engineer and an intern right now, and he chose SSD and he was like, okay, now I understand all these parts of the infrastructure. We have like, we have this weird requirement where we need to sync with another database somewhere else and, you know, bring the data and sync it with our ATS and stuff.

And then he built it, everything on SSD and I can read it because I can read TypeScript easily. And, you know, so it's good. So it's definitely working there.

Um, I want to talk, you know, I want to share my perspective on the industry of DevTooling and open source, and I'd like to know what you think about it or what, what's your take on working on this industry. So, you know, 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 DevTooling and, and, you know, DevTooling is a very particular space and that, you know, across time, you've got thousands of people, like, I don't know, putting a lot of effort into tooling.

They make no money off, right? Like they make jQuery plugins and like stuff like that. And then, you know, uh, you have all the issue on how to monetize that, right? Like it's monetizing that, that code is really hard, but I've seen like the one big thing that really works is when you have like a, like a tooling that becomes, uh, that has reverse churn, right? Like when the company, you know, starts with SSE like us, SilverDev 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, right? Just, I, I truly believe, part of me truly believes that a great part of Jeff Bezos' fortune is like developers being very negligent with our infrastructure, right? And, you know, I, 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, right? When corporate buys like millions of computers.

And the same happens with AI, right? Like everything that's happening with AI right now, even, even the applications like Cursor and stuff like that, they work because they are easy. And then, you know, 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 locking, and then you make money when it blows up. Yeah.

So this is a, that's pretty accurate. And I actually think this is why most dev tool 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 dev tools 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 don't outgrow it. And this is like such a crazy set of things to try to get right. Which is why most dev tool 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 like a wide percentage of the market. And then you need to build a complimentary product that is also like really good and like 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 like do the other thing. And even like big successes like Terraform. Their situation is funny because they have like Terraform was so successful that their complimentary product, the bar was pretty low on like, anything they built would have like made a decent amount of money.

But they did, they didn't do a good enough job where there's like two other companies building similar products to like Terraform cloud that are also very successful. So it's like so hard to like be the winner in both. So like, yeah, it's like a very, very difficult space.

And I think the B2C aspect of it is funny to me, because I think developers are attracted to dev tools, 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, like, you should know how to use this, you should be smart enough to like configure this, or you should be, you know, that's the mindset developers tend to have.

But it just doesn't work for something that needs to be like the scale, you need to like have a successful dev tools product. Like it's, it's, it's no different than launching, like a competitor or something. It's pretty similar getting to their day to day.

So they actually are very picky and low for low tolerance, low tolerance for BF. Yeah. And even just get them to understand like 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 like try to use your thing again. So yeah, it's very hard. And I don't really recommend people build dev tools.

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. True of every single space, probably.

I have two questions here. Well, like one of them is like, what do you, what companies do you think are doing a good job in understanding and executing this, in saying like, hey, I first need to charm my developers, and then I'll build a product that will work for them, right? And inside this question, I'll put my one company that gives me a strong impression, which is BUNN, right? Like, as a developer, I look at BUNN, and it's like the value proposition as a developer is like so obvious. It's like, it's going to be faster or a bunch of things.

And then I say like, how am I going to pay you? Like, I want to play you something, and I don't know how to. I was like, it doesn't connect. Yeah.

Yeah, it's funny you say BUNN, because that's actually my answer too. I actually think Jared is the best dev tools founder right now. So I think he has a very unique, pretty like incomparable crossover where he's obviously deeply technical, but he comes from building mass market, like social app.

It's not his first time being a founder. He's like launched things before. And he's launched things that have gotten like, you know, millions of users and have gone viral.

So he looks at things from that perspective, and almost no dev tool users or dev tool founders like think that way. They're very more like B2B slow growth mindset. Whereas Jared is like, anything that makes this incrementally more viral, like I'm going to do and it's our job to do.

And if you look at the trajectory of BUNN, it's so funny, like my personal trajectory of using it, they were like, Jared was like, okay, I'm gonna make BUNN a good package manager. And I was like, okay, that sounds like a good idea, but I'm not sure. And I sort of was like, okay, I guess I'll use it.

It's like pretty good. It's pretty fast. Then I'm like, okay, I have these like scripts I need to run every once in a while.

All right, I'll use BUNN for that too, because it works for that. Okay, like, now I have this internal like Docker container I need to run. It's TypeScript.

I don't feel like figuring out a build process. I'm just gonna use BUNN for that. It's not a big deal.

It's internal, right? So it just kept sneaking in. And this is like brilliant execution from BUNN where I was like skeptical of using it in like a tiny place. And before I know it, it's like taking over my whole workflow.

It's a point now where open code is literally like a BUNN single file executable. So that's like 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 like 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? 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, you know, like a bunch of people were using, not the whole world, but like, you know, early adopter, they captured like, you know, two or 3% of the world, super hyped. Everyone's like, this is awesome.

Google's amazing. How are they gonna make money? What is every single person gonna say? They're gonna say, give everyone 50 searches for free and charge them 20 bucks a month for Google, right? That would have been everyone's go to monetization plan 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 like 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 goals is kind of doesn't matter.

Because if you fail that goal, there's no point on monetization. There's like nothing really to do here. If you become default for JavaScript, I think we'll start to see business models that like 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? Still, that's still a big question, right? Like, 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. 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. OK. I have two observations.

One of them is that I agree. I had the same experience with bun. When they announced it, it's 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. OK. 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 might say, hey, I'm going to do a corporate services somehow that I'm going to make your CI in JavaScript cost one-fourth because this is way more efficient. There's some value there somehow.

But maybe when you do that, people say, hey, 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? 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 a month.

And I'm saying, no, start with $1,000 a month and then see what people ask you for that and then go from there. If you have no 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, 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 a bun. It makes no sense.

That's never going to be the viable path. Their second product, which is the one they actually decide to take a swing on, this 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. 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? That was an open source product and then they monetized it with their infrastructure. I've seen your spats with Rouch 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, okay, let's go real. 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 ignore them being like, please help me deploy my Next.js app. It's so hard. I don't know how to get this working.

There's so many features and whatever. Eventually, we begrudgingly put together a package that helps deploy Next.js efficiently on AWS. And that involved us reverse engineering a bunch of stuff, figuring out where the gaps are, figuring out where the bugs are.

And there's a crazy long tail of problems. Whenever I talk about this, there's always some guy that replies being like, you guys are all dumb. I just deployed, I'd have five Next.js apps running on a server.

Yeah, it's easy for a simple case. But if you're thinking about 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.

And 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. We just weirdly became experts on how it worked under the hood.

But like, we're not users. So there's 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 step 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 works directly with the maintainers.

And 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% not necessary. 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 a 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 trying 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 it was never like a malicious, I want to force you to use my thing type of thing. Yeah. 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 gonna... 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 SaaS products. I think it's very optimized for really optimized for where a lot of our sales 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 are very different to like like a productivity tool you're selling to businesses to do their work.

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. I don't, I don't, I just don't, it 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, you would use like a different architecture, architecture for power users, do you mean like an SPA? And what, what do you use as a framework? 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 was, it actually, I'm a front-end engineer. So I'll tell you a little bit about my story with NetJS. And I want to talk about the sync engines thing.

So I, I, you know, 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 Power, you had Webpack, like you wanted to build a page and it took you hours of configurations of like very weird models.

And then NetJS showed up and it's like, okay, your default works. And it was like, that was magical. That cut down like hours and hours of configuration that was really painful also.

And I remember, and so I did all the migrations from NetJS one to 15. I did all of them across multiple companies. So I mean, I know the history, right? And it's like, yeah, we have this new concept, get initial props, and then you do it this way.

And then it's like, Hey, but how do you do authentication with this? All of that, that's unsolved yet. It's like, 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? I get it. 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 kill someone else because we could leave. And then I had to face this issue. Okay.

Time to host NetJS 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 NetJS 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. It's like, 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, let's say, into infrastructure. You should buy that whole story, right? Like if you are buying into NetJS, you should be buying into Verso, because that's when you're going to get the full capabilities of it.

I think people run into trouble when they like try 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 NetJS 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 Verso.

Every single conversation I've had, when someone comes to me being like, hey, we're thinking of moving off of Verso, 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 NetJS, I'm not just telling them just go use Verso.

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, it's interesting.

And like, it's, that's roughly similar to like, we see this everywhere, right? Like, 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 times you need flexibility, or we don't fit perfectly into their bubble. It's like a nightmare. This 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. So I want to pull the thread on the sync engine. So my experience was that in 2021, I looked at linear.

Yeah, exactly. I had my first experience looking linear. It was like, what the hell is this? I was shocked.

It was like, how did they build these things? Right? Literally, I got that experience. And then I look at it a few years later and I say, okay, 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, you know, that kind of like an idea I have. Well, 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, it's 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 style 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 them, 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 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 zero. And this is what I'm using across the board for, 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 as someone, I'm not coding every day anymore. Like, that's my reality. But I can make a decision.

I can say, Hey, I can tell my developer, just do everything on sync engine now, go for it. And is it like, is it like, like sending him to kill windmills? Like, is it crazy? Does the cloud particularly 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 a 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 a product like a PM forever, not a programmer. The past year, she's been actively working on our product, like programming it, I mean, to 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 to 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. You are 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 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. Zero gives you really good tooling to do that easily.

It wasn't the case with replicash, it was a lot more manual then. But these are like prior 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 the for a week.

And after a week, he gets evicted. So if you open it up, again, there's a little bit of a loading delay. Some of the permission stuff for is a little bit different.

So there's new problems that show up, of course, but man doesn't 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 like, 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 like, now that's where my bottleneck is to like 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 know, you will 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. And 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 cash or something else. Like with sync engines, when do you do, when do you pull the information, all the information together? Yeah.

So, so like the dumbest approach is you pull up front when they first load. So like, I'm just going to download everything I possibly need. Some apps that make 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 homepage and there's like some kind of query for data that, you know, is needed for the homepage, 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.

Yeah. So you recently relaunched, launched OpenCode. So that, 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? Yeah. Like how does OpenCode fit into, into all of it? Yeah. So just, just to like list out everything.

So I primarily work on SST, which is a framework and SC 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 going to 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 SSD, which then sees... It's like an ecosystem that kind of feeds itself. Yeah.

Yeah. And is OpenCode part of SSD 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 SSD revenue. Yeah. I see.

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, right? You're competing with maybe Cloud Code or Courser and 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 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.

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.

And it doesn't need to live inside of your editor. It can live near your editor. So 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. So that's the idea with OpenCode.

We're trying to build the exact tool that people that really understand the terminal, understand its capabilities, understand how the workflow is, would build. And 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 like an annoying process. So the idea with OpenCode is let's do one really good CLI experience that works with any provider.

And 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.

So that's roughly the pitch. If you like the Cloud Code type thing, this is our attempt at doing a version of that product. GABRIEL KREIMAN I was actually pretty shocked.

I used to use a terminal and Vim back in the day, like 15 years ago. But then I joined the company. No, actually, I stopped using that in 2020, I think, when I joined Robinhood, I think.

And then everyone was using VS Code, and it had so many configurations. So the company was like, that's it. Let go.

Let go of this terminal workflow. And then I installed OpenCode yesterday. 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.

MARK MIRCHANDANI Yeah, yeah. So I mean, we knew it would land well, because most people aren't aware of that, understandably, because why would anyone be aware of that stuff? So 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. And 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. And it's also kind of nicer, because you're not like fewer degrees of freedom. So I like just playing in that little sandbox of constraints.

I think it leads to pretty good results. FRANCESC CAMPOY One of the recurrent themes I have on my community and also a bit on this podcast is, how is LLMs and AI in general impacting either our 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 and build me a prototype, paste it, 80% there.

Then it breaks, I'll fix 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 lead code 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 like 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 autocomplete 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.

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 a fake website where it looks like you're selling yoga balls.

I don't want to spend time building that. That's the perfect thing for an 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.

So it's actually really awesome to make these fun little projects. But for anything 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 where it's just implementing features here and there, we'll issue that to OpenCode and then 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 0 to 1, 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 is 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 doesn't 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.

And 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? So I was designing the output of a CLI command yesterday.

And 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.

And I saw it in person and was like, OK, definitely I want to go with this one. And I was a lot more confident. That is so fun.

Being able to try all your ideas and not have to compromise. So for me, programming has just gotten so, so, so, so, so, so much fun. And 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 ends up not mattering a year from now.

So 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. And 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. So 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? So I don't know what you were thinking about when you had that observation. So I think I would say broadly here is 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 like older patterns 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 I work with pretty good people.

So we can get away with not having as many tests, like not having as much structure, not having as much consistency. And 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.

Like it doesn't understand that. So 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.

And 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. Okay, we can get away without great type safety before but type safety really helps the LLM.

So 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, really, really likes. So that's how some of my codebases have changed. And 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. So technical debt now hurts your LLM productivity.

That would be the... Yeah. And I think it's a perfect mirror. I actually don't think this is anything new, right? If you are a really great engineer, that means you can create codebases 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 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 at these codebases.

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 codebases, we need to fix all this random crap because of the LLM. Yeah.

How is it affecting a big organization? So I would guess that they are pretty well set up. If you even just look at it, 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 that are 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. 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.

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 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, etc.

I said, 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 a whole thing. Open source code is developers working for free in our jobs. That's funny.

I'm supposed to get paid to build this logging system from scratch. It was actually a topic of conversations. Is open source reducing the value or the wages of software 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.

Empirical observation is the exact opposite. Now, I do six months of work installing an npm package and that's it. It's done and it's actually getting people more money, not less money.

Salaries are up, engineers are up, and 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.

Right. Yep, exactly. That list is infinite.

And I think people, it's really hard to, I mean, even outside this stuff, people make this mistake all the time. They're like, they like work on things that are not that important at their job because they don't realize there's like an infinite list of like more important things. There's always more stuff that there's always new stuff to do.

There's always new problems. There's always like 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 like, if you have a factory and you're outputting, you know, 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, like these things end up, you end up investing more in more employees, more whatever. So it's always scary in these shifts.

But yeah, the open source one's a really great example. I totally forgot that was a, 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 like there's other economic issues, and it's getting intertwined with AI thing. A lot of companies are like, we're letting people off because of AI. And it's like, that's not really what's happening.

Like, if your company was doing great, and AI was like, making your costs go down, you would be like hiring like a madman. Like, we've seen that to like a negative degree where people hire way too much when times are good. So it's like that explanation is probably not it.

Yeah. Yeah. So I think this is a good moment to wrap up the interview.

I think we we hit our like an hour and 15 minutes mark. It's been great to have you here. I hope really enjoy the conversation.

I definitely learned a few things. And thank you for being here. Yeah, of course.

It was fun. Appreciate you having me.