Welcome And Blacksmith Overview

SPEAKER_02 0:02

Welcome to Uplink, where we explore the world of digital infrastructure, uncovering the technology fueling AI and cloud innovation with the leaders making it happen. Let's get this going. JP is the founder and CEO, or one of the founders at least, and the CEO of an incredible company called Blacksmith. This is a really, I've been looking forward to this catch-up because uh this is a company that hit, I think, a million dollars in ARR with four people. It's two years old. You've got a dream team of founders that have come, I think, through friends through university. You've scaled the company now. I think you're at 25 folks and so forth, but you've just gone through the moon. You're solving a really interesting problem, and you're scaling so quickly. So we've got a lot to unpack, and I'd love to love to ask a few of these pieces as we sort of um go through this conversation. So uh first one is maybe you could explain what Blacksmith is and the problem that you're solving. And I'll try and get it uh and articulate in a way that makes sense to me at least.

SPEAKER_00 1:03

That that that that that that sounds great. Um When we started Blacksmith two years ago, what we set out to do was build was we built purpose-built infrastructure for running CI workloads really, really fast. Yeah. And just infrastructure specific to delivering CI. Just CI. And and maybe let me, you know, for the audience and also I'm not sure how familiar you are with CI. CI is, yeah.

SPEAKER_02 1:27

Yes, yeah. It'd be good to explain what that is, the words, and also what it means in practice.

SPEAKER_00 1:31

Yeah. So CI, it stands for continuous integration. And what it means to developers is the following. Really simple. Every time they write write code and they want to merge code, they have to run a do the build and run a battery of tests and make sure that nothing has regressed. And they can ensure that their code change can be merged into the main branch. That's and that none of the new changes break the old code in a code. Exactly. Like to make sure that nothing regresses. Now that's that's that's almost the definition of CI. Now, what that entails is every time someone pushes code, they have to run a battery of tests, they have to do builds, they have to run a lynch job.

SPEAKER_02 2:17

And they run that not in production, they have to do that in a dev environment, I guess, to try and test it.

SPEAKER_00 2:23

They need infrastructure to do that, and that's separate from production. Yes.

Why CI Feels So Slow

SPEAKER_00 2:28

And there are two problems with this. The first is that process is incredibly slow. So if you are a software engineer at a company and you're writing code, 10 out of 10. And it's a huge code base. It has to, yeah. Yeah. And and and here's the crazy part. When you're running CI, in most cases, you have to, or you can make optimizations, but in a lot of cases, um, even for a pretty trivial change, you end up running most of your tests. And over seven years, you have a massive code base, you have tens of thousands of tests, and that can be quite frustrating. At a lot of companies, this takes, you know, 30 minutes, depending on the size of your code base, to several hours.

SPEAKER_02 3:13

Yeah. And only to find there's a problem, and then you need to make a change, you need to rerun the test.

SPEAKER_00 3:18

Rerun it, and only then can you merge it. Only then your your you know, all your checks are green and you can merge it. And this is incredibly frustrating. Yes.

SPEAKER_02 3:26

Particularly now. Particularly now, yeah. Given how much change people want to add. This probably wasn't an issue when you had the old days where you'd have a code base and like once every quarter will update the code or once every six months. Whereas now I people are, I mean, we update daily uh into the platform.

SPEAKER_00 3:42

Uh so so I I I'll I'll I'll I'll say this. This used to be a problem in the past too. Okay. But like pre-AI code gen, depending on who you asked, again, this really depends on the company and the developer. And I'm just gonna throw a number out here. People push code maybe thrice a day. Okay. So they had to go through this process of like pushing code thrice a day. Yes. And every time they did it, they would have to wait for CI. But now you have this happening on steroids where you have agents pushing code all the time. And you're running the same, you know, your your your your pipelines, you're running it 30 times a day.

SPEAKER_02 4:18

Yes. And that's and that's crazy. And each time, um, and just as you're saying this, you have multiple coders. This is what's interesting, you've got multiple coders, each one might be running 11 agents on their code or whatever. This person might be updating the code, and this person might be updating the code separately. You run tests separately, you both try to publish or something they haven't tested together. I don't know. Like this is becoming true.

SPEAKER_00 4:42

They're all sources of- I mean, I mean, there's there's the concept of a merge queue and conflicts, and there's I mean, that's a whole separate can of worms. I I won't even go there. Yeah. But going back to what you mentioned, you can have developer A pushing code and you need compute or infrastructure to validate that code. And you can also have person B doing it at the same time, and they have to run separately.

SPEAKER_01 5:04

Yeah.

SPEAKER_00 5:04

So uh a natural side effect of this is you're gonna need a lot of compute. Yes, yes, yes. And the compute demands have just gone up.

AI Agents Make CI Explode

SPEAKER_00 5:12

Skyrocketed. Have skyrocketed because of this.

SPEAKER_02 5:15

Yeah. But that's kind of one of that's one of the big problems you're solving. That's one of the big problems that we're solving.

SPEAKER_00 5:19

So we're our value prop is twofold. The first is um we make CI run a lot faster. The second is we manage the infrastructure so teams don't have to worry about this.

SPEAKER_02 5:33

Aaron Powell The infrastructure to run the CI. To run to run CI. Yes. And you can scale that super fast. So you could if someone wanted to run, I don't know, 10 massive code bases and test now and tomorrow or less, but you can scale in and out of the platform, presumably.

SPEAKER_00 5:48

Yeah. All customers have to do is just start, just migrate to us. And our philosophy on infrastructure is that it needs to be invisible. We don't want them to think about it. So you can be a team of 10 or 100 people, and you could be not using coding agents or having coding agents running all the time. Yes. We manage the infrastructure for you. So that's how we started the company, and that was the value prop. But with four people. With three people and then later designer. But along the way, what we realized was that the infrastructure that we've built to run CI is really great more broadly for running any type of code validation workload. If you think about it, CI is a specific type of validation step. It's what you do after you push code. Aaron Powell After, yeah, to keep it up fresh, updated, and all that. Aaron Powell But what we've realized over time is that our infrastructure is really great for any type of code validation. Aaron Powell Even if it's not continuous, it's just the first vote code validation, new product or whatever it may be. Trevor Burrus or even as agents are iterating on code.

SPEAKER_02 6:55

You can do it before you even look at putting into the bigger code base, just clean this piece constantly and make that faster. Exactly. During development.

SPEAKER_00 7:04

And we're going to be launching a lot of products centered around that to help people do that.

SPEAKER_02 7:09

But yeah, that's so explain to me this. I'm a I'm a coder. I sit in Git. I'm sitting there in GitLab or something like that, or GitHub or whatever. And you've got agents running that are producing code for you. When you go to run testing, you then push this out, or you is it you just a link to from GitLab and you just press a button and it publishes into your platform. So it sends all the code base or something in there at one time and then it starts running the running it, or do you hold the code base or yeah, how does that work?

GitHub App MicroVMs And Cache

SPEAKER_00 7:42

That's a great question. So the way it works right now is first, we only support GitHub as a platform. We don't yet support GitLab. Developers install our GitHub app. That gives us a bunch of permissions to be able to do to run their CI. And pretty much what happens is every time someone pushes code, we get a bunch of web hooks from GitHub telling us that, hey, there's this org named Megaport. You have a bunch of CI to run. And what we do on our end is we spin up micro VMs. And these micro VMs uh run the GitHub Actions binary. So it starts at running their CI.

SPEAKER_02 8:22

Interesting. Yes.

SPEAKER_00 8:24

And automatically, we've got thousands of these. I mean, as we're talking about right now, we probably have 20, 30,000 VMs running customer jobs as we speak. Yes. We run millions of customer jobs a day. And these VMs are hydrated with cache artifacts that make these builds run a lot faster automatically, you know, out of the box without the customer having to do any work.

SPEAKER_02 8:43

Yes. And this is where the infrastructure side is really interesting. I mean, on our side, we had this belief of that high-performance compute is required, other than, say, just something that would be provided out of AWS or Azure. Aaron Powell So what we've seen is that we had this belief that infrastructure, uh particularly high performance compute, uh GPU storage, high performance platforms for that, made a lot of sense. And we're starting to see that scale now. And the the world's changed. We we could chat about that in a minute. But there's certain workloads that make a lot of sense in the cloud, and there are workloads that don't make a lot of sense in the cloud. And that's where we've, you know, bare metal and high performance compute gives you the full access to the box itself. And we build boxes for you guys that are very specific to your workloads and so um deliver an outstanding performance. Is that uh SaaS companies in the past used to just all they did was create great software, stick it on AWS scale anywhere in the world, and it was that simple. Today, what you're you're leveraging is high performance compute infrastructure beneath that. Now, typically you just throw it on AWS, but I'm assuming either performance or cost-wise, that doesn't make sense. Um is that is that something that's this is very different to what the SaaS cell companies were not that long ago. And I'm not saying you're a SaaS company, by the way, either, because you're already stuck in a SaaS pocalypse world that's in. But that's such a different theory behind it. We had a belief that that was going to become critical. And we know that you're using a lot of that infrastructure. So is that something you ever thought about landing in that space or the cost-wise or performance? What is it that makes you um not leverage that platform?

Why Hyperscalers Struggle With CI

SPEAKER_00 10:22

I I I can share more about this, and this is one of the reasons we started Blacksmith. So we had one observation, and that was that at that point we realized that CI as a workload was a completely different beast from what you're describing, which is what I would what I would describe as production workloads. Yeah. I would describe production workloads as running a database, running a web server. And the hyperscalers are fantastic for that. And the trade-offs that they've made at almost every single level are more geared towards running a web application or a database. And they subtly nudge you towards using a lot of things that guarantee durability. Um, an example of this is EBS volumes or network attached storage. But realize that CI has a completely different set of trade-offs. When someone's running CI, the only thing that you care about is performance. You actually do not care about durability. It is okay if your machine craps out and your CI job fails, you just need to run it fast, yes. Yeah. And the only thing that matters is performance. And the second bit is CI workloads are extremely bursty. Now, coming back to the example that we were talking about, we have customers who, you know, ever where every time a developer pushes code, they need access to a thousand VCPUs worth of compute that run for, say, 10 minutes and then scale down to zero. And at times you have seven or eight developers pushing code at the same time. So if you look at their utilization, there are these like really tall spikes that go all the way to 8,000, come down to zero, go to two, go to four, come down to zero. It's very different from a production workload. Yes. And we quickly realized that on the hyperscalers, hyperscalers were great if you wanted to slowly add machines. And I mean 10% of the EKS and you have Carpenter to help with that, but that's not really great when you want to go from zero to say 8,000 uh cores in a matter of 10 seconds. Wow. So we quickly realized that both of these made it extremely hard to make it work on the hyperscalers. 8,000 cores, which is like a lot. And and yeah, you know, in fact, we have some customers that burst all the way up to 40,000 in a matter of seconds, which is absolutely crazy. We would not be able to do that on the hyperscalers. And we're able to handle that with with without breaking a sweat. So that was really the the the the thesis behind why we decided to build our own stack.

SPEAKER_02 13:00

Yes. And so you also build, I also know you build your storage elements, you stitch them all together, and you've built something. Is the is it the optimized, everything's optimized for just super high performance?

SPEAKER_00 13:11

So that's what's sort of every single part of the stack. Yeah. Every single trade-off, every single decision that we've made is simply geared towards performance.

SPEAKER_02 13:20

That's incredible that you I mean, which you've built, this

Shipping Faster While Keeping Quality

SPEAKER_02 13:23

is two years. So is am I right in assuming that AI has helped you build and code this to build this business faster than something you could have ever done, say three, four years ago? Um is that a true statement?

SPEAKER_00 13:36

Abs Absolutely. I I think pre-AI. Right now we're 25 people and we're an eight-person engineering team. Pre-AI, I mean, without coaching tools, we'd need a hundred people a minimum.

SPEAKER_02 13:49

Yeah, yeah. And the time that it takes to deliver that. You know what's something on our side? We have uh something like uh 90 developers inside the business across the world doing all different products that we've got. And they're all leveraging AI in some way, shape, or form. Some are super passionate and gone deep and running lots of agents, some are, you know, taking and taking their time in different ways. Um, some of our platforms are super um, you'll be super careful, like we're particularly with the network. We're a giant network as a service, you'd be incredibly careful whenever you publish to that thing would literally cause all sorts of we we can't have the network go down. So you'd be super careful. One of the problems that we've seen is everyone is developing so fast now. Everyone. And we used to have these sorts of QA folks who would sort of test, and it's just become like this giant like funnel that's hit these folks. And so we've had to pivot the thinking, or at least, and we're probably not even uh doing this right, but we've had to get each other, everyone checking each other's code because we couldn't withstand the amount of code that's coming through. And for whatever reason, I mean, maybe Claude's getting there, but it's I think still I think the QA component is probably needs a little bit of work. That's the bit where it seems to get stuck. Um, I'm definitely not a coder, but it's sort of that seems to be the feedback. Is this something that helps solve for that equation as well? Or how do you see that play out with your teams? And and um is that statement even true now? Maybe it's changed last week, who knows?

SPEAKER_00 15:18

So something that I've observed and and also talking to our customers the the the amount of code that's being shipped is getting to a point where it's very hard for people to even review pull requests. Like back in the day, there's a lot of friction in creating a PR. Today, you can go on Slack and you can add a coding agent and you can give it a prompt, five minutes later, you have a PR. And it's getting harder and harder for humans to review code, which is why you're seeing a lot of code review tools succeed, they're taking off. Um I think companies are still, including ourselves, we're figuring out how to get past that. I think, I think, I think, I think a few ways I've seen companies go about it is certain pull requests, like you have an agent review the change and flag it as a like low, medium, or high risk, and they have certain thresholds. Like if it's low risk, you know, you don't actually need a human to go review it. But if it's medium, you kind of do. If it's high risk, you need maybe two people to review it. I've I've seen flavors of that. Um but actually in this context, something that you can do to make sure your software, your or your system does not regress is actually add more tests. Well, that that's what I was thinking. Wouldn't that be the you actually test it in the code itself? Like have more unit tests, have more end-to-end tests. And these coding agents are actually incredibly great at writing tests. Yes. And that's something that we've seen across the board too. I was I was having lunch with a customer today, and they were like, traditionally, writing end-to-end tests have been a pain in the ass. But because of how good AI coaching tools are, they were actually able to get a very high percentage of their product surface, like have end-to-end test coverage. And and those are some ways you can kind of get around it. Yeah. Like have guardrails so that so that most of your code is actually tested.

SPEAKER_02 17:17

Got it. Let me ask

Ideal Customers And Word Of Mouth

SPEAKER_02 17:19

you this. Who is your customer base? Who would who is your ideal customers? I mean, are it coding?

SPEAKER_00 17:25

Trevor Burrus, Jr.: Yeah. I mean, eventually we want Blacksmith to be, you know, everyone writing code that requires your code needs to be running on Blacksmith. But today our focus, I'd say, is on high-grid startups. Yes. So anyone who's, you know, series A to pre-IPO. Yeah. And and the rationale for that is these are teams that are early adopters of AI codigen tools. And they're the ones pushing the most amount of code. And they care about developer velocity or Asian velocity. They want to move as quickly as possible, and they're eager to try out Blacksmith. Yeah. Uh I do think we're about a year or two out from enterprises truly getting AI build. And at that point, they'll start to see similar problems and we'll serve them. But our focus today are what we're calling like high-growth startups or digital natives.

SPEAKER_02 18:15

Aaron Powell And how are they finding you today? Just um how do we how do we help get your message out there?

SPEAKER_00 18:20

Um like one of the biggest channels is word of mouth.

SPEAKER_02 18:24

Yes.

SPEAKER_00 18:25

They tell their friends about it.

SPEAKER_02 18:26

It's funny, that's how Latitude was was built. Like literally product led, just I think Reddit. Something like that. Yeah.

SPEAKER_00 18:34

We have developers talking about us on on Twitter. And a big source of of engineers uh like trying us out is let's say they're at company A and they leave for another company, they tick us there.

SPEAKER_01 18:48

Yeah.

SPEAKER_00 18:48

Yeah.

unknown 18:49

Yeah.

SPEAKER_00 18:49

Which is perfect for high-growth startups because they're always moving.

SPEAKER_02 18:52

They're too slow at the enterprises, and they might move once every three years. Okay. So let me pivot and ask you about building a company. You've started it two years ago. How did you have that vision? I know you've c you've got two co-founders. You went to university together. Um they both worked at Cockroach. Cockroach Labs, yeah. Yeah. Uh I got a chance to meet them in New York, gave me a t-shirt, which was helpful because I ran out of clothes on this trip. So uh that was very, very useful on Sunday. Um, yes, tell me about how you how do you even do that? Were you call each other to say it's a cool idea, let's do something, or what happened there?

SPEAKER_00 19:26

After university, the three of us ended up in Toronto. So they were working at Cockroach, uh, I was I was working at Fair, and the three of us, we would hang out a lot, and we had an itch to start a company.

unknown 19:38

Yeah.

SPEAKER_00 19:39

And we were developers, and we were looking at, okay, what problems do developers face? And CIA was, I mean, uh CIA was a screaming problem. I mean, we all used to encounter it every day, and they um one of them had this gaming rig. And and he noticed that building Cockroach's code base on that was a lot faster than doing it on GCP, yeah. On a remote GCP VM. That led to a number of conversations. And during that time, we were also like going through Pivot Hell. We were trying to see if some other ideas were eventually we converged on on Blacksmith.

SPEAKER_02 20:23

And did you you your Series A, um, I think you Google Ventures backed? Um how long from idea to that? Obviously it can't be long because it's only a couple of years, but yeah, was that was that a was Google when did Google enter the the the fray? Was it before you had sort of an idea or the product market fit component, or was it post-product market fit?

SPEAKER_00 20:42

We applied to White Combinator, the startup accelerator with just an idea. And at the end of White Combinator, which is about a month after we launched the product, Google Ventures led our seed and they wanted to double down. And we loved working with with Eric Nordlander.

SPEAKER_02 20:58

And Google Ventures is in has created some incredible companies. Yeah.

SPEAKER_01 21:02

Yeah.

SPEAKER_02 21:03

Yeah. Companies I've been a part of in the past were Sequoia and Google Ventures back, which was just very, very helpful for their growth. Uh, very supportive to get the company to do what it needs to do. I bet they're even impressed with the number of humans that you have in the team. Well, well, I think lots of companies are appearing that this is this sort of bizarre piece that no one ever thought was possible. If you rewound a little bit, one of the fastest companies from zero to a hundred and ARR was Wiz. You know, it came out of nowhere. That was in 2020, I think they wrote the first piece of code in 2023 or whatever it was, maybe they hit 100 million, which is considered like this insane growth. But what's happening now is teams of tiny numbers of humans are doing that. You're and you're the example of that. So we hear about it a lot, but you're the example of it. Solving a problem, scaling, and not needing a giant sales team, not needing a giant function. I mean, you might build that over time, who knows? But right now, you're sort of scaling so quickly. And the growth. Is insane. Um, I mean, we see your growth, by the way, on the on the on our side at least in terms of what you're utilizing. So that's impressive. Um talk to me about the growth

Planning Hardware For Hypergrowth

SPEAKER_02 22:10

element. How do you deal with that level of growth, particularly when you also require physical infrastructure to go and do that?

SPEAKER_01 22:16

What what is the thing that slows you down, or how the hell do you plan when you're growing so quickly?

SPEAKER_02 22:23

Um I I mean because before this wasn't a problem. You just let AWS deal with it. But now this is like your value is part of that. So it's like um it's just sort of hard to plan, I guess.

SPEAKER_00 22:36

I'll add something to that. I think what also makes it incredibly hard to plan is we don't really know how much more code people are gonna put or agents are gonna push.

SPEAKER_02 22:47

Yeah. I mean three months ago, four months ago, it changed. Well, we certainly felt it changed, but I'm assuming it massively changed.

SPEAKER_00 22:53

Especially after the Opus 4.6 launch, we saw this huge spike in the amount of like PR gen, right? Yeah, we've heard this from a lot of companies. Yes. Typically the conversation goes, oh, and oh, ever since we started using cloud code or after like the Was that was it February, January or something? That was actually late December. Oh, like so people don't hold it up in January. Like my quote, we we have this theory that people were playing around with cloud code during the Christmas break and they came back and they were like, this is working. Time to make sense. Time to token max. And ever since then, we're actually seeing a five to ten percent week over week growth in the number of PRs per developer. Like, which is absolutely crazy. And we and it's all about capacity planning. We have to plan for a capacity four to six months out.

SPEAKER_02 23:42

Well, if you and that's really hard to do. Yeah. When you're doing that sort of growth, yeah. Yeah, you're almost having to redo everything weekly, monthly versus most people are like, oh, maybe do a year plan, or then we're just quarterly and now, yeah, you'd you're doing something a lot quicker. And you're also doing it, unfortunately, at a time where everything's running away from everyone. And that is data centers are disappearing at the rate of notch because every single person is just trying to take it. All the CPU and memory and RAM and all the um supply chain challenges that are sort of just compressing everyone. So it's not only, not only making, I mean, it's because everyone's getting growth on that, everyone's trying to consume something. So it's in a really interesting time too. It's hard to solve that problem. That's kind of where we we've uh, I mean, we're we're we're running faster than we've ever had to run in the history of time, but we've got so many different parts of our business help us solve that problem in different ways from data centers. Um, we're in 1300 data centers, interestingly. Like we're with um RACs, with uh MSAs, with all those data center providers. We've been there for 13, 14 years with 400 gig fibers, dual in every one of those. We also have CPU and um components in each one. That was this sort of megaport was this giant network as a service fabric. And in December or November, I can't remember now, we closed on Latitude, which was this CPU, GPU, and storage. So we had network totally autonomously run by software, delivered in 30 countries. And then we said, well, actually, we believe that compute, network, and storage is the keys to the every single application in the world, CPU, GPU, cool, call that, and that's everything. And we can automate that with software and deliver physical infrastructure at that scale, so super high performance but cloud-like, could to deploy. We thought that that would make a lot of sense. And I mean, the company, like we've seen growth that we were sort of planning over maybe a five-year period happening in months, like something out like that. People came back on January or whatever, and you you've exploded, but it's not just yourselves, there's lots of folks that have also exploded. It's actually a good time. One of the frustrating things was when AI came out, it was like there was only a few people really winning for a long period of time. Um, and something about that Claude code change has lived has changed everything for so many other flow-on companies, like the utopian dream that was sort of waiting for three years, sort of appeared. Um, and it's then it's gone run so, so, so fast that everyone's gone, we need all the data center space, we need all this compute, we need all this memory, and everything's sort of got messed up. But um, it's a cool time, man, to be um a part of anything, actually. It's really, really exciting. Because what you're doing in that period of time, it would have taken even the fastest company in the world prior years to do what you're doing in that really short space of time. And the fact that you can keep your hand around the number of humans inside, at least for for the time being, I'm sure at some point you'll get to a point where it has to scale with sales and customer success and support and what have you. That's awesome. Like it's it's fun. Is it fun for you or is it just crazy hustle stress, or is it a little bit of both?

SPEAKER_00 26:49

It's a little bit of both. I think what I would describe it is type two fun. Or I don't remember, someone else told me about this. It's not fun in the moment, but it's fun maybe two weeks out after like, oh yeah, that was that was a lot of fun.

SPEAKER_02 27:01

Yeah, we hustle, we executed while you're in the middle of it. Yeah. Yeah. And we we saw that we we closed a $254 million deal um a few months ago. Sorry, a few weeks ago, actually. Um and closing that meant every single piece of the puzzle had to be lined up in one exact moment. And if you miss a single piece of the puzzle, the whole thing does not work. And each one of these pieces is incredibly difficult and complicated and time sensitive. And you have to line like all these things up at the exact same moment so that they all execute on the like the same day, including contracts for data center power and space that's disappearing where you look at them, all the CPU, GPU, and delivery and supply, the network component, the storage platforms that sit next to it, all these factors. And then you need to somehow figure out how to make sure that there's even racks, physical racks available. Click that button, do it all, and then we're publicly traded, so we have to announce the minute second we do it. So um I'm kind of with you. Like at the time, we wasn't a lot of sleep, and then you finish that and you even look back, and you're like, oh, now we have to execute. So I don't even know if I've gotten the type two fun. Get to the yeah, it's maybe it's this raging anxiety that just never stops. Uh it's wild. Maybe in a few years you'll look back and yeah, well, yeah, we'll look back, we'll execute. Once we when we go live, it's funny, we we had um we had a customer of ours that needed a whole heap of GPUs delivered very, very quickly. And we actually, from contract signed to actually turning them on was two weeks. Um, that hustle was just wild. We were diverting vast storage platforms from one side of the country to the other, needed a petabyte quickly there. We had network devices from another piece there. We needed a bunch of CPU we put out of the other part of it. We had all these H-100s coming in from a different location. Like, and then two weeks we got that stood up. Um, customers sort of couldn't believe it either. No, no, no one could actually believe that this thing was live at that point. But we keep doing them. So we've got another one and another one and another one. So um yours is actually really interesting. Your problem is just the sheer quantity of CPUs. It's actually huge, huge amounts of CPUs, which is funny. It's a much harder problem to solve than a GPU. Um what's what's happening is GPUs are about 124 um servers of eight um, say B300s, cost more than like 20,000 servers. You know what I mean? The cost. But the complexity is running and automating compute is very, very difficult. It's incredibly difficult. Whereas one SKU, B300s or whatever it is, it's one SKU and it's 120. You and I could install that this afternoon. So it's the the scale problem actually is much harder on compute, which is what we had this belief was the the why that we brought these two companies together. So and I know it's helping, it certainly helps us with your your business as well. We couldn't deliver for you without all the automation platforms that we have. You just never would never do it. That's crazy. I bet. Yeah. Anything else you wanted to share before we we we we wrap up? Was any um any interesting thoughts that's going on?

Always-On Agents And The Next Phase

SPEAKER_02 30:10

What do you what do you see the future?

SPEAKER_00 30:12

Um in the future, we see a hundred X more code being produced. Yes. Like so just constant increase. Constant increase. I think I would say there are three phases of uh software development. One is like pre-AI, human-based software development. I think we're fast fingers can type. Yeah. Yeah. I think I think we're actually in the middle phase right now where you have humans prompting agents to write code. There's actually gonna be this future, maybe a year or two out, where you're gonna have agents running all the time, literally 24-7.

SPEAKER_02 30:47

What agents running agents? Is that what you're doing?

SPEAKER_00 30:49

Yeah, agents like orchestrating other agents and I think something that I don't think we've gone to is the the a lot of a lot of systems are gonna be modeled like closed loop systems. And if you have a closed loop, agents can iterate extremely quickly. And once you kind of give it an objective, you're gonna see long horizon agents running for several days trying to accomplish a goal. And that's gonna that's gonna lead to an even higher like order of magnitude increase in the amount of code being produced. So it's a real exciting future. Which means more of your property. Exactly. Like more, more, more validation. We are pretty excited to power all of that.

SPEAKER_02 31:36

Yeah, it's amazing.

SPEAKER_00 31:37

It's gonna be a fun couple of years.

SPEAKER_02 31:39

Yeah, what an incredible company you've built. Congrats on two years. Imagine what you can do in three years or another few months. Um, yeah, we're proud to be partners with you and we love watching your success. And uh I love your t shirt by the way. So make sure we we think we have good t shirts. You also do. So yeah, congrats, dude. Appreciate you. Awesome. Yeah, this is really great. Pleasure, man.