Confidence or Con? The Psychology of Tech’s Boldest Leaders

0:07Aaron Good morning, good evening, wherever you are, 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:33Brian Today'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 Idira by Palo Alto Networks comes in.

0:52Brian Human, machine, AI, one identity platform for all of them. Idira replaces permanent permissions with dynamic access, so you can lock down every identity without slowing down your business. Secure every identity with Idira by Palo Alto Networks. Visit paloaltonetworks.com/idira. Again, that's paloaltonetworks.com/IDIRA.

1:19Brian Today'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.

1:36Brian 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:53Brian Connect with Nord Security to learn more about NordLayer AI Scout. Visit nordlayer.com/ai-scout/enterpriseai and get started today

2:09Brandon And we're back. Joining me today is Dan Mangas, co-founder and CEO of RWX. Welcome to the show, Dan

2:16Dan Thanks for having me, Brandon

2:18Brandon 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?

2:31Dan Yeah, that 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 years after that, I co-founded a car insurance carrier, Root, in 2015.

2:50Dan We launched the product in 2016 and went public at an IPO in 2020. So through both of 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 who could be impacted by your changes.

3:19Dan But I also felt like there were, some technical tools that didn't scale as well with our code base as I would've hoped. And as I looked into this problem space, I realized, big companies like Google, they had this internal build system, Blaze, that inspired open source Bazel, built around all these amazing techniques.

3:34Dan But it was ex- 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.

3:46Brandon 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. So why don't you take us inside that? You're at these large companies and, you're do- or I guess, successful companies and are doing very well.

4:02Brandon But, like, when you say… dive into that a little bit. It's like, what was the pain that w- that you were seeing? Is it just long times to get de- deployments out? Is it just frustrated developers? What were you living every day to get you motivated to actually say "I'm actually gonna go solve this problem once and for all"?

4:17Dan Yeah, I think it's good that you called out that, bo-both of those experiences for me were in regulated industries where the reliability of our software, was critically important. And 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.

4:36Dan 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, 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:58Dan There's that well-known XKCD around engineers slacking off, with the excuse that, their code is compiling. And in, 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.

5:19Dan 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, you know, horribly inefficient to me

5:35Brandon Yeah I think you wrote it somewhere or I saw something on your website and not to oversimplify any company, but I really liked it 'cause I just crystallized what was going. It said something like, if you can reduce the time it takes to basically go through the whole cycle to 15 minutes and basically get four loops an hour, right?

5:50Brandon Versus if it takes an hour then of course you get a lot. So it's like in some ways it's just, 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? And also so they can k- stay in the zone, right?

6:06Brandon I know we're not playing sports here, but you know what I'm saying. You stay in that that feeling of like you get going and you don't… 'Cause I think that's the big part. You walk away and then you let the build run and then you go do other things. So are you-- Is there, in your mind going back to maybe your previous jobs, is there like a, a number like you, you say to yourself almost like I just, I wanna get people this many reps in an hour because I feel like this is what keeps them engaged"?

6:27Brandon Is that like how you think about like the business problem at the highest level?

6:31Dan Yeah, I do think there's a few thresholds there where, how an engineer is going to work is going to change based on, that, 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.

7:02Dan And really once you start crossing that threshold, you're going to be pretty inclined to multitask and go switch off to something else. And 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.

7:20Dan 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 wanna try to feel productive.

7:39Dan And now, it's-- 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.

7:47Brandon Yeah, I think this is a really interesting idea. It's like there probably is something about human beings around like you wanna 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.

8:03Brandon So I like that. That's a probably-- that's probably like a, a life lo- a, a life lesson for all of us. Just wait. Just wait for a few minutes. Don'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?

8:17Brandon So what are you kinda looking at when you kinda look at this and after these successes, you could 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's become s- so popular however many years ago?

8:36Dan Certainly if there's a theme for my career, it has been working in like mature, entrenched industries and trying to bring a new approach to it. Both 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.

8:54Dan 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 interesting to me, they'd all been built around a similar abstraction which is really parallelizing 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:24Dan Oftentimes just running the exact same command on the exact same files as had been previously executed or that is currently being executed like a- 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.

9:48Dan 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 in a w- and 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.

10:17Dan 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.

10:29Brandon So is the end goal then really, as simple as speed? You just want to get through the, the integration builds as quickly as possible? Is that your guiding light or is there something you talked about more the abstraction. Is there something more you're trying to bring inside the industry? You want people to think differently about it than maybe they thought about it before?

10:46Dan 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 als- oft- also found that, the overall developer experience and now how that ties into the agentic experience is if anything, even more impactful.

11:17Dan 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 and, 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, hi- higher levels of actualization of, developer tools and build pipelines.

11:42Brandon Yeah, so you mentioned agents, and I think that's probably ma- a good way to set it up. So I would imagine, say I'm just a large company, could be anybody, and I'm, 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.

11:58Brandon 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. And 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:15Dan Yeah, 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 were 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.

12:36Dan 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. And 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 was, is very version control centric.

12:58Dan And it made sense. They built their platforms that probably if an engineer spent a few hours writing code and wanted to run the build, 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.

13:11Dan 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. And, 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 was gonna work just to test your changes, because the only way to run anything was with a Git push.

13:33Dan 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.

13:54Dan And 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.

14:09Dan 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.

14:26Brandon So it's really interesting. I feel as you were talking there, I almost just feel like I type git commit push, like without even thinking. Like 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.

14:43Brandon I just know if I do this, all this stuff happens. And I don't wanna 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 know, at least for me, maybe other people like it, 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.

15:02Brandon So in your scenario I don't know. I don't know how to say it in a way that's maybe not lazy, a lazy way, but it's like, is it, can it be just as easy as listen I don't, I j- I wanna run everything and can I just run your command or do I have to like kinda know what's going on? Can I don't know if there's, different teams 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?

15:26Dan No I think it has a lot 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. Most engineers on the team don't even really have to know.

15:40Dan The automation's 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.

16:00Dan The benefit is, like even in the feedback loop for agents will be it- 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. And 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.

16:19Dan 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 hit instead. So what this means is you can actually instruct your agent to run RWX run ci.yaml before it opens up a PR. It'll loop, and it'll fix errors and very productively validate its changes.

16:40Dan 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, because 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.

17:01Brandon Okay, so smart says "We've already done this work. We're not gonna do it again." Okay, and I the human being don't have to

17:06Dan And you don't, yeah, you don't have to,

17:08Brandon remember that I did that or I didn't do that. So let's go… I wanna hear more about that in a second, but let's go back. So there's kinda probably two different ways people are doing it. There's obviously those people that have I don't know, 5 million agents running simultaneously rebuilding the world, so I always put them in like their own category.

17:21Brandon 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 or the thing, you think it's pretty good, right? And then are- how do people use it today? Are they like just in Claude Code or their favorite agent tool and saying, "Okay," I don't know, do you have MCP server or something and I just say "Run, r- run this command for me," see, and then even shortcut the whole thing.

17:42Brandon "Run this command, and if you find any errors, come back with suggestions on how to fix it." Is that what you're seeing in real life? Is that what people are doing?

17:50Dan 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 that I can have an agent go and fix my build failures?

18:06Dan 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. And RBX 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.

18:33Dan 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 gonna run everything locally on your machine.

18:50Dan Give that agent that distributed compute so they can make sure everything, passes, and 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.

19:05Dan 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 tests failed, go fix those tests, and go through another feedback cycle.

19:19Dan But now you can just tell your agents to run RBX, run ci.yaml, and, fix any issues that it finds. You 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.

19:34Brandon Okay, so then where do you see the human coming back into the loop? So the agent's gonna fix all the build errors, and then eventually, the build runs, everything's good, and then the developer or whoever, gets a notification, can see if it's like, okay, it's all in there. And if they wanna go take a look at it, they can, or if, run more tests, they can.

19:50Brandon Is that kind of the, the way it's working in the quote-unquote real world?

19:53Dan Yeah, I think so. It really depends on what the engineering team is building and what sort of review process they wanna 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.

20:09Dan Maybe with the 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 that person that prompted the agent initially, maybe wants to take a look at what they're doing.

20:25Dan But, obviously other organizations are, complete software factory type automation that they 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 Art of React to 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.

20:47Dan 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 opened. But I think all that just depends on, you know, the engineering team and the practices they wanna have and the type of software that they're building.

21:07Brandon 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 does it and sometimes you're like, "I'm not sure it really did it."

21:21Brandon So those part, I guess the UI part is still, I don't know, maybe it's not hard. I think, I feel like when I say anything, I'm like, "Oh, I bet you the people at Anthropic have already solved this." So maybe they've even got a better solution, let's get into it. You t- you talked about a couple of the, the things that really make it great, and now I kinda wanna talk about two things here and k- to kinda give people a flavor of what you've done.

21:38Brandon So there's the content base caching, which you talked before. But maybe just talk about how does that work? Why does that work so well? And then, I don't wanna… we'll just say graphs, right? Getting into like going through in a, the build in a directed graph that makes sense. 'Cause that seems like another key to your success.

21:54Brandon So I don't know, take us under the covers. W- how do th- these things actually work?

21:58Dan Yeah. Let's, uh, let's maybe start with the graphs, and then we can come back to, uh, the caching. Um, you know, we really think that structuring, uh, pipelines and distributing code execution as a graph, um, is-- it's more efficient to run for certain, um, and, also just kind of more ergonomic in general.

22:16Dan and you know, the way this works is that, uh, traditionally, uh, 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. Um, and there's a tremendous amount of overhead. Like Datadog just published a blog post.

22:31Dan Because they were running so many parallel jobs, every one of those virtual machines was having to clone the code, and it was placing a huge amount of strain on their Git server t-to the point where they had to like, you know, retool, you know, their Git hosting to be able to support the CI workloads.

22:47Dan Um, but when you think about it, it's, you know, really inefficient and silly that every one of those virtual machines is having to do all of 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 like jobs and virtual machines at all anymore.

23:06Dan 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. So 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, um, with graph-based execution, they'd only have to clone their Git repository once on one virtual machine.

23:34Dan 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

23:47have to decide do I tack this onto the end of an existing job? Do 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.

24:11have to decide 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. So something fails, five minutes into the job on step eight, and you have to rerun steps one through seven to retry that.

24:31have to decide With graph-based execution, every step is atomic, so you can always start the retry at the point of failure. Additionally, in the traditional model an entire job runs on a single virtual machine, just 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.

24:48have to decide 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. You can run your setup on a small machine and then fan out to bigger machines.

25:04have to decide But you have a lot more basically have the ability to rightsize the compute that's used for every individual step in the pipeline

25:11Brandon So on, on the graph side of it, one, do-- like who's creating this graph? Are you figuring this out? Am I just telling you like, "I got all these steps," and then you're, you and the software behind the scenes are like decomposing this into a graph for me? Is that how it works? Or like what's going on there?

25:25Dan 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. So for everything that you run, you specify which-- what the dependencies are. Like, which other tools you need installed or which other tasks that you need to run, to run the subsequent one.

25:46Dan In a more traditional approach, you have to define all those steps, and you have to define them within every single job. You're gonna 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.

26:04Dan 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 and then, any other task that you wanna run that needs those system packages installed, you just specify that dependency that, oh, to compile, my package manager install, I need the system packages installed first.

26:20Dan 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 it's… I know there's a lot to explain here, but it's almost like we're building like Docker images on the fly.

26:42Dan So there's no like snapshots, there's no like 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.

26:56Brandon So is it behind the scenes? Is it are there like, is it, am I doing this in like a config file, like a Docker file type of thing where I say "Here's what I need," and then, o- other people can like build on top of that? Is that what I'm doing to actually, tell y- tell the system this is what I want done?

27:09Dan 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 that'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.

27:30Dan But 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.

27:52Dan So you can get, we're talking about graph-based execution here. You'll get like automatic parallelization of maybe pulling down Docker containers maybe of different languages. Almost everybody unless they're purely TypeScript, will have some TypeScript for the front end and some back end. All that setup's gonna 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.

28:13Brandon Okay, that makes sense. So then b- on the caching side, kinda when you were talking there, I was thinking like Cloudflare, it's oh, it just caches everything and it's all works like magic. But maybe the more appropriate is 'cause it's what you said there was, it's a container basically at every step.

28:24Brandon So you basic- 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. They 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?

28:39Or maybe ask it this way Are you caching anything beyond the containers or some other magic caching happening that we should know about?

28:46Dan No, you pretty much have it right. There's a few differences that… Or maybe, yeah, a, 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:05Dan It'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 in another container.

29:21Dan 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.

29:43Dan But 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.

30:02Dan 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.

30:20Brandon Interesting. So I can see where you've probably found a lot of a lot of wasted time. Just as you're talking, I was like, yes, there's probably quite a bit of things. I know even when I just rebuild things on my local machine, I'm always like, "Oh, I think we just did this. What are we doing this for again for?"

30:32Brandon But anyway, that's a separate personal problem. Now so you've kinda got all the caching going there and, of course, like when I hear all of this, and you've mentioned a couple 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? How are they running all these containers?"

30:46Brandon So I don't know, maybe you can 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 wanna run them? How does all that work?

30:59Dan 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. Like obviously

31:11Brandon an understatement right there. But go on

31:14Dan Yeah. It's like obviously Dock-- absol- both absolutely incredible technologies and platforms, but, y- 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.

31:38Dan It'd just be, far too slow. So really what we did Brandon, is we used the same low-level primitives that Docker uses run C directly under the hood but built our own distributed container runtime. So 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.

32:00Dan 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.

32:17Dan 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 that's all container-based, but without the overhead of pushing images and pulling images and everything else that's incurred on that stack.

32:35Brandon 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, do you just, you're doing everything you just said. You're taking care of all this container runtime, all this stuff behind the scenes for me.

32:51Brandon Is that how people are typically doing it?

32:53Dan Yeah, that's the most common approach. A lot of engineering teams like alleviating the need to manage a build cluster or manage, some of their own infrastructure. Certainly 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.

33:08Dan 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 like shared hot pools across our customer base.

33:26Dan We never reuse a virtual machine across different tenants just, for security reasons especially, like container escape vulnerabilities and things like that. But we can leverage, unassigned hot instances, across an 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 can distribute, that across every engineering org running on RWX versus, somebody just maintaining their own build infra.

33:55Brandon Yeah, that makes sense. Economies of scale taking over there, right? You've got the scale and you can do what you want. So where I know do you talk about where do you guys run? Do you run in the cloud? Do you run your own data center? Some of both? How does it, how do you deploy it all?

34:06Dan Yeah, we primarily run on AWS. I think that's a bit of a black bo- black box but certainly, s- 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.

34:23Dan 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, 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.

34:40Dan I'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.

34:48Brandon Makes total sense. That makes total sense. Okay let's, I think I appreciate you kinda taking us 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, we can talk about any of them. One of the customers I saw on your website, Honeycomb, that's, a, a name most of our listeners will have heard of.

35:03Brandon So why don't you take me through what was their pain that they were, experiencing, and then, what's the journey they went on to, if you will, achieve nirvana with you guys, shall we say?

35:14Dan Yeah, we've loved working with the Honeycomb engineering team. It's, 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 like developer tooling and working with talented, discerning engineering teams like that is certainly the b- the best part of my job.

35:33Dan So Honeycomb, they 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.

35:54Dan So they engaged with us to do a POC, which is probably how most engineering teams have, come onto RWX. One of the nice things, and 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 cut over. 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 it 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.

36:20Dan And that was really the conclusion that Honeycomb came to. We 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.

36:39Dan So they published a blog post where they talked about like 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:06Brandon Yeah, I th- I think it was a great story, and I-- 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 quite a lot. It's like you have to like…

37:19Brandon It's pretty detailed. So this is, So anyway, as I was preparing for it, I was looking at. So if you really wanna know like what I think a very talented group did, it's-- 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.

37:33Brandon I think we talked a lot about stuff. Maybe the next thing is where are you going? You obviously, you-- 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?

37:46Dan 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.

38:05Dan 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. So 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.

38:25Dan It doesn't even have to be a branch. Again, RWX is CLI-based, so you can just, take the code on your machine and get a URL that corresponds, to running that code in the cloud. You can even trigger automation, based on like custom webhooks 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, tasks, and, kind of development as a whole.

38:49Dan 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 gonna provide code hosting, code review, and start maybe, competing with GitHub a little bit more broadly. Nothing I can promise today on that, but certainly something that is interesting to us.

39:08Brandon I can see why. You guys have done, you've done a lot of the hard work, right? You mentioned just on this thing, you said that we- you wrote, re- rewrote, not rewrote, but you wrote your own container runtime. You've got your own, not Kubernetes, but your own, system, and it's… If it's performing at a, a high level, ev- that's always gonna attract people.

39:22Brandon People always want more speed. So that makes sense. And of course, we were talking a little bit before the show, it's I read every day there's another article about someone's like, they're g- trying to rewrite or replace Git. So I feel like that's I don't know, some- everyone… I'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 k- a little frustrated.

39:41Brandon 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. So 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 wanna get in contact with you or maybe they have to just try RWX, where should they go?

39:57Brandon What should they do?

39:59Dan Yeah, it's certainly easy to find us online. We support free trials. We give everybody $100 in free credits who sign up. But rwx.com is our website. We're RWX on Twitter. You can reach out to me directly. I'm dan@rwx.com and Dan_Mangus on Twitter. So would love to chat with anybody, who's thinking about retooling their dev processes for agentic development now.

40:21Brandon 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 billing system, so you definitely want that. So Dan, really enjoyed the conversation. Thanks a lot for coming on the show today.

40:32Dan Yeah, thanks, Brandon. Thanks for having me

40:34Brandon And for everyone else we appreciate you listening today. Of 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.

40:55Brandon Check us out at theenterpriseaishow.com for past shows, newsletters, and all things enterprise AI