Kyle Galbraith

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.

But then you think about it through a build lens, too, of if your builds take 20 minutes with three humans and now you're going to have three humans and 297 agents also running.

Well, like you definitely don't want your builds taking 20 minutes because now like the entire pinch point is the build pipeline.

And so we're starting to think a lot about how do we eliminate the bottlenecks that come downstream?

And what can we do with Depot that streamlines that?

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.