В DoorDash платформа экспериментов управляет больше чем 60 000 фича-флагов, разбросанных примерно по 623 репозиториям. Каждый месяц добавляется около 2 300 новых. Устаревшим считается флаг, который не меняли 90 дней, на который ещё есть ссылки в коде и который не архивирован и не исключён из чистки. Таких набрали больше 1 000, и каждый день по ним автоматически создаются задачи в Jira.
Задача усложняется тем, что в DoorDash используют обёртки с внедрением зависимостей. Определение флага, вызов клиента и бизнес-логика могут лежать в разных файлах. Удаление даже простого булева флага иногда требует правок в 5–20 файлах, включая тесты.
Почему правил на AST не хватило
В Uber есть инструмент Piranha с открытым кодом: он находит и удаляет устаревшие флаги через трансформации над абстрактным синтаксическим деревом (AST, структурное представление кода, удобное для автоматического анализа). В DoorDash попробовали и выяснили, что под их паттерны внедрения зависимостей Piranha не подходит: связи между флагом и логикой задаются семантически, а не совпадением синтаксиса.
Две фазы работы
Пайплайн собран на Google Agent Development Kit и работает в две фазы.
Фаза первая. Оркестратор на Claude Sonnet забирает задачи по устаревшим флагам из Jira, ищет релевантные репозитории и через MCP (Model Context Protocol, стандартный протокол для подключения модели к внешним инструментам и данным) обращается к платформе экспериментов за метаданными: процент раскатки и целевое значение флага. Инженер проверяет собранный отчёт и подтверждает целевое значение. Без этого подтверждения код не меняется.
Фаза вторая. В изолированных Git-worktree запускаются агенты на Claude Opus, по четыре параллельно на репозиторий. Они ищут упоминания флага, выбирают стратегию удаления, правят исходный код и тесты, прогоняют сборку, тесты, покрытие патча JaCoCo и статический анализ Detekt. Pull request создаётся только после зелёных проверок. У каждого агента лимит в один час, а Gradle запускается без демона, чтобы состояние не разделялось между worktree.
Что показала оценка на 50 флагах
Из 50 прогонов 45 дали пригодные pull request-ы. Среднее время составило 13,8 минуты, средняя стоимость $4,79 за чистку. Для сравнения, ручная оценка в DoorDash один-два часа на флаг. Распределение по сложности:
- простые флаги: 100% закрыты с первой попытки
- средние: 94%
- сложные: 85%
- 31 флаг прошёл без правок, 14 потребовали доработок, 5 потребовали прямого вмешательства инженера
- во всех 50 изменениях регрессий и багов не нашли
Пять ручных вмешательств касались глубоких цепочек вызовов и протягивания параметров между интерфейсами.
Где будут дорабатывать
В DoorDash планируют добавить оценку уверенности для низкорисковых чисток и отдельный проход качества после удаления: например, чтобы поймать оставшиеся имена переменных, которые после удаления флага начинают звучать странно. Работа принята на индустриальный трек ICSME 2026.
Как повторить
- Сначала опишите критерий устаревания: срок без изменений, наличие ссылок в коде, статус архивации, список исключений. Без явного определения агенты будут спорить с вами о входных данных.
- Разделите работу на фазы с явной точкой подтверждения. Сначала оркестратор собирает отчёт и метаданные, инженер их валидирует, только после этого запускаются агенты-исполнители.
- Изолируйте окружение для каждой задачи. В DoorDash используют отдельные воркспейсы, лимит по времени и отключают общий демон сборки, чтобы параллельные прогоны не делили состояние между собой.
- Прогоняйте проверки до открытия PR: сборка, тесты, покрытие патча, статический анализ. PR появляется только если все зелёные.
- Измерьте стоимость и время на репрезентативной выборке до запуска в прод. В кейсе DoorDash метрики считали на 50 флагах и сравнивали с ручной оценкой.
- Заложите проход качества после удаления флага. Имена переменных, комментарии и сообщения в логах могут остаться и начать вводить в заблуждение.
- Отдельно отслеживайте вмешательства инженера. Это даёт список мест, где агент не справился сам, и подсказывает, какие слои кода нужно дать модели в первую очередь.