DoorDash: LLM-агенти чистять 60 000 фіче-флагів
У DoorDash понад 60 000 активних фіче-флагів у 623 репозиторіях і 1000+ застарілих. Оркестратор на Claude Sonnet готує звіт по флагу, інженер підтверджує рішення, а агенти Claude Opus у ізольованих Git worktree правлять код і тести та відкривають PR лише після проходження перевірок.
На тесті з 50 флагів вийшло 45 придатних PR, 31 змерджено з першого разу, без багів. У середньому — 13,8 хв і $4,79 за флаг, проти 1-2 годин роботи інженера вручну. Просте правило Uber Piranha тут не спрацювало — зв'язки між флагом і кодом семантичні, а не синтаксичні.
Коли флаг стає «протухлим» і чому це складно прибрати
У DoorDash флаг вважається застарілим, якщо його не змінювали 90 днів, він досі згадується в коді, не заархівований і не позначений винятком. Щомісяця платформа створює близько 2 300 нових флагів — тож потік застарілих не спиняється, і щодня система автоматично заводить Jira-тикети на ті, що підпадають під критерії.
Проблема не в тому, щоб знайти флаг, а в тому, щоб безпечно прибрати всі його сліди. DoorDash використовує обгортки з dependency injection, тому визначення флага, виклик у клієнтському коді та бізнес-логіка можуть бути розкидані по різних файлах. Один булевий флаг інколи вимагає правок у 5-20 файлах, включно з тестами. Готовий інструмент Uber Piranha, що працює через аналіз синтаксичного дерева, тут не підійшов: він шукає збіги в синтаксисі, а зв'язок між флагом і логікою в DoorDash — семантичний, тобто прихований за рівнем абстракції, який Piranha не бачить.
Як улаштований конвеєр з двох фаз
Систему побудовано на Google Agent Development Kit. У першій фазі оркестратор на Claude Sonnet бере тикет з Jira, шукає відповідні репозиторії і через протокол MCP звертається до платформи експериментів за метаданими флага — відсотком розгортання і цільовим значенням. Інженер переглядає цей звіт і підтверджує цільове значення, перш ніж почнуться правки коду.
У другій фазі за роботу беруться агенти на Claude Opus — до чотирьох одночасно на один репозиторій, кожен у власному ізольованому Git worktree. Агент знаходить усі згадки флага, визначає стратегію чистки, змінює вихідний код і тести, тоді запускає збірку, тести, перевірку покриття JaCoCo та статичний аналізатор Detekt. Pull request відкривається лише якщо всі ці перевірки пройшли. На кожного агента відведено годину, а Gradle працює без фонового демона — щоб стан одного worktree не протікав у інший.
Результат залежить від складності флага
З 50 флагів у тесті 31 змерджено з першого разу без правок, 14 знадобилось доопрацювати, а у 5 випадках втрутився інженер. Прості флаги пройшли чистку з першого разу у 100% випадків, середньої складності — у 94%, складні — у 85%. П'ять втручань інженера стосувалися глибоких ланцюжків викликів і параметрів, які передаються через кілька інтерфейсів — саме тих місць, де семантичний зв'язок найважче простежити автоматично. За всіма 50 оціненими змінами DoorDash не зафіксувала жодного бага чи регресії.
Що далі
DoorDash планує додати оцінку впевненості (confidence scoring), щоб автоматично вирізняти чистки з низьким ризиком, і окремий прохід перевірки якості коду після видалення флага — наприклад, щоб ловити змінні, назви яких після видалення флага стають оманливими. Роботу прийняли на індустріальний трек конференції ICSME 2026.