Kyle Galbraith

And that's orders of magnitude faster.

The other part of build performance is the stuff that's not the tech side of it, it's the observability side of it.

is you can't actually make a build faster if you don't know where it should be faster.

And we look for patterns and commonalities across customers, and that's what drives our product roadmap.

This is the next thing we'll start optimizing for.

In the conversations that I have with customers, a lot of DevOps teams, platform teams, site reliability teams, they're really looking at this new era of software engineering that we're all living in.

And they're starting to question like the bottleneck is no longer the act of writing code.

The bottleneck is shifting.

The most time consuming part is integrating the code.

It's everything that comes after.

It's the build, it's the pull request review, it's the deployment, it's the getting it into production.

Once it's in production, it's scaling up support teams to support it.

It's adding documentation, all of these downstream problems.

And so through the lens of Depot, what we're really starting to think about is there's a very realistic possibility that within the next two to three years, maybe even sooner, that we're going to enter a world where an engineering team of three people

could theoretically have the velocity of an engineering team of 300 people.

And what's the consequences of that?

What's the consequences of the code velocity spiking up to that level with such a small team?

There's no way three engineers are going to be able to code review all of the code that's being created

If there's three engineers and 297 agents also creating features and fixing bugs.

So that's just like from a pull request perspective.