From GitLab to Kilo Code (Interview)

Welcome to the change log, where we have deep technical conversations with the hackers, leaders, and innovators of the software world. I'm Jared Santo. On this episode, Adam and I are joined by Sid Sabranage, founder of GitLab, who led the all in one coding platform all the way to IPO. In late twenty twenty two, Sid discovered that he had bone cancer. That started a journey he's been on ever since, a journey that he shares with us in detail. Along the way, Sid continued founding companies, including kilo code, an all in one agentic engineering platform, which he also tells us all about. But first, a big thank you to our partners at fly.io, the platform for devs who just want to ship. Build fast, run any code fearlessly at fly.io. Okay. Sid Zibbrandage back on the changelog. Let's do it. Well, friends, I'm here again with a good friend of mine, Kyle Golbraith, cofounder and CEO of depot .dev. Slow builds suck. Depot knows it. Kyle, tell me, how do you go about making builds faster? What's the secret? When it comes to optimizing build times to drive build times to zero, you really have to take a step back and think about the core components that make up a build. You have your CPUs, you have your networks, you have your disks. All of that comes into play when you're talking about reducing build time. And so some of the things that we do at Deepholm, we're always running on the latest generation for ARM CPUs and AMD CPUs from Amazon. Those in general are anywhere between 3040% faster than GitHub's own hosted runners. And then we do a lot of cache tricks, both for way back in the early days when we first started Depot. We focused on container image builds. But now we're doing the same types of cache tricks inside of GitHub Actions where we essentially multiplex uploads and downloads of GitHub Actions cache inside of our runners so that we're going directly to blob storage with as high of throughput as humanly possible. We do other things inside of a GitHub Actions runner, like we quarter off portions of memory to act as disk so that any kind of integration tests that you're doing inside of CI that's doing a lot of operations to disk, think like you're testing database migrations in CI. By using RAM disks instead inside of the runner, it's not going to a physical drive. It's going to memory, and that's orders of magnitude faster. The other part of build performance is the stuff that's not the tech side of it. It's the observability side of it, is you can't actually make a build faster if you don't know where it should be faster. And we look for patterns and commonalities across customers, and that's what drives our product road map. This is the next thing we'll start optimizing for. Okay. So when you build with Depot, you're …