DoorDash automatizó la eliminación de feature flags obsoletos con un sistema multiagente de LLM en dos fases que generó pull requests aprobados por ingenieros en 45 de 50 casos de prueba, con un promedio de 4,79 dólares y 13,8 minutos por flag frente a una referencia interna de una a dos horas de trabajo manual. Los resultados se publicaron en un artículo del track industrial de ICSME 2026 firmado por los ingenieros de DoorDash Atharv Chandratre y Jai Datar.
Claves
- El sistema convirtió 45 de 50 flags obsoletos en pull requests utilizables: 90% de éxito general y 85% en los casos más complejos.
- Un orquestador con Claude Sonnet planifica cada limpieza a través de MCP; los agentes con Claude Opus ejecutan las modificaciones, hasta cuatro a la vez, cada uno en su propio git worktree.
- Ningún pull request se abre hasta que la compilación, las pruebas, el 95% de cobertura del parche y el análisis estático pasan en local.
Por qué los flags muertos de 623 repositorios se volvieron un problema de mantenimiento
Un feature flag es configuración en tiempo de ejecución: controla un despliegue gradual, divide un experimento o funciona como interruptor manual de emergencia. Una vez que la funcionalidad está completamente desplegada, el flag deja de aportar valor. La lógica condicional permanece en el código como peso muerto, y una rama dormida que nadie prueba puede reactivarse por accidente.
Lo que vuelve inmanejable la tarea a mano es la escala. El artículo contabiliza más de 56.000 feature flags repartidos en 623 repositorios, 1.659 de ellos obsoletos a mayo de 2025. El propio informe de ingeniería de DoorDash sitúa hoy la plataforma por encima de los 60.000 valores dinámicos, con unos 2.300 nuevos cada mes. Las herramientas de limpieza basadas en reglas, señalan los autores, resultaron insuficientes frente a los repositorios de DoorDash: eliminar bien un flag exige razonar en qué se convierten los condicionales que lo rodean, no buscar un símbolo por coincidencia de patrones.
Cómo funciona el sistema de agentes en dos fases
La primera fase es de planificación. Un agente orquestador con Claude Sonnet recupera el ticket de Jira, consulta datos de despliegue en vivo de la plataforma de experimentación mediante MCP, hace un barrido semántico de todo el repositorio y emite un plan de limpieza estructurado que indica por qué valor debe sustituirse el flag. Un ingeniero confirma ese valor antes de tocar una sola línea de código: es el único punto de control humano del circuito.
La segunda fase es la cirugía. Un agente de eliminación por cada valor confirmado, ejecutado con Claude Opus, hasta cuatro en paralelo por repositorio y cada uno en un git worktree separado para que las modificaciones simultáneas no colisionen. Gradle corre con --no-daemon para evitar que el estado de compilación se filtre entre worktrees, y cada agente arrastra un límite duro de una hora.
Lo interesante son las barreras. Antes de que un agente pueda abrir un pull request tiene que superar la compilación, la batería de pruebas, un umbral de cobertura de parche del 95% con JaCoCo y el análisis estático de Detekt. Si falla cualquiera, no aparece ningún PR. El reparto de modelos responde abiertamente a la economía: el modelo barato se ocupa de recopilar metadatos y planificar, y el caro queda reservado al razonamiento sobre cadenas de llamadas y a las propias ediciones.
Qué mostró realmente la evaluación de 50 flags
El conjunto de evaluación no estaba sesgado hacia victorias fáciles. Incluía 41 valores booleanos, seis cadenas y tres enteros, repartidos en seis casos simples que tocaban uno o dos archivos, 18 casos medios de tres a cinco archivos y 26 casos complejos con condicionales anidados y dependencias entre archivos.
La tasa de éxito al primer intento siguió la complejidad casi punto por punto: 100% en los simples, 94% en los medios, 85% en los complejos. El coste hizo lo mismo. Las limpiezas simples promediaron 7,5 minutos y 2,69 dólares; las medias, 10,4 minutos y 3,46 dólares; las complejas, 17,7 minutos y 6,20 dólares. Catorce de los 45 pull requests aceptados necesitaron una corrección menor y cinco casos exigieron que interviniera un ingeniero.
Los modos de fallo son lo bastante concretos como para resultar útiles. Seis revisiones vinieron de cobertura de parche insuficiente y ocho de eliminaciones incompletas: una variable sobrante o una referencia que sobrevivía más abajo en la cadena de llamadas. Las cinco intervenciones humanas estuvieron todas asociadas a la profundidad de la cadena de llamadas y al paso de parámetros entre interfaces, que es justo el razonamiento que peor se le da a un agente de programación que trabaja con una vista local de archivo.
Qué dice esto sobre los despliegues de agentes que se sostienen
Basta leer la arquitectura para reconocer el patrón. Aislamiento por unidad de trabajo, un punto estrecho de aprobación humana y barreras mecánicas que el agente no puede sortear con argumentos: la misma forma que empleó Cloudflare cuando redujo un 85% los issues abiertos de Astro con cuatro agentes que se niegan a compartir contexto. La elección del modelo es una partida de gasto; el producto son las barreras.
Las cuentas cuadran incluso en el peor tramo: 6,20 dólares y menos de 18 minutos frente a una o dos horas de ingeniería. La reserva es el tamaño de la muestra. Cincuenta flags son un piloto, no la cola de 1.659, y tanto el coste como los fallos se concentran en el tramo complejo que domina esa cola. Si ese 85% sobrevive al contacto con la cola completa es la cifra que conviene vigilar.
Preguntas frecuentes
¿Qué modelos usa el sistema de limpieza de DoorDash?
Dos, repartidos por tarea. Un orquestador con Claude Sonnet se encarga de recuperar Jira, lanzar consultas MCP contra datos de despliegue en vivo y planificar. Los agentes con Claude Opus realizan las modificaciones de código, porque el razonamiento sobre cadenas de llamadas es donde el modelo más capaz justifica su coste.
¿Qué impide que los agentes rompan la compilación?
Cada agente trabaja en un git worktree aislado y debe superar la compilación, la batería de pruebas, un umbral del 95% de cobertura de parche con JaCoCo y el análisis estático de Detekt antes de crear un pull request. Un límite duro de una hora corta a cualquier agente que se atasque.
¿La limpieza es totalmente autónoma?
No. Un ingeniero confirma el valor de reemplazo al final de la fase de planificación antes de que empiece cualquier cambio de código, y los pull requests resultantes pasan por la revisión habitual. Cinco de los 50 casos de la evaluación necesitaron intervención directa de un ingeniero.
