DoorDash limpia 60.000 feature flags con agentes LLM sobre Claude y MCP
La compañía ha montado un sistema multiagente que abre pull requests de limpieza de flags obsoletos sin intervención humana salvo la aprobación del valor objetivo.
DoorDash ha construido un sistema multiagente basado en LLM para deshacerse de los feature flags que ya no sirven en su código. En una evaluación con 50 flags obsoletos generó pull requests utilizables para 45, a un ritmo medio de 13,8 minutos y 4,79 dólares por limpieza, frente a la estimación interna de una o dos horas si la hace una persona.
El volumen explica el interés. La plataforma de experimentación de la empresa gestiona más de 60.000 flags repartidos por unos 623 repositorios y crea alrededor de 2.300 nuevos cada mes. De todos ellos, más de 1.000 están marcados como obsoletos: no se han tocado en 90 días, siguen referenciados en el código, no están archivados ni retirados y nadie los ha excluido a mano. Un proceso diario abre tickets en Jira por cada uno.
El problema no es trivial en su caso. DoorDash usa wrappers con inyección de dependencias, así que la definición del flag, la llamada al cliente y la lógica de negocio pueden vivir en archivos distintos. Un booleano aparentemente simple obliga a tocar entre cinco y veinte archivos, tests incluidos. La herramienta open source de Uber, Piranha, ataca esto con transformaciones sobre el árbol de sintaxis abstracta, pero la compañía comprobó que no cubre sus patrones de inyección: allí la relación entre flag y lógica es semántica, no una coincidencia de sintaxis.
Dos fases, dos modelos
El flujo se apoya en el Agent Development Kit de Google y se divide en dos partes. Un orquestador con Claude Sonnet recoge los tickets de Jira, busca los repositorios afectados y consulta la plataforma de experimentación a través de Model Context Protocol para obtener metadatos como el porcentaje de despliegue y el valor objetivo. Un ingeniero revisa el informe y confirma ese valor antes de que se toque una sola línea.
En la segunda fase, agentes de limpieza con Claude Opus trabajan en git worktrees aislados, hasta cuatro en paralelo por repositorio. Localizan las referencias al flag, deciden la estrategia, modifican código y tests, y ejecutan compilación, pruebas, cobertura de parche con JaCoCo y análisis estático con Detekt. El pull request solo se abre si pasa la validación. Cada agente tiene un timeout de una hora y Gradle corre sin daemon para que los worktrees no compartan estado.
De los 50 casos evaluados salieron 31 merges a la primera, 14 revisiones y cinco intervenciones de ingenieros. Los flags simples se limpiaron en una sola pasada el 100% de las veces, los de complejidad media el 94% y los complejos el 85%. Las intervenciones manuales se concentraron en cadenas de llamadas profundas y parámetros que atraviesan varias interfaces. DoorDash afirma que no hubo bugs ni regresiones en ninguno de los 50 cambios, aunque la medición es suya.
Lo siguiente en la hoja de ruta es una puntuación de confianza para las limpiezas de bajo riesgo y una pasada de calidad posterior, pensada para cazar cosas como nombres de variables que quedan engañosos cuando el flag desaparece. El trabajo fue aceptado en la industry track de ICSME 2026.
Merece la pena separar lo que hay aquí de la propaganda. El modelo no decide si un flag debe morir: eso lo sigue cerrando un ingeniero que confirma el valor objetivo. Lo que se automatiza es el trabajo mecánico de rastrear referencias, editar archivos de test y pasar los checks antes de abrir el PR, que es justo la parte que nadie quiere hacer y por la que los flags se acumulan durante años. Queda por ver si el sistema mantiene esas ratios cuando ataque los más de 1.000 obsoletos y no una muestra de 50.
