The Infra Pod - Bazel and the Next Wave of AI Developer Infrastructure (Chat with Alex Eagle from Aspect Build)

Episode Date: November 17, 2025

Welcome to Episode 53 of The Infra Pod! Hosts Tim from Essence and Ian from Keycard are joined by special guest Alex Eagle, CEO and co-founder of Aspect Build. In this episode, Alex shares his journey from working on Angular at Google to founding a company around Bazel, Google's open-source build tool. The conversation dives deep into the challenges and motivations behind building developer infrastructure, the evolution of CI/CD systems, and the unique strengths and hurdles of adopting Bazel in organizations of all sizes.The trio explores the future of software development, the impact of AI on coding and build systems, and the ongoing debate between monorepos and polyrepos. Alex also discusses Aspect's mission to make Bazel more accessible and the broader implications for developer productivity in an agentic, AI-driven world. Whether you're a platform engineer, open-source enthusiast, or just curious about the future of build tools, this episode is packed with insights and spicy predictions for the future of developer infrastructure.00:00 – Introduction & Guest BackgroundTim and Ian introduce Alex Eagle, who shares his journey from Google to founding Aspect Build.04:20 – Why Bazel?Alex explains the motivation behind focusing on Bazel, its challenges, and the analogy to municipal infrastructure.10:55 – Bazel in the Real WorldDiscussion on Bazel’s adoption, who should use it, and the hurdles organizations face.21:06 – The Future: AI, Agents, and Build SystemsExploring how AI and agentic coding are changing developer infrastructure and Bazel’s evolving role.43:01 – Closing & TakeawaysFinal thoughts, how to learn more about Aspect and Bazel, and episode wrap-up.

Welcome back to the InfraPod. This is InfraBescence, and Ian, let's go. Hey, this is Ian working on making sure you've got secure agents and can get into the agentic future at KeyCard. I'm super excited today that you joined by Alex Eagle, one of the founders, and I believe the CEO of Aspect.bilt. Alex, it's great to have you what got you motivated to actually start a company around Basel.

Tell us everything, tell us all. Oh, I'm excited to tell you guys. everything. Thanks for having me on. And yeah, I mean, I'm happy to tell that story. Is that where you want to start? Sounds like the answer is yes. Yeah. We always love to start with, okay, building companies is hard. It's a crazy idea. What actually convinces people to get over the line and like do it versus kind of thinking about it. Yeah. So I'd love to hear yours. Yeah. I mean, I guess my origin story here is that I've been pretty obsessed with open source forever. worked at Google from 2008 to 2020, and probably the awesomest experience I had there was working

on the Angular team, got to go to our conference and speak to 1,500 people in a giant room, 1.5 million developers using our stuff. And really, Angular was sort of an exception to how Google does open source projects. Like, it was staffed as a skunk works. Like, it was never actually given headcount. And development happened on GitHub first and then, like, imported into Google's internal mono repo, which is like the reverse of most of the projects there. And that was the kind of experience I always wanted to have in tech. Basel is Google's build tool. And so really the way I got into starting a company was that that project does not run the same way as Angular. And it wasn't as successful out in the world as I wanted it to be. And so I wasn't really looking to be an

entrepreneur. I just had this vision and nobody else was solving it. Right. I'm like, okay, well, I guess like, I'm going to go solve this thing. Google doesn't, doesn't have the kind of posture for open source that let somebody, like, really jump on a project like that and drive it. And I think companies changed over the last few years, maybe even more in that direction. So, yeah, I just, I just had this vision and had to chase it. I love it. And was there some, like, moment where, like, oh, yeah, Basil's the thing? Like, what was the, what was the defining moment where you sort of saw it or experienced

you had that got you over the line? Because working on continuous integration and build infrastructure is an esoteric but important mission. And so I'm just really curious to sort of understand what you know. I think there's a particular personality type that draws people to this, which I liken to municipal water supply and sewer engineering, where you're maintaining this infrastructure for a giant city of people and they just flush the toilet and turn on the tap and like they don't care why that works. They're very mad if it doesn't work. And like what kind of person is like really working behind the scenes literally with other people's

poop? That's kind of how it feels like in developer infrastructure some of the time. Basel is the open source version of Google's built system. They call it Blaze internally, and anybody who's worked at Google will say, like, wow, this piece of software is incredibly well-engineered and maybe incredibly complicated and definitely a key to how Google does development. And so, I, you know, just combining my love for open source and the fact that, like, solving engineers works. Gotcha. And, you know, I think when we take a step back and we kind of think about. building anything, like it's a development, like what motivates us. You know, I started keycard because I had been thinking about machine identity

and how I was tired of copying secrets around. And just something about when I, like, 12 years ago when we first started adopting cloud software that like really, really bothered me. And it's been sort of an inch I wanted to scratch for a long time. Like, what is it about Basel specifically that you were like, okay, there's a company opportunity here. Like there's an opportunity to build a company or actually there has to be a company. And if there is a company, it's going to like funnily change things for people.

or Creight net good or whatever it is. And like, these are the water pipes people should have versus, like, other water pipes or other types of, like, electrical equipment to try and play on your analogy of, which is very good, by the way. Yeah, actually, I was at my kid's soccer game and I met somebody who actually is a municipal plumber, so to speak,

and said that, oh, actually, yeah, people who work here are really intransigent. Like, we don't, or I guess I should say, Rekal's a trend. Like, they don't follow authority necessarily. And, like, if they have to shut down your street to fix your sewer and you're mad at them, they just don't care. So the reason that I saw for doing this, and there's the reason that I

understand today for doing this. And I guess to carry the narrative, I should start with the first one. So like how our company got started, we bootstrapped, we didn't take VC money to begin with. We had a bunch of consulting clients who needed help. We saw that Basil was being adopted pretty widely, but it was too difficult. So like the beginning of the business model was sort of a tongue-in-cheek. You've probably heard this phrase, give away the poison and sell the antidote, as one of the ways that open source works. Like, oh, like, you know, we intentionally made it not that good, so you'd be forced to pay us for support, which I would never do intentionally,

but it so happened that Google had given away the poison, right? And so, like, we could sell the antidote for somebody else's open source. And since Google didn't want to staff any sort of professional services or support or even, like, really Devrel in the long term around the project, like that was an obvious place that we could start. And so we managed to bootstrap for a couple years just doing that. And basically, in our 20% time, we were like, hey, do you know what? A lot of the stuff we're building for our consulting customers, everybody else in the world needs.

It can be productized. We can create terraform that stands up this infrastructure. We can create utility programs and wrappers that fix the issues that we know about. And we can contribute back to open source in a giant way in the Basel ecosystem to fix things that are missing. And so we ended up sort of following a number of the open source business models to make that a reality. and get the company to the point where we are today, which is like a lot of it is actually, majority of the revenue comes from the SaaS product.

And I think the opportunity that we still see for build systems is huge. Interesting. There's lots of different approaches to CICD. You know, what problem was Basel design to solve, broadly speaking? And why was it uniquely built at Google? And what was Google trying to optimize for? And where do people find success with it? And where don't they?

That's a broad question, but, like, I think it's also a question of, like, Basil's pretty well known. I think anyone who's played around with any Google open source projects has run across to it at some point in their life, and many open source projects. But what was it the true intention of its design and why was it required? And then what makes it difficult? Yeah, I think there's a diagram I've seen go across on LinkedIn from thought leaders in like the platform engineering and developer infrastructure space that's like,

here's all the things you're going to need to pick, right? It's like, okay, what database are you going to use? And what are you going to use for version control? And there's almost never on that diagram a box that says, what are you going to use as your build and test system? We think about CICD as, you know, you set up Jenkins or GitHub actions and you're like, okay, I'm going to trigger whenever somebody makes a change. And then there's a box that where you type in, what command do you want to run every time, right? And you just type in, oh, well, like, I don't know, the command is pie test or it's Python dash M pie test or it's my shell script that wraps a couple of things. And you don't really think about the fact that the CICD system actually has very little to do.

with the execution of the build and test and how fast it can be, right? So this, like, CI systems will say, oh, well, you can shard your build or you can avoid running part of your build if you didn't touch files in that folder, but that's all kind of a manual step that you do, and it's definitely not correct. And so it becomes really hard to rely on your CICD. The more you're adding these sort of performance tweaks, the less you are getting the guarantee of, like, green main means everything is good. So Basel is a replacement for the idiomatic build and test system or framework or just a library that came with whatever you did when you started your projects.

You're like, oh, I'm going to run the React Create app or I'm going to get started with a new Go program and I'm just going to run Go Build because that's what the documentation says to do. Works great at small scale. And then as you get to bigger scale, like nobody's prescriptive about what you should do when those tools aren't good enough anymore. every engineer has work in industry we all heard of basel but to be really honest i never actually even tried basil because it's just like you know is it even worse trying like i heard it's faster it's way powerful but it would take you maybe a pH to do it so you know this sort of like so damn hard to even like get going is very notoriously there and i've you know CI is one of those last things like if you just want to flush your toy i really want to go buy like a fancy toy that needs like a

PhD to set it up or a toy that just seems to work and doesn't seem to bother too too much. And you have this like very weird sentiment around it. I think as we go to work, I worked at larger places and smaller places. I feel like this sort of like we should really just like go try basil has always kind of came up, especially at larger places for me. But then who's actually volunteering to actually go use it? No one. So we end up stuck in this like death loop of like, okay, nobody's ever dare to try it.

maybe talk about like your experiences working with other companies because Google of course they built it they adopted it but what is the main motivation for them to get over the line to even use it and maybe even give us a summary like what has been like the hardest forever for some reason that people just just don't even want to bother trying it and you're trying to help them yeah there's a bunch to talk about there so I think part of it is reputation and so I'm glad to come on the podcast because partly I was sitting at the Oakland Airport listening to Ian Noland from your episode back in February, who was talking about platform engineering, and sort of, I heard him say two different things on that show.

One of them was that developer infrastructure, you don't want to go with something complicated, and he mentioned Basil by name. You can let teams kind of be fragmented and pick different things that are simple because maybe their problems don't necessitate somebody coming in with a complicated tool. But then when you're talking about platform engineering, it's, oh, well, that should be a centralized function because if every team picks their own, like, you know, production stats, then there's no way we're going to have the economy of scale of being able to monitor that whole thing and provide good uptime guarantees.

So I had to come on and try to rebut that a little bit. It's definitely true that Basel is hard, right? And I'm trying desperately to both fix the inherent things in Basel core and also provide the last mile developer experience that's always been kind of missing. So anybody who wants to give it a try, I encourage you to check out a GitHub org called Basil hyphen starters, where I've been putting repos. And you can basically pick your language. because one of the reasons Basil seems hard is just like, oh, I have to do all languages at once.

Like, no, that's not true. And it doesn't have to be incredibly different from what you're used to doing. Like, it can run the tools you're used to. And so, like, in that Basel Starter or each of those repos tries to be less of an edit distance from what you're used to doing today. As you observed, Tim, like at bigger companies, it's more obvious that you have a need for something like this, right? And it's also more obvious that you can afford to staff a couple of people who maybe don't need to be experts at developer infrastructure, but at least need to be specialized. in it because there is more stuff to read than anybody would want to do if they're just sort of hobying for the rest of their team, getting the build system set up. But I think that

small number of people can have a huge impact. So you ask, like, what kind of companies do you see doing this? Well, there's three kinds. There's, like, the big ones who have the problem, and Basel's really the only solution they can find. There's the ones where ex-googlers went, and they're like, well, I know what this looks like when it's good. And so I just want that from the beginning. And then I think there's this growing third class of users that are aware that it's hard to do a migration like this later and they want to get on top of it today. And as Basel gets easier, I think that's the group that's going to grow the most. And so it'd be great to understand where Basel is really strong. Like what type of projects and workflows is Basil really strong today and

where is it weak? And to help people understand sort of like, hey, I've got a problem in shape that looks like X, like I should use basal. Or, oh, I have this problem. Maybe not worth it. Like, maybe not worth it. Because I think going back to sort of like what Ian Nolan was saying, I think this is true. There's always this like, I mean, every organization has this giant tension. I think between like decentralization and centralization of functionality and you kind of go through these like the pendulum swings as companies go through maturity cycles where like, you know, everyone sprawls out and becomes a mess. So then you create like a platform function and things start to centralize again. And then you realize, oh,

actually the centralization is now the bottlenecks, then you, like, you inverse it. So, like, now the platform's, like, now it's about enabling and offshoring it back to the teams. You kind of, like, go through these, like, growth cycles. And oftentimes, if you don't time those gross cycles properly with the right investment, you end up with, like, projects that aren't successful. Like, I'm in his, I think it's probably the nuance he might provide. Or, you know, maybe he would just be like, absolutely not.

Basil's terrible. And I'd love to have him to come on and have that conversation with you. But I'm curious. Like, where do you think Basil, like, yeah, you should absolutely use it today. This makes a total sense. you're going to save yourself tons of time and tons of pain. Because I definitely, like, remember the days before Basel when, like, you go to a giant C or C++ or Java project or something that has a shit ton of dependencies,

if you go read the 17,000 make files and different thousands of lines of code, and you're like, I have no idea how this thing works. And it's broken, and it doesn't cash properly, and it's all different. And it only works on one developer's computer. And we certainly can't push it out across, like, a giant build system. And then you had to hold build engineering team that, like, was responsible for maintaining this, like, brittle mess. So, yeah, kind of curious to understand where the state of the state of the world today for Basel, where it's really strong and what use cases it's like ready for today.

Yeah. I think there's a few, like, if you have this experience today at work, this might be the day to take a look at Basel, right? One of them is, like you said, that the giant pile of make scripts is brittle. And so I mentioned earlier, like, a volunteer spending part of their time to keep the build info working for their team. that person is not only fixing the thing, but then they're getting a Slack message from their co-worker who's like, hey, I can't get any work done today because all of a sudden, when I run the test,

I get this crazy stack trace that's coming from some tool I've never heard of that's way deep in the plumbing and it's scary. So reliability of developer workflows, like, you know, if GitHub is down, all of us, like, you know, go out and have a coffee or a beer, depending on what time of day, it's down. Like, you can't have outages of your developer infrastructure, right?

And, like, reproducibility is a little bit of that because not only is your thing broken, but like you get the wrong result. You're like, hey, it's red for me, but it's green on CI. Why is that? Oh, well, like, so there's something about your machine that's not right. So that's one thing is like the build feels not reproducible. You know, build systems people will use the word hermiticity for this, which is like the build system knows everything.

It doesn't matter, like, what your machine looks like. Sometimes I even describe this in security terms, if I'm talking to security company. It's almost like your engineers are attackers trying to figure out what weird thing they can do to their computer so that your build stops working. right and if you think about it in that mindset you're like okay well if it's an attacker like i'm going to cover all the surfaces that they could attack and make sure that the build is reliable for everybody another scenario that means maybe it's the day to look at basil is just growth and this is a boil the frog kind of thing where it's like oh the code base is so huge and the

number of engineers is so big but it just feels like we're not as productive as we were a year ago right and it's hard to see that sort of day over day or week over week but i think if you especially if you do developer satisfaction survey or if you have any hard metrics around developer productivity and you compare it to a year ago and, you know, our startup was great, but now we grew, we 10x and now everything feels slow. Build systems can be faster when they have a cache, right? And like, that's part of the journey of making my thing faster and also avoiding running tests. But the alternatives to Basel to make those things faster are just really not rigorous enough, right? And you end up just having to support it. A couple more is,

oh, we have multiple languages. Maybe you have an acquisition and now you're trying to fold in the acquisitions code and you're like, oh, well, they wrote everything in Perl. Like, what are we going to do? Rewrite it in Rust. Yay, we love rewriting everything in Rust. This is the, you know, it's 2025. Let's do it. Hey, I can rewrite it in Rust for me, except not exactly right. And then I think the last one to point out is production outages. So every time you have a SEV, something is wrong in production. And you're like, hey, do you know what? Like, this was an integration problem. It wasn't like our unit test would have caught this. We ran all the unit tests. But it's like, you know, in these bigger software systems, you have multiple teams,

making different assumptions. Maybe there's an API contract between the two things, but it just so happens that that wasn't strong enough to prevent mistakes. And I think when people talk about continuous integration, you have to question what they mean by integration. And for a lot of people, it's just continuous build. And then integration is something that happens later when you go to push to staging every two weeks or something.

And that's too late to find out things are broken. So Basil is also great for taking both a polyglot repo, but even just a large mono repo and making sure everybody can be writing integration tests that run the code from head, right? And this idea of live-at-head is really the thing that it enables. I'm kind of curious, you know, I think this is a conversation.

I literally started a company, I was literally having this conversation with one of our platform engineers we hired last week on monorepo versus multi-repo, why the industry went from monorepo. Like, if you go and look at, like, the large tech companies that came in the 2000s,

they are all basically have a giant per-force repository one way or the other, right, with everyone working off a per-force. And then no Git kind of comes along. It becomes really difficult to build large, mono repos on Git, but it gets like a significantly better pro like protocol and workflow for lots of different branching and stuff. And so it's lots of advantages over perforce. And also then we

kind of move towards service range architecture and everyone's like, ah, services all need to be in their own little like world. And so there'll be little repos independently deployable things. So like it's conceptually easier for the human to understand what the hell this thing is, right? Because that context kind of got lost in the movement. I'm curious how much overlap there is between people that find a lot of success with Basil and people that are also like doing mono repo paste deploy. And I'd love to get your view on this never-ending debate on mono versus multi-polyglot repository structure. I'm sure it's something that you actually spend a lot of time talking to your customers about. Yes.

Yeah. I've tried to stop using the word mono repo. I think the answer is poly repo. The answer is almost nobody is crazy as Google and wants to have to rewrite perforce on top of big table in order to make it scale big enough for the size of code that's in there. And also to your point, like a Git repo, is a unit of configuration of certain things. And partly that's not, that's GitHub's fault and not Git itself, right?

Like, permissions are on a repo and, like, notifications are per repo. So there are reasons to have more than one repo. Now, if you've chosen to do what I'll call monorepo or, like, you know, our company's really going to try to make everybody be in one place, then, yeah, you arrive at Basel because you've taken a tradeoff there. You've said, hey, we're going to have fewer governance issues. and like nobody has to figure out which repo they should contribute to, but we broke the ability to sort of, you know,

have the CI system test everything every time. And so we have to find a better built tool. But I think it's also the case that you can have multiple repos and still have this, you know, physical multiple Git repos, but logically one unified build over that set of repos. And that's still advantageous and Basil can still do that too. Let me also put it this way. I think not only is Mono the wrong word because,

Companies don't literally want to have one. But you've also got what I like to call the frozen veggies problem. Like my cousin hates eating vegetables, and it's because my aunt and uncle only know how to buy frozen vegetables and then, like, put them in the microwave for two minutes. And then, of course, it's terrible. And, like, if your experience with mono repos is with bad tooling, then, of course, you think mono repos are terrible.

And, like, part of the reason that Basil's been successful is that enough Googlers left and we're like, hey, do you know what? It can actually be great. So I think what we want to do is say, hey, there is a good experience for fewer repos, which is just to say, like you said, every time you make a new service, maybe co-located with a service

that already has excellent developer productivity and ergonomics built into that repo. But there's also cases where you decide to be in a separate repo and that should be allowed too. Interesting. Yeah, I feel like mono repo, even basal, a lot of these sort of like either concepts or technology has been so interesting that I feel like the industry

has been sort of keep continuously trying to figure out what is next, right? Like, obviously we've seen how containers took over, now AI is taking over. It sort of like kind of submerges one and another. And given that you're still knee deep into sort of like CI business and getting everyone's build stuff, I'm very curious about like what your thoughts now. Is there any shift at all right now with way or people building software at all? Or just do you see Basil becoming a bigger need? Or we're sort of just on a continuous trend of like, oh, there's just more co-developers are so just doing stuff.

And people are just looking for more ways to get faster and easier builds. Because that's the Basel's sort of like reputation is faster, right? Faster, cheaper and more correct. Yeah. And 2025, it's almost like very hard to kind of tell like why is Babel even more relevant, you know? And so I'm just wondering like what you're seeing today. Like is Basil becoming even more relevant for what reasons? Yeah.

So you asked, are people changing the way? they write code. And partly the answer is product engineers are writing the code that they need to write to ship the product, right? And so autonomous vehicles is a good example where there's a lot of C++ and Rust, there's a lot of cross compilation to embedded systems, but there's also a lot of machine learning involved for being able to like navigate in an environment. And it's like part of the answer is like, well, I'm just running compilers. And for my customers, like, I don't really need to know what your software does once it's running. Like I'm shifted left, you know, like once continuous delivery occurs, it's out of my hands. But I think the other part of the answer in

2025 is obviously AI. AI is writing tons of code. It's also proposing tons of changes and making it easier for developers to create changes, which increases the load on CI, on the build systems. It also increases our reliance on tests to catch things because none of us is super careful at reviewing what the AI writes. You know, like, I remember the first time I used like cursor or windsurf. It's like, oh, wow, let me read what it wrote because that's fascinating that can write code. And then by the fifth time, you're like, okay, well, I ran the app and it seems to work. So check it in. And so I think that is where like just the scale of, like, the demand on infrastructure is increasing a lot because of those tools and because of the way

developers are now expecting to get really fast turnaround time, but also like you can have an agentic AI that's like working in 10 different branches at the same time on different problems. And you can't switch back and forth context locally like that. And so you're expecting to get fast enough feedback loops on CI that you don't have to context switch. Yeah. I think that's sort of AI making more code and sort of like the sort of newer sort of style of coding. What are you seeing now? Because I think, you know, when it's talk, think of Faisal, I would definitely think of more larger companies. And in my mind, larger companies are actually taking the longest time to adopt AI. Because it's, it's pretty new. Like getting sort of auto completion style of coding is obviously it's a little bit easier. But, you know, is AI making like 10% more productive right now at larger companies versus actually 2x, 3x? And is, it's obviously, people really stressing the sort of like the CI systems to like the no balance because we talked to like blacksmith founder on our pot and he was basically saying like hey this is going to be a five to 10x more activity and you know I feel like it's true but I don't know when and I don't know like how exactly it can happen is people just really just yoloing a lot more commits and pushing so much often or they're actually because code is so much more I guess easier to generate I actually still need to take a like pretty careful times to figure out what they're doing and I'm just curious like are you seeing like this sort of like increase happen in what kind of teams and how are they actually able to do that successfully at all? It's true. I guess that the formal adoption of AI in large

companies is slower than everyone wanted, right? And companies are saying like, hey, we should make our engineers more productive by giving them these tools. And then I read some research like from the Dora community that, well, actually, sometimes it makes them less productive for various factors, right? And you could, I'm not the right person to even get into those details with. I think the key is that the most compelling case I've seen, and maybe I'm biased as a more senior engineer, that like the AI can do the easy parts, right? And it's like, okay, well, like, this is a task I've done before

and I can kind of describe the task to you. I can kind of tell if you've done it the right way. And as an assistant, it's helping me to still be in the driver's seat, right? The most expensive thing and the thing that still holds back productivity is when the AI is letting me get code put together faster, but then I'm still waiting just as long to get feedback from the CI system. And I think it's easy for like a CIO to say, I'm going to sort of increase all my developers' productivity by 10 to 15%. And that's the same as hiring that many more engineers.

Now I don't have as much pressure on headcount. Now I can deliver more stuff with fewer people. But I don't think AI is the biggest unlock for making engineers to 10 to 15% more productive. It's super fast feedback loops so that they're always in the flow and they don't have to contact switch. I think that's true. A lot of the promise of like the move the cloud and a lot of what we did in that the last generation of tech, and adoption of developer tools and infrastructure was to enforce much faster feedback loops. It was to break waterfall and move towards agile.

And that led to the rise of things like CICD. It led to the rise of things like good automated testing harnesses and the ability to scale it and do testing, ability to scale it to do some of these build systems. So that started it. But also many organizations, I think, in the last, as those investments took much longer to like realize upside and became incredibly difficult for them to actually track. Like, it's hard to tie the investment to improve. improvement directly for many organizations.

There are some organizations in the world, like a Google and Co, that like can tie those investments directly to net positive productivity improvements, but it's not true for every organization. And certainly not every organization has the sophistication of like engine organization and company that can even understand what those cycles mean for them one way or the other. But it is interesting to think about, and I think about this a lot, is like the rise of agentic coding, the rise of these things, are going to. to require feedback loops, deterministic feedback loops, that are much faster than ever before.

And now there's such an opportunity for founders to go and find where are places or pieces of infrastructure that assume a relatively static, long-lived world, right? Something that's going to live for a long period of time, that's going to be relatively static, doesn't really change. And it's now going to have to be hyper-dynamic and hyper-ephemeral. Because the future of agents is paralyzed oat, hyper-femeral, spawns into existence, lives for a short period of time, iterates for a short period time inside a box, then dies off as sort of like the broader system tries to navigate going from zero to one on some task. I'm kind of curious to

understand what you think the future is there, but it would be also awesome to understand how you think what you're working on with aspects specifically, unless basal, but what you guys are working on aspect could kind of fit into that future as well. Yeah, that's a good prompt. I think agentic AI and just generally the ability to prototype and experience. is huge, right? And I think there's even a cautionary tale there not to invest in something like Basil. If you're just writing some throwaway stuff, you know, especially like you said, founders trying to try to get things running. If you're looking for product market fit, like it's not the time to invest in robustness and assume that the codebase will live for a long time. That's true.

The thing that experimentation gives you is a lot of greenfield opportunities to build a new thing. But in a microservice architecture, it's often the case that you want to experiment with some new go-to-market strategy for your company that involves the product appearing a slightly different way to consumers, but a lot of the logic and services that you're already operating can be reused by that thing. And so I think what continuous integration, like integration with like a capital I has to offer is the ability to do that kind of experimentation in one piece of the stack and still reuse a lot of the rest of this of what you've built, right? So making our systems more malleable without the productivity of living ahead and also the ability

to write integration tests, you end up with experiments that are on their own island, and it's really hard to then take them and ship something to customers, even if it's a pre-product market fit, like let's do an A-B experiment and see if customers like this new version, but it still needs to be reliable and work against a bunch of the rest of the parts of the stack you've already written. So, yeah, what are we doing at aspect? Well, there is making Basel easier, which I mentioned. And there's a little bit of this where I also have a community hat that I wear. We took the conference to the Linux Foundation. We took most of the Basel language plugins, which are called Rules, to the Linux Foundation.

Also working on starting a fiscal entity within Linux Foundation. So anybody listening, if you are at a company with an open source program office and you're using Basel, like please come and give us a hand to get enough initial members of that thing to get it off the ground. So that's on the community side. What we're doing as a company is to build all of the missing workflows around Basel. So that's CICD, obviously. But even CD is not that obvious. Like, we're doing continuous delivery, but what do you deliver?

You don't want to push, like, every container in the repo on every green commit to Maine. You want to figure out which ones to deliver. Well, which ones do, you should deliver the ones that are changed, which you can do based on the dependency graph, or you can do based on content address hashing, which is something Basil's kind of obsessed with. There's Merkel trees everywhere. It's like a fun computer science problem. And then Basil is involved in linting.

It should be involved as an expert code review. of both changes the dependency graph and also like the side effects of the code you're changing. It doesn't have to even be AI code reviews like there's plenty of static analysis tools out there from long ago like 2020, which are still pretty valuable.

So we spend a lot of time wiring those things in. I think that's trying to deliver on this promise of continuous integration, meaning that your business is more agile. Well, I think we actually, at this point, we love to jump into our favorite section called The Spicy Future. So I'm going to be curious, what your take around this stuff that most people don't believe in yet?

Okay, that was a great sound effect, by the way. My spicy future is that this is going to grow more than people expect, and not for the reason you might think. So Basil at its core is this sort of rules engine. It's like, oh, if you asked me for this output, I will work backwards to see how to construct that from the productions that I know all the way back to input files, which is the same model that make has. And that's actually not the most valuable piece here. There's two things that are much more valuable. One is that there's a protocol called REV2 remote execution, which Basil's not the only build system that speaks it. And there's a bunch of backends now that are the server side of this protocol. So that gives you the ability to do

caching and like farm workout to a farm of machines. So this is like, you know, um, just CC from forever ago. And like this is, this is part of what people know from Google is that they have this massively parallel build farm. The other part is, I mentioned the plugins that we took the Linux Foundation. So the fact that Basil works with almost every language and framework out there is very unique. And the ability that gives you to have homogeneity across, you know, developer infrastructure fleet means that you really can have a small team of people making changes that are super impactful because everybody at the company got more productive regardless of what language they're in. That thing is written in this language called Starlark, which is kind of a Pythonish language with

certain performance and execution time guarantees that are important for an incremental build system. This remote execution protocol and idea, plus a way to represent the build systems of all languages at once is what's going to take over. And whether that's incrementally improving Basel or a new build system, and there is a candidate out there, I don't want to like overhype it yet because it's probably six months out from like being ready for lots of eyeballs on it. I think we're going to discover that, like, we don't have to have this tradeoff between Kluji build tools and super complicated Ph.D. build tools, but we can have one that doesn't require PhD and also does everything we wish it would.

And so I guess maybe follow up of this. I'm curious because, you know, you're selling sort of aspect that builds products, right? Which I assume is mostly people that are going to be already want to use Basel. And I think the sort of the thing the need is there. I'm looking at your logos of all the customers are using Basel. There's a lot of AI companies and from people are small, right? I think one way or another is really interesting to see. Do you see the new wave of companies, like even at these startups, right? These startups, I mean, the ones you listen on our website are not actually that small, even from the get-go. It's a little bit larger than your typical two-people startups, but still pretty small, right?

You're like, still like hundreds of engineers or whatever. You may talk about some of the tradeoffs of people have been, we kind of talks about, like, it's actually basically shouldn't be that hard to adopt, the powerful and the execution and everything should be able to have a huge speed up. Do you see these teams that are adopting Basel pretty early in their journeys? Are they getting as much benefits that the larger companies are actually adopting? Because we see, like, larger companies usually are the ones that click on and say, oh, we probably need this now because of all complexity. But I assume that these smaller companies don't have as much crazy complexity yet. But maybe they taste the basil, they're adopted early. I'm just very curious, like, what got them

they even use Basel very early. Because most people I know GitHub actions still the thing, you know, lots of people still want to use the shortest path of possible here, right? So tell me more about like how you find even these earlier folks are really taking this on and what benefits and cons they're getting. Yeah. Let me take just a second to clarify GitHub Actions works great with Basil. So they're not like, because you still need something to drive the loop, right?

So the continuous part. Like I make a change. I have to go execute Basil test everything, right? And you're just expecting that basal test everything will be fast. We've got a lot of AI companies recently. I'm actually going to visit physical intelligence right after this that are, like you said, they're newer companies that don't have as much legacy baggage. And it's not that they need basal because the scale of the code necessarily means that

like Java C takes 60 minutes to run, right? This isn't like the sort of problem that like the previous generation of companies had that get to that scale. They do have problems of making their builds reproducible. They do have problems of polyglot. Data scientists tend to be in Python, but then you need Rust or C++ to make things fast enough. And so, you know, Python has like, of all languages, the worst packaging and distribution and build story. You know, source distributions arrive on your disk, and then, like, you're supposed

to sort of, like, run some bespoke C++ compiler that happens to give you something that will link into the interpreter at runtime and doesn't work all the time. So I think a lot of these AI and autonomous vehicle companies that we're working with, they have that problem today, and they also are able to attract the caliber of engineers who have worked at some of these other tech companies that have adopted it in the past at large scale. And they're like, hey, even at our scale, this thing will solve our problem. I'm curious. I think a lot about, you know, there's just a little level A, like, infrastructure stuff, which is like helping, you know, in a context you just gave around these AI companies, like helping them manage like the sprawling, growing polyglot

set of tools that all basically roll up into an experience and having that be, you know, fast. efficient, reliable. I'm curious on your thinking about as we move towards a world where agents are coding, agents are creating their own tools, agents are finding their own path of production, where do you think Basil plays in that world? And where do you think Basil sits? Because the broadest problem about Basil has almost always been, it's been too complex for the human to understand, but it's not complex. It's just highly descriptive, right? And we always have this tension in the products we build for people that we have to deal with like, okay, the complexity of the solution to model the problem oftentimes is too complex for a human

to grok and so you're always pulled in this tension between like finding the like the right in between space and that's also ultimately why like enterprise software is terrible to use and like you have CRM software designed for the SMB and all these like market things I'm very curious like what the future here holds where you can have an agent that can build on top of something like basil which is highly descriptive and highly deterministic and highly reliable and very fast and what that changes from an adoption perspective when more agents are going to be writing both their own tools but just writing more code. Yeah. Well, there's a few things to say there. I think one observation that I've heard from another company in the mono repo space is that

AI tools, first of all, want to understand your code. And to do that in a polyglot, larger repo, let me suggest, by the way, the term Omni repo, which is like a repo with multiple things in it, but it's not mono. There's not only one of them. So an agent working in that repo, first of all, wants to be able to know what the dependency graph looks like.

And so that's very interesting to be able to feed that into the context of like, I'm working in this file, and by the way, here's the graph of like how it's consumed in other parts of the repo

and then, you know, the AI doesn't have to go like make changes in places it shouldn't. Certainly today you use, you know, cloud code or whatever you like to make changes and then these tools are better about like verifying their changes.

And they're like, okay, let me see if the app still builds. And so they'll discover oh, I see you're in a basal build. Let me run the basal commands for you, which is not at all what you're getting at, right? Like, that's not tackling the basal complexity for you yet. I think where we're headed is probably, first of all, the sort of explain the error to me workflow. And like, I've seen a bunch of CI vendors now, like, you know, everybody has to add AI to their product and their contribution is to have it explain the error. explaining the error in a way that is more frequently

going to bring you back to what to fix is going to be the first unlock because a lot of the complexity in basil is just diagnosing why did I break it. And then I think the other part is going to be more tooling for taking, and this is the part that doesn't fit in the human brain, is, okay, like, if you run a basal query, it can output as a graph-vis diagram. And then the only thing I've ever seen somebody do with the resulting diagram is put it up on the screen and joke about how you could never possibly understand it because it's got so many lines and connections and stuff. And that's where AI is going to be key is insights into the graph. So like, why, if I change this file, do I execute that test? How would I fix that? how do I avoid cycles in the graph? Does my graph even relate to the architecture that I tried

to have for the software? Like, oh, it turns out, like, the dependencies here are, don't make sense. It turns out, like, the most important business unit at our company is writing code that depends on something that, like, nobody's maintained for the last three years. It doesn't have the SLA to support that, right? In microservices, we're all very well aware that you can't build something reliable that has dependencies on something less reliable. And the same is true for code maintenance. So I hope that's where we go. You know, I remember I was talking, to run that builds a company around Nix, right? And always Nix helps us like predatoryous usability, you know, rents and reputation.

And his hope is Floss can fix some of that or at least build tooling around it that makes the simpler. And I guess for Aspect. That build, are you also trying to make this basal feels like everyone's feel like it's a PhD problem kind of product easier? And do you think that is going to help adoption? Maybe tell a little bit what you're doing around the aspects of things. Yeah.

Yeah, I mean, I think, so we took a seed round about a year ago, and I would describe Basil as being pre-CASM. So this is the term VCs love to use for like the product has early adopters who are willing to bleed a little bit. And then there's this gap that you have to cross in order for like regular adoption to take place. And so, yeah, as part of the company growing and being able to, you know, I mean, like, today we have plenty of customers who want.

to use Basel, but, you know, tomorrow we need, let's say, 10 times as many. And so we have to help either Basel or another built system to cross the cask. So what specifically are we doing? Well, part of it is, like, there's some fundamentals that are in Basel core that Google's never going to change because with their, however many billion lines of source code, it's just really difficult to make changes. And so that's, you know, possibly this new build tool I mentioned earlier. And then we're also doing a lot of better documentation, better examples, essentially what I would call developer relations, which is just like make for the last mile simple enough. The basal starters GitHub org is another example there. Like make it so that I can get

started easily and then give me enough examples and maybe scaffolding out like new components so that I can add a new thing to my app and it works. And I think there's dozens of projects that I'm trying to push forward that improve that experience in varying degrees. So, like, one of them is the Basel documentation site. We're trying to move that to a community-hosted model so that it's easier for, like, the Linux Foundation to help us hire a tech writer, for example, to make substantive changes there. There's just lots of low-level work to do to improve the last mile, things like having presets, because Basil has, like, 750 flags, right? So we're working on, like, improving the flag experience, both with presets and also there's a team at Google that's trying to improve the situation with Basil's flags. So, yeah, I mean, I could probably go on forever about all the different projects.

we're trying to do to make it cross the chasm. And what do you think about Basel in comparison to other CI systems or build systems that exist there and what gives you bullishness that it can cross the chasm and the broader competitive market, especially as a sort of we have this next new wave coming and it's going to change a lot of the way that people build software, there's going to be a bunch of new innovation budget, there's going to be a look at basically everything that company is doing and they're going to go and say, okay, now what do we have to change, build by? In order to be agent-native, I'm kind of curious how you think, how well-positioned you think

Basel is there and why it's better than other competitors or other offerings. Yeah, I'd like to give lots of credit to all the other built systems out there and not to demean them in any way, right? So, first of all, you know, there's been a lot of clones. I think the most obvious one is Buck, too, which is from meta. So Buck was originally like a Basel clone. They rewrote it and it has, in particular, it has a dynamic action graph, which means basically as it's reading source files and performing build steps, it can then grow what it thinks is going to need to do, whereas Basil's fully static in that regard.

So that's neat. I don't think meta is backing that tool enough, and I don't think it has enough sort of developer relations to overcome the early market advantage that Basil had. Like Basil just has, like, massive adoption from all the signals we can tell, like 50,000 companies. I don't actually have a comparable number from Buck, but my sense is it's a lot lower.

And also Buck 2 can't reuse, the basal plugins that I mentioned earlier. And so they have to sort of rewrite every language integration, and that's where so much of the work is. And then you have other general purpose build systems that are trying to do all languages. Like Pants was an example from Twitter. Now that it's X, I haven't seen much from their open source and the company that toolchain.com that was founded around that folded. I mean, the Pants developers are still keeping it going. It's strong in Python. And I think that's basically the case for all the other competitors is you can say it's strong in this language. And it's not that, like, for any given, if you told me one programming

language, there would probably be an equally good build tool for that language. Maybe not for every language. For C++, definitely not. But like, there's a reasonable, like, you could use great old build tool plus dev velocity to get similar things for Java, Kotlin Swift kind of code basis. But I think the answer is if you want to be agnostic across languages, and I think part of the thing that you're getting at Ian with like the agenic revolution is that it's easier than ever to, like, bring in a new language because you don't need to, like, really deeply learn it. You can have the AI write it in whatever language is best for that problem space or just, like, you know, the flavor of the month or, you know, something that you have, like,

you have libraries you want to reuse that are in that language. And so I think it's just difficult to find a build system that's going to let you do that. Amazing. Well, Alex has been such a pleasure having you on the podcast. Is there, how can people learn more about yourself, Aspect, and all the work you're up to? Yeah, well, we're at Aspect.Bild. I'm pretty active on the Basel Slack. Come find me on LinkedIn. I also do a podcast so you can come listen to Aspect Insights

where I'm talking to a bunch of the folks in our ecosystem about what they're building and how we're going to make it better. Check out the Basel starters that I mentioned. And I guess I'll make another plug for the Linux Foundation effort to get the funding model fixed here because a lot of big companies are depending on this thing

and I think they have a perception that Google is supporting it more than they actually are. Amazing. Thanks so much. Yep. Thank you. It was awesome to talk to you guys.