DoorDash's Multi-Agent LLM System Cleans Up Stale Feature Flags Across 623 Repositories

Overview

DoorDash has deployed a multi-agent large language model system to clean up stale feature flags across its codebase, according to InfoQ. DoorDash’s experimentation platform manages more than 60,000 feature flags across roughly 623 repositories and creates about 2,300 new flags each month, InfoQ reported, and the company identified more than 1,000 of them as stale.

What We Know

DoorDash classifies a flag as stale when it has not been modified for 90 days, remains referenced in code, is not archived or retired, and is not explicitly excluded from cleanup, according to InfoQ. A daily process creates Jira tickets for flags that meet that definition.
The cleanup problem is harder than it looks because DoorDash’s dependency-injected wrapper pattern spreads a flag’s definition, client call, and business logic across multiple files, and a single flag can require changes across 5 to 20 files including tests, per InfoQ.
DoorDash found that Uber’s open-source rule-based tool Piranha did not cover its dependency injection patterns, “where relationships between the flag and application logic are semantic rather than directly represented by matching syntax,” according to InfoQ.
The system DoorDash built runs on Google’s Agent Development Kit and operates in two phases, InfoQ reported. In the first phase, an orchestrator running Claude Sonnet retrieves stale-flag tickets from Jira, searches repositories, and queries the experimentation platform through the Model Context Protocol for metadata.
In the second phase, Claude Opus cleanup agents operate in isolated Git worktrees, with up to four agents running concurrently per repository. The agents locate flag references, determine a cleanup strategy, modify source code and tests, and run builds, tests, JaCoCo patch coverage, and Detekt static analysis, according to InfoQ.
In an evaluation of 50 stale flags, the system produced usable pull requests for 45 of them, averaging “13.8 minutes and $4.79 per cleanup, compared with DoorDash’s estimate of one to two hours for manual cleanup,” InfoQ reported.
Results varied by flag complexity: InfoQ reported a 100% single-pass cleanup rate for simple flags, 94% for medium-complexity flags, and 85% for complex flags. Across the 50-flag evaluation, the process produced 31 first-pass merges, 14 revisions, and five engineer interventions, with no bugs or regressions in the evaluated changes, per InfoQ.
DoorDash plans to add confidence scoring for lower-risk cleanups and a post-cleanup code-quality pass to catch issues such as misleading variable names left behind after a flag is removed, according to InfoQ.

What We Don’t Know

Neither the underlying architecture description nor the published results detail how DoorDash selected the 50 flags used in the evaluation or how representative they are of the full stale-flag backlog.
Timelines for a broader, production-wide rollout beyond the 50-flag evaluation have not been disclosed.
Cost and timing figures cover only the automated cleanup step; it is not clear whether they include the time engineers spent on the five interventions or 14 revisions noted in the evaluation.

Analysis

The project is a concrete example of AI agents being pointed not at writing new features but at the unglamorous maintenance work — flag removal, dead-code cleanup — that engineering teams often let pile up because rule-based tooling like Piranha cannot reliably parse the semantic relationships in a large, dependency-injected codebase. The two-phase design, with a Claude Sonnet orchestrator handling ticket retrieval and metadata queries and separate Claude Opus agents doing the actual code changes inside isolated Git worktrees, reflects a broader pattern of splitting agentic coding work into planning and execution roles running in parallel across a repository.