DoorDash Deploys AI Agents to Automate Removal of 60,000+ Feature Flags

DoorDash has deployed a multi-agent language model system designed to automate the cleanup of stale feature flags across its codebase, combining live experiment data, human review gates, isolated Git environments, and automated testing. Testing on 50 outdated flags showed the system generated viable pull requests for 45 of them in roughly 14 minutes each, at an average cost of $4.79 per cleanup—far faster than the one- to two-hour manual process the company typically performs.

The Scale of the Problem#

DoorDash's experimentation infrastructure manages over 60,000 feature flags distributed across approximately 623 codebases and introduces roughly 2,300 new flags monthly. The team identified more than 1,000 flags sitting dormant—defined as inactive for 90 days, still present in code (not archived), and not explicitly exempted. Daily automated checks create tracking tickets for flagged candidates.

The real challenge lies in DoorDash's code architecture: flags often get tangled across 5 to 20 files through dependency injection patterns, where the flag definition, its invocation, and the actual logic live in separate locations. A seemingly simple Boolean flag can therefore require edits in tests, wrapper code, and business logic simultaneously.

Why Rule-Based Tools Fall Short#

Existing solutions like Uber's open-source Piranha use syntax-tree transformations to locate and excise stale flag code. However, DoorDash found that Piranha's syntactic approach didn't handle its dependency-injection patterns well—the relationships between a flag and its usage are semantic, not directly readable from the code structure alone. This limitation motivated DoorDash to pursue an LLM-based alternative.

The Two-Phase Workflow#

The system leverages Google's Agent Development Kit with Claude models orchestrating the work. In phase one, an orchestrator agent retrieves stale flag tickets from Jira, scans relevant repositories, and queries DoorDash's experimentation platform via Model Context Protocol (MCP) to gather metadata like rollout percentages and target values. An engineer then reviews the orchestrator's summary and approves the intended target before any code changes proceed.

Phase two deploys Claude Opus agents into isolated , running up to four in parallel per repository. These agents identify all flag references, decide on a cleanup strategy, modify source files and tests, and execute builds, unit tests, JaCoCo patch coverage checks, and Detekt static analysis. A pull request is created only after all validation passes. To prevent cross-contamination, each agent has a one-hour window and Gradle runs in no-daemon mode.