Never Do the Same Work Twice: Rethinking CI for the Agent Era with Dan Manges

0:07Good morning, good evening, WebYar, and welcome back to the Enterprise AI Show. This is your host, Aaron. And for today, our topic is continuous integration in the age of AI and AI coding agents. Brandon interviews Dan, who is the co-founder and CEO of RWX. And that is coming up right after this quick break.

0:33Today's show is sponsored by Palo Alto Networks. Every time your team deploys a new cloud workload or AI agent, another identity gets permanent access to your critical systems. Legacy tools were built to manage human employees, leaving modern machine and AI access largely unmanaged. That's why IDERA by Palo Alto Networks comes in. Human, machine, AI, one identity platform for all of them. IDERA replaces permanent permissions with dynamic access so you can lock down every identity without slowing down your business. Secure every identity with IDERA by Palo Alto Networks. Visit paloaltonetworks.com slash IDERA.

1:10Again, that's paloaltonetworks.com slash ID-I-R-A.

1:19Today's show is sponsored by Nord Security. Your employees are using AI every day, but do you know which tools they're using, what data they're sharing, or where their AI agents are connecting? you can't govern what you can't see. Introducing NordLayer AI Scout, the visibility layer for enterprise AI. AI Scout gives you visibility into AI activity across web and desktop apps, detects sensitive data exposure, helps control AI agent connections, and creates an audit trail for governance. So you can protect your data without blindly blocking innovation. See what your AI is doing, then decide what happens next.

1:53Connect with Nord Security to learn more about NordLayer AI Scout. visit nordlayer.com slash ai-scout slash enterpriseai and get started today

2:08and we're back joining me today is dan mangis co-founder and ceo of rwx welcome to the show dan thanks for having me brandon all right we're gonna have a fun conversation on continuous integration but you have an excellent fun background so i wanted to hear the origin story. What did you do before you started RWX? Yeah, my background is really the motivation for having started the company. I was previously the CTO of a couple of high-growth tech startups, Braintree in the payment space, which acquired Venmo and was then acquired by PayPal. And then a couple of years after that, I co-founded a car insurance carrier, Root, in 2015.

2:50we launched the product in 2016 and went public at an IPO in 2020. So through both those experiences grew remarkably fast and I spent a lot of time as CTO focusing on maintaining a really high engineering velocity even as we were scaling. And obviously for folks listening who have built things at scale probably get that there's some diminishing returns on productivity just as you have more people your company is maturing your code base is larger you have more users it could could be impacted by your changes. But I also felt like there were some technical tools that didn't scale as well with our code base as I would have hoped.

3:25And as I looked into this problem space, I realized big companies like Google, they had this internal build system Blaze, inspired open source Bazel, built around all these amazing techniques, but it was exceptionally difficult to adopt. There wasn't really something that made those techniques available to the everyday engineering org. And that was a large part of the motivation for wanting to co-found and build RWX. All right. I like it. It's always good when you've felt the pain, I guess, in your case, several times over and also felt the pain in what sound like pretty regulated financial institutions, of course, and insurance and stuff like that.

3:56So why don't you take us inside that? You're at these large companies and you're, I guess, successful companies and are doing very well. But like when you say dive into that a little bit, it's like, what was the pain that you were seeing? Is it just long times to get the deployments out? Is it just frustrated developers? What were you living every day to get you motivated to actually say, I'm going to actually to go solve this problem once and for all. Yeah, I think it's good that you called out that both of those experiences for me were in regulated industries where the reliability of our software was critically important.

4:26And I think this is one thing that sometimes gets lost in the discourse of software engineering is that I do think different types of products warrant different solutions, have different consequences of issues. And sometimes that isn't, I think, acknowledged enough as people are debating the right way to build and ship software and probably especially true now with AI. But as we were growing, one of the, I think, key things impacting an engineer's productivity is just the overall feedback loop. And as I looked into it, continuous integration was often a place where engineers were stuck waiting.

4:58There's that well-known ex-KCD around engineers slacking off the excuse that their code is compiling. And in the 2020s, it wasn't code compiling so much as a comprehensive automated test suite that is running. And I think for me as an engineer, I really hated waiting on things, especially things that just didn't even need to be running. And really had this observation that in a lot of these pipelines, like regardless of the change that an engineer made, there were all kinds of automated tests and checks to make sure that completely unrelated things didn't break. And that was something that just felt horribly inefficient to me.

5:35Yeah, I think you wrote it somewhere or I saw something on your website. and not to oversimplify any company, but I really liked it because I just crystallized what was going on. I said something like, if you can reduce the time it takes to basically go through the whole cycle to 15 minutes, I basically get four loops an hour, right? Versus if it takes an hour, then of course you get a lot. So it's like, in some ways, it's a very simple thing to say, but it's also like something I don't think people internalize. It's just like, how many loops in an hour can I give this engineer so that they can do more work?

6:03And also so they can stay in the zone, right? I know we're not playing sports here, but you know what I'm saying? You stay in that feeling of like you get going and you don't, because I think that's a big part. You walk away and then you let the build run and then you go do other things. So is there in your mind, going back to maybe your previous jobs, is there like a number? Like you say to yourself almost like, I just, I want to get people this many reps in an hour because I feel like this is what keeps them engaged. Is that like how you think about like the business problem at the highest level?

6:31Yeah, I do think there's a few thresholds there where how an engineer is going to work is going to change based on that feedback loop and just how inclined they are to go switch off to another task. And certainly if you can get that feedback loop under five minutes, it almost starts to get fast enough that by the time you've looked at the output of something, the automation is finished running and you can stay in that flow state on a task that you're focused on, where maybe even within 10 minutes, that's still achievable. And really, once you start crossing that threshold, you're going to be pretty inclined to multitask and go switch off to something else.

7:10And I find that does incur, I think, a lot more inefficiency than maybe some people realize. And especially now in an agentic world, it's easy to have so many agents like working in parallel. But I do think there's a real cost to that context switching as engineers are bouncing back and forth between different things just because they have to wait. And often what happens is you don't even come back to that task at the earliest moment you can. you're coming back to it later. So sometimes you have something critical that you're really trying to get done, but you're context switching because you want to try to feel productive.

7:39And now the consequence of that feedback loop being slower is even higher than it is just based on the sheer wait time because of the context switching. Yeah, I think this is a really interesting idea. It's like there probably is something about human beings around like you want to be doing something, but you would probably be better off just like staring at the screen for three minutes and just staying in there versus check the email, do a Slack message, whatever, work on something else, look at another agent. So I like that. That's probably a life lesson for all of us. Just wait, just wait for a few minutes.

8:08Don't distract yourself. So obviously there's been a ton of solutions in this space, right? We won't go through them all, but I think people know a lot of them and there's been lots of smart people, right? So what are you kind of looking at when you kind of look at this and after these successes, you can probably do anything, but like, what are you bringing to the table that's like new here that people either haven't done or haven't been willing to do since continuous integration has become so popular however many years ago? Certainly if there's a theme for my career, it has been working in mature, entrenched industries and trying to bring a new approach to it.

8:43Both of my past experiences, Braintree building payments technology, Root building a car insurance carrier. Car insurance wasn't a new thing. Online credit card processing wasn't a new thing, but there was a tremendous opportunity to really improve the way it was done. And I think I feel very similarly about continuous integration and building RWX. Obviously, a lot of very entrenched companies in this space. But interestingly to me, they'd all been built around a similar abstraction, which is really paralyzing automation and pipelines by spinning up large numbers of virtual machines that are running everything in parallel as fast as possible, but also just doing a tremendous amount of redundant work.

9:24oftentimes just running the exact same command on the exact same files as it's been previously executed or that is currently being executed like across that cluster and i think some of this is also a consequence of the shift that we made in the industry over the past decade towards using more ephemeral infrastructure because there's a lot of nice properties of that as opposed to using more persistent environments but there was also some consequences and trade-offs there And as I looked into this space, I realized that build tools like Bazel, tools like Nix had these really interesting ideas built in them, but there wasn't really something that took those same concepts and applied it to continuous integration really broadly and comprehensively.

10:08And in a way that worked really well, you know, across a wide variety of runtimes and frameworks and different tech stacks that organizations are using. And I was really excited to do that. I was really excited not just to build kind of yet another player in this space, but one that was built around an evolution of the core abstraction that's used for continuous integration. So is the end goal then really as simple as speed? You just want to get through the integration builds as quickly as possible? Is that your guiding light or is there something you talked about more of the abstraction? Is there something more you're trying to bring inside the industry?

10:42You want people to think differently about it than maybe they thought about it before. There's quite a bit of the latter there. certainly speed and cost, which cost is probably just another way to talk about the efficiency of it all, are table stakes. And that's a large part of what we do. A large part of what we do is make things run faster and make things run more efficiently. But I've also found that the overall developer experience and now how that ties into the agentic experience is, if anything, even more impactful. And those abstractions do create the opportunity to loop far faster, run more efficiently, but also work better with the way that software is built today with coding agents.

11:28And I'd be happy to elaborate on that. But I find you do have to clear those table stakes of speed and cost before you can get into the higher levels of actualization of developer tools and build pipelines. Yeah, so you mentioned agents, and I think that's probably a good way to set it up. So I would imagine, say, I'm just a large company, can be anybody, and I've been doing things the old way, right? And then agents come on the scene. And I'm guessing this is where you start to really start to see traditional tools break down. So what is the kind of the state of the industry as you see it? So everyone's adopting agents, I got my cloud code going.

12:04And why is that bubbling up this issue? What are they now seeing that maybe they were either not seeing before or they were willing to live with before?

12:38choosing. Get the news from the end of the world. Follow the clues. Unravel the mystery as civilization collapses. 2029, the war for our world. A science fiction news series from the future. Premiering October 30th. Follow wherever you get your podcasts.

12:58Yeah, I think that's a great intro to some of the changes that we've made in the approach that we've taken at RWX because there's still a lot of engineering teams that are in effect working the way that they're working before, but trying to get agents to do the things that people were doing. And I think some of the most effective engineering organizations are the ones that are rethinking the way they work completely from first principles. Some of this for us at RWX was very fortuitous because I think the approach that we were taking to improve continuous integration tooling for engineers also just positioned us to be far more agent native.

13:32And a great example of that, Brandon, is the fact that every other CI platform, as I talk about like the evolution, the abstraction of CI, is very version control centric. And it made sense. They built their platforms that probably if an engineer spent a few hours writing code and wanted to run the bill, it was a good time just to push it up to GitHub anyway. And you may as well just run continuous integration on that git push, and then you can tie in the status checks and everything. Now, we'd taken an approach at RWX where instead of being Git first, like we will run the way I just described, but also all of our workflows can be run from a CLI directly.

14:05And we had taken that approach to improve this experience for engineers because we always hated the experience of having to commit and push when you had no idea if the code is going to work just to test your changes because the only way to run anything was with a Git push. So we had built this approach where you can initiate runs from a CLI so you get this really great feedback loop. And obviously a CLI is almost like the de facto interface for coding agents. It's that and MCP servers. And the fact that everything you can do in RWX you can do from the CLI without having to commit and push at all means that feedback loop is much faster for agents.

14:38And we were talking about speed earlier. It's not even really just the sheer speed. It's also the accuracy, the token efficiency of that agent looping. It's not having to make a git push and then commit and then go find the jobs that are running and then go pull down the logs from that to see what went wrong. It's like a synchronous CLI loop where the agent runs RWX run, and then it gets an output of here are the tests that failed. So yes, it's faster, but it's also more accurate. It's more ergonomic. It's more token efficient. There's a lot of like second order benefits to that speed. So that's really interesting.

15:10I feel as you were talking there, I almost just feel like I type git commit push, like without even thinking. It's almost just like a, it's just, but the reason I guess I do that to some degree, and I bet you people listening is I don't necessarily know what's all going like i don't really know the continuous integration stuff that's happening i just know if i do this all this stuff happens and i don't say it's magic but it's just like i just don't have to worry about it and i think that's so i don't at least for me maybe other people like that's almost the i almost am like conjoining these two things it's almost oh yeah it puts the source code in there but really it's just like all these systems run and i get what i want out of it so in your scenario i don't know i don't know how to say it in a way that's maybe not a lazy way, but it's like, can it be just as easy?

15:54Listen, I want to run everything, and can I just run your command, or do I have to kind of know what's going on? I don't know if there's different teams that are putting this together, but can you just give me a command and I'll just run it, and I don't necessarily have to know all the details, or do I need to get more of the details to get the value? No, I think it has all of those same properties where, like you described, oftentimes there's a person or maybe a team inside an engineering org that's responsible for the tooling, and if they're doing their job well, It's exactly like you described.

16:20Most engineers on the team don't even really have to know. The automation is just running. It's doing things for them. They don't have to become experts in that system. It's just set up well to work across the entire engineering org. And that's true, actually, with RWX as well. Everything I just described around it running from the CLI is true, but it will also run on like a Git push or when a pull request is open and all that can be configured. The benefit is like even in the feedback loop for agents will be able to iterate far more efficiently if they just kick off runs directly, as opposed to going through that entire Git process for every change that they're trying to validate.

16:55And the really cool part, we could talk more about this, is that RWX uses content-based caching, which basically means you'll never do the same work twice. A lot like Docker layer caching, if you go to run the same command on the same files as you've previously executed, RWX will skip that execution entirely and produce a cache instead. So what this means is you can actually instruct your agent to run rwxrunci.yaml before it opens up a PR, it'll loop and it'll fix errors and very productively validate its changes. And then when the agent actually goes and opens a pull request, the status check will go green instantly because the agent has already run it before.

17:31Because the agent before it pushed the code up to GitHub ran those exact test commands on that exact source code as it ended up pushing. So even though you still have CI configured to run on that PR, the status check just goes green instantly if the agent already ran it. Okay, so smart says we've already done this work. We're not going to do it again. Okay, and I, the human being, don't have to remember that. Yeah, you don't have to. I would never remember that I did that, or I didn't do that. So let's go. I want to hear more about that in a second, but let's go back. So there's kind of probably two different ways people are doing it.

17:57There's obviously those people that have, I don't know, five million agents running simultaneously, rebuilding the world. So I always put them in their own category. And then there's, I don't know, human in the loop, where it's like you're working with your coding agent. You finally get the feature, the thing. You think it's pretty good, right? And then how do people use it today? Are they just in cloud code or their favorite agent tool and saying, okay, I don't know, do you have an MCP server or something? And I just say, run this command for me. And then even shortcut the whole thing. Run this command and you find any errors, come back with suggestions on how to fix it.

18:29Is that what you're seeing in real life? Is that what people are doing? Yeah, I think the most effective engineers now are the ones that are getting their agents to do that before there's a human in the loop at all. So it really doesn't make sense anymore A lot of engineers will ask me, like, hey, what's the best way to automate it so I can have an agent go and fix my build failures? And you can, but I find it to be far more effective just to make the agents do that initially before they push the code up at all. So you just never have build failures that are pushed up. You can just have an agent validate its work before a human is in the loop at all.

19:03And RWX also supports sandbox executions, which really allow agents to also run the inner loop of validating individual test changes and running individual tests as it's making code changes. So really with that, an agent can validate obviously changes as it's making them. It can then also leverage distributed compute, which is really the key here. It's really we're focused on engineering teams that have comprehensive enough automation that you need distributed compute to validate it, that you're not just going to run everything locally on your machine. Give that agent that distributed compute so they can make sure everything passes.

19:37And there's really no reason to have a human in the loop around test failures. The agent models are good enough to abort if, I don't know, it hits some test failure where maybe the prompt is ambiguous and it needs to ask for more input to proceed. But otherwise, I think there's just no reason anymore for a human to ever have to be in the loop for build failures. Obviously, that's the way we used to work. The way we used to work is you commit, you'd push, you'd go check your build later, go see what test failed, go fix those tasks and go through another feedback cycle. But now you can just tell your agents to run rwxrunci.yaml and fix any issues that it finds.

20:08You can put that in your agents.md or in your prompt, and then your attention isn't pulled into it until the agent has already ensured that none of the code changes that it made broke anything. Okay, so then where do you see the human coming back into the loop? So the agent's going to fix all the build errors, and then eventually the build runs, everything's good, and then the developer, whoever gets a notification, can say, okay, it's all in there. And if they want to go take a look at it, they can, or run more tasks, they can. Is that kind of the way it's working in the quote-unquote real world?

20:36Yeah, I think so. It really depends on what the engineering team is building and what sort of review process they want to have. And obviously, there's a pretty wide spectrum there. Some engineering teams are still pretty similar to how they were before AI, where there's a pretty thorough review that's happening on top of every single code change. Maybe with a difference being that the person who entered that original prompt is often doing the first review, because when we were writing code by hand, there's almost an implicit review that's happening as you're writing it, where when the agent's doing it, even And that person that prompted the agent initially maybe wants to take a look at what they're doing.

21:08But obviously, other organizations are complete software factory type automation that they don't have humans reviewing everything. And if all the automation passes, that's good to go. And we have engineering teams running on RWX that do a lot of really interesting things. Like there's one who will have an agent go and write automated playwright tests to do what would be probably analogous to like kind of manual or automated QA. And they throw away those playwright tests. They don't really keep them around as a regression suite, but they use that to get the agent to do extra work to validate that the code changes are actually working functionally from the perspective of the product before that PR is open.

21:44But I think all that just depends on the engineering team and the practices they want to have and the type of software that they're building. Yeah, I just personally, I just find that it's like all the kind of like command line automated tests are usually awesome. It's like the playwright level, though. It's always where you're always like, huh, did it really do it? I don't know. Sometimes it's like, sometimes Playwright doesn't. Sometimes you're like, I'm not sure I really did it. So those part, I guess the UI part is still, I don't know, maybe it's not hard. I feel like when I say anything, I'm like, oh, I bet you the people at Anthropic have already solved this.

22:12So maybe they've even got better solutions. Let's get into it. You talked about a couple of the things that really make it great. Now, I kind of want to talk about two things here and to kind of give people a flavor of what you've done. So there's the content-based caching, which you talked before, but maybe you should talk about how does that work? Why does that work so well? And then I don't want to, we'll just say graph, right? Getting into like going through it in a, the build in a directed graph that makes sense. Cause that seems like another key to your success. So I don't know, take us under the covers.

22:39How do these things actually work? Yeah. Let's, let's maybe start with the graphs and then we can come back to the caching. You know, we really think that structuring pipelines and distributed code execution as a graph is, it's more efficient to run for certain and also just kind of more ergonomic in general. And, you know, the way this works is that traditionally, a lot of this automation is broken down into jobs. Every job runs its own virtual machine. And every one of those VMs has to go through the same setup steps. There's a tremendous amount of overhead, like Datadog just published a blog post, because they were running so many parallel jobs, every one of those virtual machines was having to clone the code.

23:20And it was placing a huge amount of strain on their Git server, to the point where they had to, like, you know, retool, you know, their Git hosting to be able to support the CI workloads. But when you think about it, it's really inefficient and silly that every one of those virtual machines is having to do all that redundant work to each individually clone down the code. The way that graph-based execution works, or running as a DAG, is that you don't really have to think about your pipelines in terms of jobs and virtual machines at all anymore. You just define everything that you want to run, and the dependencies between it, and everything runs with maximum parallelization and only needs to run once.

23:59So not once per job, but just quite literally once. So in the scenario that I was just talking about, you know, with Datadog, even if they wanted to, you know, shard and partition their test suite across 100 parallel nodes, with graph-based execution, they don't have to clone their Git repository once on one virtual machine. And then you can take that output and replicate it out to all the other machines as necessary. So everything will always run with maximum parallelization. In the traditional model, every time you go do something new, you have to decide, do I tack this onto the end of an existing job?

24:34Do I make a new job for it? And then like provision a new virtual machine for it. With graph-based execution, like on RWX, you just don't have to think about it at all. At the granularity of what would be a step in the traditional model, you define tasks, you define dependencies between those, the setup, everything runs with maximum parallelization. based on that dependency graph. And there's two second order benefits that are also really impactful. One is the experience on failures and retries. With the job-based model, anytime something fails, you always have to start the retry from the top of the job.

25:07So something fails five minutes into the job on step eight, and you have to rerun steps one through seven to retry that. With graph-based execution, every step is atomic. So you can always start to retry at the point of failure. Additionally, in the traditional model, an entire job runs on a single virtual machine, which is provisioned with one set of resources in terms of like CPU and memory. Where with a graph-based model, you have a lot more flexibility. You can actually crank up the CPU or the memory for each step individually. So you can crank up the CPU to compile some dependencies and then maybe fan out to a bunch of smaller machines for your test suite, or vice versa.

25:43You can run your setup on a small machine and then fan out to bigger machines. But you have a lot more, basically have the ability to write size of the compute that's used for every individual step in the pipeline. So on the graph side of it, one, who's creating this graph? Are you figuring this out? Am I just telling you, like, I got all these steps, and then you and the software behind the scenes are decomposing this into a graph for me? Is that how it works? What's going on there? It's actually really simple, because you just specify the dependencies directly. It's almost a little bit like having multi-stage Docker builds, but far more ergonomic.

26:19So for everything that you run, you specify what the dependencies are, like which other tools you need installed or which other tasks you need to run to run the subsequent one. In a more traditional approach, you have to define all those steps and you have to define them within every single job. You're going to be cloning the code and installing system packages and installing your language runtime and configuring some tools and everything. And then you're copying and pasting that setup, sometimes with some awkward reuse in each job individually. But with RWX, you do have to define it, but it's really natural because you'll define a task to install your system packages.

26:53And then any other tasks that you want to run that needs a system packages installed, you just specify that dependency that, oh, to compile my package manager install, I need the system packages installed first. So you say use system packages and that's it. It's just a use declaration. And that declaration then assembles the tasks into a graph because it knows which tasks need to run after which other tasks. And I know there's a lot to explain here, but it's almost like we're building Docker images on the fly. So there's no snapshots. There's no manual caching that's happening. We take the output of every individual task that we can run, and we can assemble those outputs together to pass those dependencies into the next task that needs to run.

27:39So is it behind the scenes? Is it either like, am I doing this like a config file, like a Docker file type of thing where I say, here's what I need. And then other people can like build on top of that. Is that what I'm doing to actually tell the system this is what I want done? Yeah, yep. There's a YAML file. The YAML file starts from a container and it starts from any container image that you want. We don't use Docker directly because it's too slow, but we essentially build our own distributed container runtime and it's completely compatible with the OCI spec. So also like with RWX, you can pull down a container image that corresponds to any individual step in your pipeline.

28:14But you define that workflow. You define what you want to run. You start from a container image. And then from there, you write tasks to install the tools that you need, configure the image the way that you want, pull down Docker images that you need to run your workflows. Every one of those tasks can be cached atomically. And the outputs of them can also be combined together to feed into other subsequent tasks. We're talking about graph-based execution here. You'll get automatic parallelization of maybe pulling down Docker containers, maybe you have different languages. Almost everybody, unless they're purely TypeScript, will have some TypeScript for the front end and some back end.

28:48All that setup's going to run in parallel. And then you can take the output of all those tasks and pull it together to then maybe boot your application and run a test suite. Okay, that makes sense. So then on the caching side, kind of when you were talking there, I was thinking like Cloudflare, oh, it just caches everything and it works like magic. but maybe the more appropriate is, because it's what you said there was, it's a container basically at every step. So you've basically, once that container's been built, you've got it in a cache somewhere and then anyone that wants that container can just grab it.

29:15They don't, that, and that's where the, I assume the benefit of like not having to go back and rebuild everything and do it over and over. Is that how it's working behind the scenes? Or maybe ask me this way, are you caching anything beyond the containers or some other magic caching happening that we should know about? No, you pretty much have it right. There's a few differences that are maybe, yeah, a few differences that we take in the approach, though, to make this a little bit more ergonomic than it is on other platforms. But in effect, we're automatically producing an image for every single step without the overhead of having to build and push those images to run things.

29:48That's really almost just like the images get built on the fly. The key ergonomic improvement that we made, though, is like I'm sure you've been through and most listeners here have been through the exercise of trying to optimize Docker caching by very carefully ordering their copy statements into their container. And that's because Docker uses lineage based caching. And with lineage based caching, once you have a cache miss, everything downstream is going to be a cache miss. RWX uses content-based caching, which means that the cache key is based on the contents of all of the code. And then, of course, the commands you're running, the environment variables, and everything else.

30:26But with content-based caching, you can actually have a cache miss followed by a cache hit. And the key ergonomic improvement from this is that most workflows on RWX will start by cloning a Git repo. And then as individual commands are running, you can filter those commands down to just a subset of the files. And if you filter down to a subset of the files where the contents of those files has been seen before, you'll skip the execution entirely and produce a cache hit instead. So the implication of this is that the only things that will run are the things that need to run based on the changes that you've made.

31:03Interesting. So I can see what you've probably found a lot of wasted time. And just as you're talking, I was like, yes, there's probably quite a bit of things. I don't know, even when I just rebuild things on my local machine, I'm always like, I think we just did this. What are we doing this again for? But anyway, that's a separate personal problem. Now, so you've kind of got all the caching going there. And of course, like when I hear all of this, and you've mentioned a couple of times that you can scale out, give it more compute. So in my mind, I just like Kubernetes is just like going off. I'm like, what are they doing?

31:29How are they running all these containers? So I don't know, maybe you're gonna tell me you've done something else. So how do you do it? Do I just have some big cluster and you just like out there and you can, I just give you a bunch of capacity and you just throw those images out there and containers when you want to run them? How does all that work? Yeah, we do have a container compatible runtime, but we couldn't use Docker or Kubernetes directly because it's too slow. A lot of that technology was built for a pretty wide variety of use cases. I'd say that's an understatement right there. But go on.

31:57Yeah, it's like obviously Docker, both absolutely incredible technologies and platforms. Of course, of course. Built to handle, built to pull container images down like across the internet and run on your machine. And we're optimized for running inside like a cloud, running inside a data center use case, which is what has enabled us to achieve far better performance than you get if you're trying to do some of what we're trying to do, but push container images around between everything you're running. It'd just be far too slow. So really what we did, Brandon, is we use the same low-level primitives that Docker uses, run C directly under the hood, but built our own distributed container on time.

32:34So by default, we manage all the infrastructure. So you don't have to provision or worry about anything. You're running these container-based workloads, but on the RWX platform. So no operational overhead, workflows that are very compatible with the tooling and the container images that you're using anywhere inside your infrastructure. And if you want, RWX can run inside your own VPC, run inside your own cloud. But by default, we manage everything. But it's really like having a distributed container runtime. It's having Kubernetes without having to push and pull the images and being able to paralyze, being able to spin things up, being able to run code on demand.

33:09That's all container based, but without the overhead of pushing images and pulling images and everything else that's incurred on that stack. Okay. So when I sign up, so if I'm sold, are you hosting? Is that the preferred way? Or I'm sure you do a lot of things, but is it the typical way is that I'll use your hosted service to basically run this for me? and you're doing everything you just said. You're taking care of all this container runtime, all this stuff behind the scenes for me. Is that how people are typically doing it? Yeah, that's the most common approach. A lot of engineering teams like alleviating the need to manage a build cluster, manage some of their own infrastructure.

33:44Certainly in some regulated industries, it can be different. And that's why we do support the option to provision infrastructure inside your own cloud if you want. But predominantly the engineering orgs that are running on RWX are letting us manage the infrastructure. And there's obviously some really nice properties to that. In addition to just having our engineering team be responsible for the reliability of that platform and everything, we can also leverage shared hot pools across our customer base. We never reuse a virtual machine across different tenants just for security reasons, especially container escape vulnerabilities and things like that.

34:18But we can leverage unassigned hot instances across entire customer base. So this is a way that we can actually almost run more efficiently than you would even inside your own cloud account because we can spin up resources faster because we distribute that across every engineering org running on rwx versus somebody just maintaining their own build infra yeah that makes sense economy is a scale taking over there right you've got the scale and you can do what you want so where i don't know do you talk about where do you guys run you run in the cloud you run your own data center some of both how does it how do you deploy it all yeah we We primarily run on AWS.

34:52I think that's a bit of a black box, but certainly some engineering teams know that we're running there and they specifically want low latency access to other services running in AWS. But I think the key thing is that for us, we're really trying to innovate at the software layer. There's some great players in this space that are trying to innovate at the hardware layer and get better hardware, better chips, more modern infrastructure. And the technology that they're building is focused there. For us, we're focused on innovating at the software layer and it just made sense for us to run on top of an existing cloud.

35:23I'm sure at some point in the future, we'll look at racking our own servers, but our engineering team right now is focused on the software orchestration and platform. Makes total sense. That makes total sense. Okay, I think I appreciate you kind of taking this through there. I think I got it now, sort of the graphs, the caching, giving us a lot of speed, but why don't we come up a level and talk about, I'm talking about any of them. One of the customers I saw on your website, Honeycomb, that's a name most of our listeners will have heard of. So why don't you take me through What was their pain that they were experiencing?

35:51And then what's the journey they went on to, if you will, achieve nirvana with you guys, shall we say? Yeah, we've loved working with the Honeycomb engineering team. It's a talented engineering team. A lot of those conversations that we have help us guide our own roadmap as we're collaborating with them on what they're trying to achieve in terms of developer tooling. And working with talented, discerning engineering teams like that is certainly the best part of my job. So Honeycomb, they had been running on CircleCI, and they were just feeling the overhead of shifting to a more agentic-driven process and being able to run code efficiently, accelerate their feedback loops, get PRs out to production faster, and also doing that in a way that wasn't just rapidly escalating costs.

36:37so they engaged us to do a poc which is probably how most engineering teams have come onto rwx one of the nice things one of the nice properties of continuous integration is you can run it side by side with an existing solution it's not like you have to do a hard cutover and that's the thing that results in over 90 of the teams that have evaluated rwx moving forward with it because everybody looks at and they're like oh this is running faster it's going to cost us less the tooling works better with our agents and then it's just a no-brainer and that was really the conclusion that Honeycomb came to.

37:06We published a case study on our website, but they realized that they were able to get their agents in a loop with RWX so much more efficiently than what they were able to do before, that they just got a lot more mileage out of their agents. Their agents were able to work more quickly and build out a lot of pipelines and automation entirely on their own. So they published a blog post where they talked about doubling their PR velocity once they made the switch to RWX because that feedback loop was so much faster. And they really liked describing RWX as AI-legible CI, meaning it's a CLI-driven interface where agents can kick off runs, agents can get semantic outputs instead of having to sift through log files and iterate completely autonomously with the benefits and efficiency of caching as well.

37:49Yeah, I think it was a great story. And it's rare you find, it's not rare to find case studies on anybody's website, but it's rarely find on the Honeycomb. I don't know, I think it may be their engineering blog. It's actually a two-parter. It's actually a little. It's like you have to like, it's pretty detailed. So this is, so anyway, as I was preparing for it, I was looking at it. So if you really want to know like what I think a very talented group did, and they wrote a lot. So there's a lot there to take in. So I would, anyone that's even remotely interested, you should go check that out. I think we've talked a lot about stuff.

38:18Maybe the next thing is where are you going? Obviously, we have agents and I think you've built a great solution here. Is there things on the horizon? Next things that you're trying to achieve that customers are beating down your door for? We're really focused on this validation layer. We're seeing the bottleneck in software engineering move from the time and effort required to write code, you know, to really being able to validate it. And that being a bottleneck for shipping more code to, for our customers to ship more code to their customers and on their own products. But I think we realize that the foundational infrastructure that we built has a lot of use cases beyond just continuous integration pipelines and especially the approach that we took to build it unlocks a lot of other use cases.

39:00So we also support sandboxes, which I did briefly mention earlier. We support running preview web apps. So you can get a URL for every branch or every change. It doesn't even have to be a branch. Again, RWX is CLI based. You can just take the code on your machine and get a URL that corresponds to running that code in the cloud. And you can even trigger automation based on like custom web hooks directly in RWX. So we have a lot to do focusing on just kind of this area of really cloud computing and automation for coding agents as it relates to builds, tests, and kind of development as a whole. I don't know that we'll take this technology all the way into running production type systems, but we've had a lot of our customers ask us when we're going to provide code hosting, code review, and start maybe competing with GitHub a little bit more broadly.

39:46Nothing I can promise today on that, but it's certainly something that is interesting to us. I can see why. You've done a lot of the hard work, right? You mentioned just on this thing, you wrote your own container runtime, you've got your own, not Kubernetes, but your own system, and if it's performing at a high level, that's always going to attract people. People always want more speed, so that makes sense. And of course, we were talking a little bit before show, I read every day, there's another article about someone's like, they're trying to rewrite or replace Git. So I feel like that's, I don't know.

40:16I'm not close enough to be like really have an opinion, but I know it seems like there's a lot of people that are a little frustrated. Maybe like you were in your old job. There's a little frustration out there with GitHub and Git in general. So we'll see. We'll have to see what happens. We'll keep an eye on you. Maybe you'll be the ones to do it. This has been a great conversation. If people either want to get in contact with you or maybe they'll have to just try RWX, where should they go? What should they do? Yeah, it's certainly easy to find us online. We support free trials. We give everybody$100 in free credits to sign up.

40:48But rwx.com is our website. We're rwx on Twitter. You can reach out to me directly. I'm dan at rwx.com and dan underscore mangus on Twitter. So I would love to chat with anybody who's thinking about retooling their dev processes for agentic development now. All right, everyone, you just heard you have your call to action. Dan is ready to help you. It sounds like he can speed up your entire build system. So you definitely want that. So Dan, really enjoyed the conversation. Thanks a lot for coming on the show today. Yeah, thanks, Brian. Thanks for having me. And for everyone else, we appreciate you listening today.

41:20Of course, if you're not subscribed, please go ahead and subscribe right now in the podcast player you are listening to. And if you are so inclined, give us a five-star review on one of the many websites that host podcasts. And with that, we will talk to you next time. Thanks for listening. Check us out at theenterpriseaishow.com for past shows, newsletters, and all things Enterprise AI.