DoorDash’s AI Agent Pipeline, Git Worktrees & When Engineers Should Build Their Own Tools

So first up, the news for this week, I wanted to talk about DoorDash.

setting up a multi agent LLM pipeline to clean up over 60,000 feature flags across their applications.

And so DoorDash has over 600 different repositories that they currently manage to deliver the platform that we know and love.

And DoorDash is actually one of the more modern companies in the sense that their entire business has always revolved around and included technology.

That's how they've driven most of their growth since they started.

And so when you're managing lots of different applications and most of your features are digital, you are able to play around a little bit and experiment with some different features and functionality that you may turn off and on, depending on how they kind of work with your customers.

And so over the years and the different experiments that have gone on, DoorDash has found that there were thousands of feature flags that were no longer used and stale, meaning the feature has already been adopted or just discarded based on user feedback, the growth of the company, and just basically we don't need them anymore, but they're still hanging around inside of our code base.

And the challenge when you have multiple feature flags that are stale is that it makes it difficult to add new functionality because you're still potentially having old feature flags that are enabled or disabled, but they're changing the way the logic works for that application.

And so that just makes it more difficult from an engineering standpoint.

And from a reliability and maintainability standpoint to kind of keep these intact.

But the challenge to get rid of them is they require a lot of engineering work to actually go back and remove those flags and figure out what the new functionality or new logic should be moving forward.

And so DoorDash has solved that problem by using LLMs and agents to take over those tasks.

They kind of broke it down into two phases.

The first phase was basically identifying the feature flag and determining if that flag was actually something that we need to clean up.

Was it stale or not? And then if it was stale, based off of the information that they're getting from JIRA and some of their other experiments, their experiments that have gone on, they're deciding, all right, if it's stale, now what is the plan to get rid of that functionality? And so that's what this new change has supported.

And then the second part of it is they give that kind of plan to a human engineer to validate.

And then once that human engineer has validated, they're able to start the next phase of the Code the cold chain or the to submit an actual pull request using another element that could do that work.

And so a lot of the Work for getting rid of the stale branches is pretty trivial and pretty simple for the most part, but it's time consuming and it requires engineering time that could be better spent deploying and adding new features.

And so this helps them to reduce the amount of toil it takes to clean up their code base while doing it at an affordable rate.

And if you want to go deeper into how DoorDash works and some of their different applications, they actually do have a blog, an engineering blog, that they publish a lot of their different engineering feats to.

And so it's worth checking out.

But here at BLI University, we actually go over some of the different blogs out of DoorDash, Uber, and other technology companies to actually... kind of understand and learn from what they're building and figure out what we need to learn how to build ourselves.

And we actually do more than just talk about it, read about it.

We end up building those systems on our own.