Software Huddle - Faster Code Validation for AI Agents with Dan Manges

Episode Date: October 27, 2026

Today, we have Dan Manges, Co-Founder and CEO at RWX, on the show! Dan previously served as CTO at Braintree and co-founded Root Insurance, and is now building a CI/CD platform designed for the agentic era. In this episode, we explore how AI coding agents are changing software development and why the bottleneck is shifting from writing code to validating it. Dan explains why traditional CI/CD workflows are struggling to keep up, and how RWX uses content-based caching, graph-based execution, and a CLI-first approach to make builds faster and more efficient. We also dive into how engineering teams can rethink their development workflows around AI agents, from validating code changes before opening pull requests to using sandboxes and distributed compute. Dan shares his thoughts on harness engineering, why developer tooling needs to evolve alongside AI models, and what it takes to build reliable software when code is becoming increasingly cheap to produce. Finally, we discuss how teams should measure engineering productivity beyond build times and costs, and why Dan believes the shift to agentic development is creating opportunities to rethink how software gets built and shipped. Tune in for a deep dive into CI/CD, AI coding agents, and the future of software engineering. Visit https://www.rwx.com/blog/series-a for more info.

Hello everyone and welcome to the show. My name's Rich. I'm the host and welcome as well to Dan Mangus, who is co-founder and CEO of RWX. RWX is a CICD platform for the Agenic Era and Dan's going to talk to us a little bit more about that and a whole lot more besides. Welcome, Dan. Thank you for joining us. Thanks for having me, Rich. I wonder if you could talk a little bit about your background and who you are and kind of your experience. and what led you to RWX? Sure. I was previously the CTO of a couple of high-growth tech startups. I was a CTO of BrainTree in the payment space. BrainTree acquired Venmo, and then we were acquired by PayPal. And a couple years after that, I co-founded a car insurance carrier route.

We started the company in 2015, launched in 2016, and went public in an IPO in 2020. in 2020. So we grew remarkably fast. And through both of those experiences, as a CTO of those companies, I focused a lot on trying to maintain a really high engineering velocity of shipping. And obviously, as you scale, there's going to be some dimensionary turns on productivity. You have more people, you have more code, you have more users that could be impacted by your changes as the business grows and matures. But I also felt like there were some limitations in the technical tools that didn't scale as well as I hoped as code bases grew large. And as I looked into this space, I realized that big tech companies like Google, they had this internal build system blaze that inspired the open source Basel that held these amazing capabilities to build and ship software at scale around the concepts like content-based caching and graph-based task execution.

But everybody I talked to found Basel exceptionally difficult to adopt. It wasn't very malleable to the different polyglot languages and frameworks that companies usually found themselves having involved in their tech stack. And I really wanted to build a platform that provided those same capabilities to kind of the everyday engineering org. And that was largely the motivation for starting RWX. We didn't initially set out to build an entire CICD platform, but that's largely what we focus on today. Cool. Thank you very much. That's a great introduction.

I was wondering, could you talk a bit about kind of, you know, you talked a bit about where you started from with RWX? Like, how has that evolved and, you know, where, what's changed from where you were when you started, I think it was, was it 2022, to where you are today, I guess. Yeah, of course, over that time period, in the entire world of software engineering looks quite a bit different than it did when we first started. I feel very fortunate that the problem that we were working on solving, which we felt like was relevant even before AI, has just become even more relevant now. Like we already felt like an engineer's feedback loop and their ability to quickly and efficiently validate code changes was a really impactful aspect of engineering productivity. And if anything now, you know, with AI being able to write so much code, it's probably the, you know, where the bottleneck has really shifted. and like the major impediment to engineering productivity now. Additionally, a lot of the approach that we were taking

to improve this experience for engineers, the most notable of which is providing a CLI first interface to pipeline executions as opposed to other platforms, which have a Git first and a version control first interface to execution. Also just fortuitously positioned us to work exceptionally and well with coding agents. Because, of course, we had built everything around this CLI and CLIs are really, other than MCP server,

is kind of the de facto interface for coding agents to be able to interact with the service. And I think that's been very fortunate that we took that approach. So on that actually, I was gonna ask you, like when did you decide to do that? Like was that something you did quite early on? Or was it more of a response to how you saw the landscape evolving,

I suppose? Yeah, there's been a little bit of both. So we did start from the onset of having a CLI-1st interface. You know, we always hated the developer experience of having to commit and push when you had no idea if the changes you just made worked. You know, you're building a new CI pipeline, a new workflow definition file. You know, literally no clue if it's going to do what you want to do. And the only way to test is to make a work-in-progress commit and push. And we've seen some pretty hilarious commit logs of people just having, you know, 50 commits to try to see if,

their change is working correctly, just constantly having to commit and push to debug. And on each of those commits, you know, having to wait for the same setup to run over again. And if the change that you're making is several minutes into a pipeline, it's just an atrociously slow feedback loop. So we had started from the onset of wanting to build a platform that was CLI first that used techniques like automatic content-based caching to skip everything that's been run before. So you're never waiting on just the exact same commands or on the exact same source code as what had been previously executed.

And those techniques, even before AI, made RWX the most productive, developer-friendly platform in this space. And those techniques just also translated really well to coding agents. Now, what changed is the extent to which we expose those capabilities in the CLI. One thing that we had focused on

at RWX before AI is the developer experience around failures. Because 95% of the time an engineer looks at CI, it's to see what failed. If everything passes, nobody even looks at it. They just have their green status check on their build, and that's it. So if somebody's looking at the results, it's to see what failed. So we've done incredible work to parse out test failures, show semantic outputs. We actually hide most of the stuff that's successful, because, again, that's usually not what engineers are interested in. And we built this great UI experience around showing those failures, only to wake up in a world where I think hardly anybody's

ever going to look at that UI again because it's only going to be their agents doing things for them. However, all that work that we did to produce semantic outputs instead of raw logs, to really focus in on what the failures were and provide, you know, very targeted, actionable results meant we can expose that same data via the CLI. So when agent runs RWX results, you know, it's not having to comb through and grep through the log files and burn tokens trying to figure out what went wrong. You know, we give agents a very precise list of exactly what failed within each CI run. Cool. Thank you. I'm also interested in kind of how to what extent are you sort of actively responding to kind of what your users are asking for, how things are changing for them, because I imagine that

things are changing quite quickly and they're doing new things. They're experimenting. Like how are you sort of building that into your product roadmap, I suppose. Like, yeah, what are you doing and how are you kind of building on and listening to users and other developers? It's expanded quite a bit for us. Our original focus has been everything that we've been talking about here, CI pipelines as a whole. And we sometimes refer to this as the outer loop of validation,

where the inner loop is making an individual code change, running some tests to validate that change, And then, of course, the outer loop is running all of the validation, running the full suite and the full pipeline to check for everything. But obviously, you know, engineers now are, you know, they're working on running agents in a variety of context. And there's a plethora of different workflows out there. You know, some people are running agents on the machine. They're trying to offload agents into, you know, other like web-based services. So they're not running locally.

They're trying to improve the security of what agents can access. Just a wide variety of different development workflows that, you know, engineering teams are adopting. based on their own preferences and priorities. And that's really pulled us into expanding from just CICD to the entire gamut of validation that needs to happen on top of code changes and giving agents away to validate every aspect of the work that they're doing, including that inner loop.

So RWX now support sandboxes. They're a little bit different than many other sandbox providers that are kind of focused on just, you know, execution environment for an agent to run code. Ours are really oriented around application development, around application development code bases, specific coding projects, and having an environment that an agent can use to work on that code repository

or that application. And essentially what the sandboxes are, are semi-persistent environments using the exact same config, the exact same environment as the entire CI pipeline, but giving agents a way to organize Sync their changes into the sandbox, which happens automatically on each exact call, and then running commands. So even for our own development, we of course use RWX to build RWX, and the only thing that we provide to our coding agents now is the RWX CLA. And then we just instruct our agents that to validate code changes, run commands inside an RWX sandbox.

The CLI takes care of syncing local changes in. It also syncs changes back. So if you have any like code. gen or anything like that that, you know, needs to generate a file and pull back from the local repo. That's all facilitated as well. And then we can tell our agent to run the full pipeline once it's done validating, you know, the local changes, which means by the time a PR gets opened, we've ensured that the agent has already validated all of its changes. And this is something that, you know, our customer base really pulled us into because they wanted just a more comprehensive set of validation on top of their code changes. And it means by the time a human is in a loop, by the time that PR is open, you've ensured that everything works. And you're not like,

awkwardly trying to get agents to go and fix build failures from other agents, you just validated it all up front. And the other really exciting part of this rich is because RWX has automatic content-based caching, if an agent runs a pipeline to validate its changes, even if you have that pipeline configured to run again when a PR is open, the status check will just go green instantly because RWX will realize like, oh, we already ran these exact commands on these exact files before. We don't need to run this again. It'll produce a cache it and that status check just goes green right away. Cool. No, thank you. That's great. I wanted to kind of pull up a little bit to talk a bit

about, and you know, you mentioned there's a lot more to RWX and CICD, but obviously it's the kind of core of the platform and kind of part of how you talk about it. And I wanted to kind of just get your perspective on kind of what does CICD mean, what its challenges in a kind of agent-first world, I guess. Yeah, like what does it actually look like? What's new? What's different and what's actually stayed the same too? Yeah.

I think what's stayed the same has been that automated tasks, automated checks are the most scalable way to maintain software reliability and ship very quickly. I mean, the engineering teams that we see that ship the fastest are the ones that are doing continuous deployment and can do that with confidence, because they just, they have so much confidence that if CI passes, that they haven't broken something. And they're not relying on, you know, manual QA or like a really slow rollout process to be sure they're not breaking something. You know, they just have a lot of confidence in their pipelines that if those pipelines are green, that change can be shipped. And maybe still some manual review,

maybe not, maybe agents doing reviews that I think just depends on, you know, the engineering teams values and like the risk they want to take or just how they think of it. about quality, but the teams that move the fastest still rely on CI to validate everything. I think what has changed is really the frequency and the impact of the feedback loop. Even what we were talking about earlier around CI being a CLI versus like a Git-driven interface is really different in an agenic world. You know, because it used to be the case that if an engineer spent a few hours making a code change. It probably made sense for them to commit and push, get that change off their machine.

And it kind of just made sense that when they commit and push, that's probably just a good time to run the build, you know, especially so that you can make sure everything passes, you put the status check on the PR, and then, you know, it gets reviewed and gets merged and everything. I think this entire way of working, this entire like SDLC doesn't really make sense in an agentic world. You know, having to commit and push to validate a code change, you know, really as necessary because you don't need to like couple the CI pipeline to the version control events. So it's going to be fully decoupled now. Additionally, you took this approach because, you know, a lot of CI pipelines, and I guess most of them really that I'm talking about here are,

you know, CI pipelines of the magnitude that they need distributed compute. You know, they need, you know, to paralyze across a lot of virtual machines because, you know, this automation is too comprehensive to just like run on an engineer's machine. And this is still relevant for agents. You know, some people maybe have a code base or a project where everything's fast enough that the agent could just run it locally. But you really need to give agents distributed compute for them to efficiently validate their code changes. And I think what's different is that it just makes a lot of sense to give an agent tools where it can just validate code changes on its own. It can leverage distributed compute on its own. It understands, you know, both that

in-in-and-outer-loup of validation and takes care of all of that autonomously without necessarily needing to put a human in the loop at all. And I think we're still early and really shifting our ways of working. I think some of probably the least effective engineering organizations right now are the ones that are primarily working the way they worked before, but trying to substitute what people used to do with agents. And I think some of the more effective engineering organizations, conversely, are the ones that are really rethinking from first principles, how they work, and what their workflows are and which tools they use to build a process that is really more oriented towards the way that software is built now with coding agents.

That actually brings me, I think, quite nicely to something else I wanted to talk about, or kind of a way I wanted to approach this, which is the idea of bottlenecks. And I think, firstly, like, identifying them, how you might approach them. And I think, in a way, how you think about bottlenecks or maps on to what you're saying about different types of engineering teams at different levels of maturity. So I was wondering if you could talk a bit about kind of RWX in the context of identifying bottlenecks and how, you know, it could be applied to actually tackling those and how an organization or engineering team might go about it.

Yeah, I think there's a big narrative around this now, Rich. You see even Anthropic posting about CI volume increasing, Datadog, just published a blog post where they had to restructure their Git servers because every CI run was pulling so much code from Git, you know, that it was placing too much load on their Git server. Companies like linear, you know, had been focusing on CI because before the limiting factor in progress used to be the time that would take to write the code. You know, the main thing that took a while to make progress to evolve a product, execute on a roadmap, was the time that took the engineers to write. write the code. And as you look at that, there were a lot of practices based on the fact that code was

expensive to write. Even product requirements document and like roadmap planning and sprint planning was really all about trying to make sure that you were using your engineering capacity wisely because you were so constrained in that engineering capacity. And when you have finite capacity and code is really expensive to write, it makes sense to have a whole set of practices, you know, to try to make sure that that time is spent proficiently. But now, you know, code is, it's no longer expensive to write. Maybe some people are, you know, looking at their token bills and might disagree with me. But, you know, compared to what it was before, you know, code is cheap.

It's free. It's plentiful. You can implement the same feature 10 different ways, you know, at very minimal cost. And I think that really warrants, you know, rethinking what the bottleneck is and rethinking what the limiting factor is to shipping. And the reason that we're so excited to be focused on CI in this world is because the denominator is so different than it was before. You know, a 10-minute CI run after three hours of writing code, you know, felt pretty

reasonable. A 10-minute CI run after an agent Craig Dian change in five minutes is two-thirds of your cycle time. So, you know, we're really excited by the techniques that we've put into place that, you know, allow engineering teams to validate the code change really quickly so that the bottleneck can move from writing the code to validate. to validating the code, we alleviate that. And it's really just about, you know,

getting those changes out, user testing, customer validation and shortening the distance from idea to delivery. To build on that and or just to dive a bit deeper, I'm so interested in like how, like what kind of level of maturity are most of your kind of users at and what kind of level of maturity do you think is needed? I mean, I'm thinking mainly about sort of running agents maybe like in production or kind of working with production code. Like how, yeah, to what extent is that, yeah, like how much kind of support and kind of education do you need to give or how much are kind of people coming to you and saying, hey, we're ready for this.

We kind of, we're set up. Can you help us do more? I think an exciting aspect of RWX is that it fits in with the traditional model while really enabling engineering organizations. to evolve their practices. So RWX, you know, I've been talking a bunch on the show about the CLI approach and how a CLI first approach makes, you know, so much more sense in an agentic world. But RWX also can run on a poor request trigger. And it reports status checks in just like another platform does. So I think the exciting thing is, you know, it's easy to move over, kind of keep the processes

and practice you have today, but then gradually start evolving them, you know, to leverage sandboxes, leverage, you know, agent-first development and reorient your workflows towards agentric development. So we find ourselves, you know, working with a lot of engineering teams. You know, we tend to work with kind of bigger, more mature engineering teams, you know, the 50, 100, 200, 300-person engineering orgs that have been around for a long time that, you know, take the reliability of their software very seriously, where the reliability of their software is, you know, paramount to, you know, their business and their customers. And, you know, working with them.

And, you know, those organizations obviously have to be pretty thoughtful about the changes that they're making and, you know, how that does impact the quality of the product that they're delivering. But I think, you know, what we're really excited about is hearing reports of, you know, those companies, you know, shipping faster on RWX. Honeycomb wrote a blog post about their AI First strategy and published some metrics around the switch to RWX. and almost instantly they were shipping twice as much, with builds that were running twice as fast when they compared the metrics before and after moving to RWX. Cool, that sounds really interesting, and I'm sure we can link that article somewhere.

I wanted to also ask about kind of related to that, like what are the qualities or things that kind of organizations and teams that are doing this well are doing, or kind of relatedly, what advice do you give teams? that want to go through this transition and start doing this more? The key thing for me is really, just from what I've seen, across organizations that seem to be the most effective, you know, compared to others that are maybe still struggling to figure out

what their practices are, is to have a lot of confidence in a CI pipeline for shipping. You know, it's to get to a point where you feel like the validation that you're running on top of code changes is, comprehensive enough that, you know, if that validation passes, you feel confident with that code change going out to production. I think, you know, even before AI, I feel like, you know, we kind of knew as an industry that, you know, continuous deployment, you know, was the way for engineering teams to move and ship the fastest. And some organizations weren't necessarily even all the way there before AI. And I think now, if anything, it's just even more important to actually get to that point. And then I think the other one is really trying to reconsider practices as a whole.

An example that I'll come back to is just the practice of fixing build failures. It used to be the case in the way that engineering teams worked that you'd push code up to GitHub. A CI run would kick off. Something would fail. An engineer would maybe get a notification. They'd have to go see what failed. They'd have to go fix the test by hand. And you still can run that workflow.

And I see a lot of engineering teams being like, oh, well, How do we automate it so that if we push broken code, maybe have an agent go and fix it instead of an engineer having to go and fix it. Maybe we can just automate all of that. But you don't really have to work that way anymore. You don't have to have an agent push broken code to GitHub and then have another agent go and realize that something broke and go fix it. You can just have your agents, run the pipelines, use an interface like RWX to utilize distributed compute from that agent directly to validate changes before you've even opened up. your PR. And I think just more broadly, you know, the way that we work and the way that we build software, we really need to rethink about it from first principles, from the mindset that code is

no longer expensive to write. Maybe just one of the like anecdote that I'll highlight here is, I feel like before AI, there were some moments in my career where we had two different engineers solve the same problem. Sometimes that was intentionally, you know, there was like some debate about the right way to do things and we're like, okay, let's go and implement this couple different ways and see which ones we like. Sometimes it was honestly accidental that just two people kind of picked up the same thing, didn't realize it, and ended up working on the same problem. And I always found that really fascinating because you'd see, you know, two approaches that were perhaps both equally valid, but, you know, took different approaches, had different tradeoffs.

And, you know, always kind of amazed me just the wide variety of ways that a specific problem could be solved, even within like an established code base that kind of had, you know, fairly high standards and conventions around the way software is written. And I always love being able to compare the variety of solutions. And this is something that I think we're not doing enough of now. I think, you know, some of the best engineering teams I see now are, are having multiple agents. You know, I talked to a lot of engineering teams that they're using Claude or they're using Codex. But I think a lot of the fastest moving ones are using both. And they're just kind of constantly comparing and calibrating, hey, which model is actually best within our code base?

You know, which model is actually best with the agents.md that we've specified and how much does that actually, you know, get to a result that is the best thing to produce? I think a lot of engineers are still kind of, you know, guiding the agent a lot and, you know, maybe even like providing that expertise, like putting in the prompt or reviewing the code and telling the agent what to do differently. And I think the most effective engineers are the ones are trying to figure out, well, how do we get it so that the agent doesn't need guidance? How do we get it so that we're not course correcting what the agent got wrong? And we just have a sufficient agent's dot MD or a sufficient set of skills.

Agents understand the conventions and the constraints of our system and can just get things right, you know, right off the initial prompt. So it really does, I think, require rethinking the entire SDLC for the idea, you know, that code is very cheap to write. and we can, you know, explore problems in a lot of different ways. We can use different models. And, you know, those are things that before we just never really occurred to us to do or would have been too expensive to do that are very accessible and approachable now.

You mentioned kind of, you know, developers getting the agent to do kind of what we want it to do. And you mentioned a talked earlier about feedback loops, which kind of brings me to something I think I've spoken about with other people. and I know we talked about it before recording, just around like harness engineering and CICD. So what's the relationship between the two and like where does one end and one begin? How are they kind of, how do they impact one another? Like what CICD's role in terms of thinking about harness too? I think harness engineering is obviously evolving really quickly.

And it is really interesting because it is just an extra variable. and what the agentic experience is like. This is especially tough from the perspective of a CI platform that is working hard to provide a great developer experience across a variety of models and harnesses that different engineering teams are using. But sometimes, like, the system prompts are different, the tool calls are different.

One of the techniques that's been the most effective for us at RWX for agents understanding how to use a platform proficiently, is just the way that we expose our documentation to agents. When AI was first coming out, I actually thought we might have been in trouble just because we were like too new to be in the training data set. You know, RWX is kind of new and small as AI models were being released. And it's like, oh, shoot, like we're, you know, we're too new to be in the training data. Agents aren't going to understand how to use our platform. They are going to understand how to use the platforms that have been around for a long time.

Is it even going to be possible to have a new entrant into this space? But obviously, you know, the models and the harnesses, you know, have realized that things are continuing to change. It's not just the initial training data that informs what the model will do. You know, there's all these tool calls that the agents have available, you know, to go and, like, learn how to do new things, to look up information and respond to that. So we put effort into exposing our documentation, you know, directly to agents via RCL. And this is really fascinating because, you know, it used to be the case when building a product. You'd always look at feedback and analytics to try to make your product better. And I felt like documentation searches were always like a great source of insight.

You know, you could look into what people were searching your documentation for to maybe get a little bit of passive insight and know what they're confused about. Well, now, like 95% of our documentation searches are from coding agents. However, like the same principle still applies because we almost get this insight now to like, what are the agents getting confused about? Because our documentation search is also exposed via the CLI. Agents can run RWX doc search, you know, whatever term they want to get the relevant documentation. And now we just have all these analytics around like, oh, it looks like the agents are really getting confused about this. Maybe we should try to, you know, rewrite this docs page so that the agents understand what to do better. So it's kind of funny because some of those principles are still the same.

even though, you know, it's happening in a much different way. But coming back to the question that you asked around the harness, you know, I do think this is a challenge because different harnesses will invoke tool calls differently. One thing that we see a lot is different harnesses will start truncating output differently. And that makes sense because they're also trying to balance a context window. And they're, you know, increasingly kind of cautious about running CLI commands and just ingesting all that output into the CLI in case for some reason the CLA just spew. like a bunch of output. But of course, if the agent is going to start truncating that output, you know, you really kind of have to know, is it going to grab the first few lines, the last few lines, how many lines is it going to grab? Like, where do we put the relevant

information to make sure the agent will pick it up? And then you also have to build like a really robust e-vow framework around that so that you can test not only the different models, but also the different harnesses that agents are running. So we've really tried to focus providing like a standard, you know, set of capabilities, regardless of the harness, the agent is going to figure it out. I think, you know, some harnesses go a little bit further than others in terms of being prescriptive with the agents and what they should do to validate their changes.

At first, I thought some of those harnesses were overreaching. But increasingly, I do think it makes sense because, you know, they've spent the effort in figuring out those system prompts to, you know, help the agent understand what to do. And I do think most software projects follow a pretty standard workflow, just like what we were talking about earlier, Rich around like the interloop and outer loop of validation.

But I think we're not all the way there yet. I mean, obviously this area of agentic development hasn't like fully matured and understanding, you know, what should the harness do on its own? What assumptions should it make? You know, what should people have to specify about their co-base and their project to get agents to be effective? I think a lot of people have a lot of croft in their agents dot MD now where, you know, the harness and the model would just be able to figure things out,

you know, without the degree of guidance that maybe some engineering teams had to put in there with earlier model generations. And, you know, probably the most important thing is we almost just have to start over every, it feels like every few months, you know, probably, you know, delete the tooling, delete the orchestration, try different harnesses to understand what's working. And probably for some engineering teams, try to standardize a little bit on just understanding, you know, which harness is the most effective. I do think a lot of harnesses are going to reach a little bit further into CI and have the understanding that tests are going to need to be run,

pipelines are going to need to be validated, and they're going to try to do a little bit more to make sure that happens without an engineer having to prompt for it and ask for it. And I'm really excited to see how this continues to evolve. I guess also just to kind of touch on something you said that I feel is quite interesting, but I haven't really thought of before, but I guess there's a kind of question around, you know, what you treat as, I don't know, disposable or like what can you get rid of, what darlings can you kill, and, you know, what you kind of retain

and sort of coalesce around, I guess. Like, I don't know, that feels like quite a pertinent and important challenge at the moment. Yeah, oh, absolutely. And I think one interesting thing about software development is I actually think this has always been relevant. Like one thing I noticed when leading engineering organizations before AI, is that like developer experience and the tools that engineers would use would sometimes inform their opinions on aspects of the code. You know, for example, if you were very proficient with your editor, you probably want to be as concerned about a little bit of duplication, especially like structural duplication across a code base, because if you ever needed to make changes to that, if you were very proficient

with your coding editor, you know, you just wouldn't worry about that as much because you possess the skills to make those changes. Whereas somebody who is less proficient would prefer, you know, a little bit less duplication, more abstraction because, you know, they want like an easier way to make certain code changes. Same things around like silly little things around like, you know, automatically declaring imports and versus having to write those statements by hand. And I feel like those editor capabilities actually informed a lot of opinions with writing

code. And I actually think that's still going to be true. I think, you know, the harnesses and the things that they're doing, you know, for people is going to inform a lot of opinions about, like, what needs to be done to work with AI. And I actually think it's going to be challenging for some bigger engineering teams that have a variety of harnesses and use across their team. You know, it's always been a great thing to let engineers use the tools that they're more comfortable with. But I think there's enough variance in these right now that it's going to be pretty tough for engineering teams that don't try to standardize on like the harness that's used across their entire engineering org.

Yeah, it's interesting you mentioned that. I did have a question. I wasn't sure whether to ask it about, you know, whether we're sort of just retreading kind of everything we talked about platform engineering, I don't know, three, four, five years ago. Yeah, what's your kind of take on that? Yeah, it does feel very similar, doesn't it? I think, you know, platform engineering really emerged as, you know, I feel like a maturing

of just a developer tools type team, you know, an engineering productivity team, you know, a subset of the engineering org that was, you know, really trying to make it productive to work on, you know, projects and repos across an entire organization. And I think, you know, there was some great work that came out of that space. But I think some of the lessons were maybe similar to the lessons in DevOps. So just like when, you know, there was an infrastructure team that was responsible for like production and deployments, but you had all these different engineers that were shipping all these different applications. And, you know, maybe that infra team, you know, didn't know much about like, you know,

the nuance of how that system was operating in production. I think we learned that it was really hard to separate those responsibilities. And I think consequently then, you know, it was actually a pretty big challenge. or platform engineering team to be able to provide, you know, the right tools to enable an engineering org to work across the different languages and runtimes and code bases, you know, that they wanted to put into production. So I feel like there's always some tension between standardization versus every project reinventing the wheel. And it's a tough balance to get right, but I think one that's worth exploring. And one that's worth exploring, you know, with, I've always

like the phrase in software engineering strong opinions weekly held across how some of this is done. So I think we might be back to needing some sort of platform type engineering team that is trying to figure out how to make different harnesses and different models work really effectively for an organization. But I think we have to take some of those lessons that we learned and really also make sure that there is adequate leeway provided to the engineers that are the ones who are directly working on the code base to figure out how to, you know, evolve those tools so that they can, you know, get the most productive results as they can from their agentic development processes. I also wanted to, well, kind of just as we kind of come towards the close, talk to you a little bit

about some of the successes, and you've already mentioned Honeycomb, but yeah, and I wanted to ask you about kind of any wins that you've all kind of users have found with RWX. And then a kind of associated question that is maybe more interesting, actually, but just around kind of measuring success, like how you do that or how teams do that using RWX, different ways of doing that as well. Yeah, I wanted to get your view on that. Yeah, I think this is an area of software engineering that is really challenging. And there's a whole set of companies that specialize in justice, just like surfacing metrics from an engineering process to help engineering leaders understand if they're doing better. But I think there's that one quote. Like, you know, as soon as you start measuring something, it stops being a useful metric, you know, that one.

And that gets tricky. You know, you start measuring PR ship per day. And now all of a sudden, I don't know, something happens where you're shipping a ton of small people. and that metric is going up, but you're not necessarily delivering more value. And I think there is some inherent truth that just like the value of the work that we're doing is so hard to measure that sometimes we can't really get it quantified to the degree that we want. But there are things that we can quantify and that obviously come up a lot with continuous integration. The two primary ones, of course, are just speed and cost.

And that's always a really relevant metric in this space. Sometimes I think those metrics overlook, like the developer experience aspect. And even now, like the agentic experience aspect, because I feel like it's not just about sheer speed. Pipelines do. They always run faster on RWX. They always run more cost efficiently. But I feel like it's some of the second order benefits of that that are the most impactful. You know, it's like the benefit that if a PR is fully up to date, then when you merge it into Maine, even if you have CI configured to run again on Maine, CI is going to go green instantly because that exact code change was just validated on the PR.

And that's something that doesn't happen in other platforms, but does happen on RWX. I think similarly, you know, the fact that that critical bug fix just gets out to production so much faster, maybe matters more than, you know, just the average runtime of every build, you know, as a whole. So over 90% of the engineering teams that have evaluated RWX has moved forward. And it is because everything runs faster and it does cost them less. We didn't really talk about graph-based execution, but it's an incredible technique to just run pipelines with far more efficiency than the old like job and VM-based abstraction that most CI is structured on.

because with graph-based execution, every step only needs to run once, regardless of how wide you're fanning out. So, like I mentioned that Datadog blog post earlier where they had to retool Git because they were running, you know, 100 parallel CI jobs that were all cloning down the code. On RWX with graph-based execution,

that doesn't happen. Only one VM has to clone the code, and then you can fan out to 100 without each of those 100 VMs having to run the exact same thing over and over again. But anyway, I think it's not just about the speed and cost. It's also about the fact, that you just get so much more mileage out of the platform.

There's always kind of that threshold that might kick in where it's just too many tests, there's too much validation to run on top of every single code change. And now you have to start maybe selectively running tests or deferring some validation to like a later stage, and then you're starting to slow down your feedback loops. But RWX just gives engineering teams so much more mileage. And when they do need optimizations,

the optimizations are so much easier to achieve that it makes a really meaningful contribution to just accelerating a team's delivery as a whole. And that's, again, what is led towards over 90% of the engineering teams who have evaluated RWX moving forward with it. Cool. So, Dan, I don't want to take up too much more of your time, but I have a couple more questions just before we do properly close out.

And I'm curious, like, what does, and I know we're not at the end of the year yet, but what does kind of 2027 look like, I mean, both for RWX, but also more broadly, what are you kind of excited for or kind of watching and think other people should be looking out for over the next six to 12 months in the software industry? I think the thing that I'm most excited about is that shifts in technology like this really kind of reset the playing field. It creates the opportunity for people to come in and create new novel solutions based on the new way of working. You know, it's not like it's possible for anybody to have 10 years of experience of, you know, AI harness engineering.

You know, it's kind of like just a greenfield opportunity to go and create new companies and new solutions and new ways of working. And I love that. You know, I love that the playing field has been reset and there's just an opportunity to reevaluate everything that we're doing. For us at RWX, you know, we view, you know, the bottleneck has moved to code validation because it's no longer writing the code, you know, we're making significant progress and alleviating that bottleneck. And we're going to stay focused there. But there's always more, you know, that we've thought about doing, especially as I think, you know, we're still early in making this shift. I think we're still living in a world where we're mostly, largely, except for, you know, having AI write the code, kind of working similar to how we've

worked before. And I think more evolution is going to happen. And, you know, we're constantly talking about ideas for the ways to make a biggest impact, you know, through that shift, trying to see where things are headed. And, you know, given the core capabilities that we've developed, ways that we might be able to utilize those to make an even bigger impact for engineering orgs. Dan Mangus, thank you very much for joining me on the show. Appreciate your time. And just before we do finish up, is there anything else you'd like to promote or kind of, where can people find out more about our RWX or maybe learn a bit more about you.

Yeah, thanks, Rich. Thanks for having me on the show. It's really fun to chat about all of this. You can find out more about RWX. We're just RWX.com. We're RWX on Twitter. Anybody who signs up, there's $100 free credit so you can just try to platform.

And for any bigger engineering orgs, there's a link on the website to book time with an engineer. This is what we do day in and day out. We just work with really thoughtful engineering teams, to help them evolve their processes for like agentic engineering. And we get a lot of satisfaction about just seeing how enthusiastic engineering teams are to, you know, improve this part of their developer tooling. So there's actually a link on the website to meet with an engineer.

You know, we'd love to chat with anybody that's working on these problems inside their organization. Cool. Thank you very much. But yeah, thank you, Dan Mangus again for joining us. I've been rich. Yeah, thank you for listening as well. or watching if you're watching. Appreciate your time and see you next time. Thank you.