La app de las tiendas Levi's: 17 agentes de IA reducen un trabajo de 9 meses a 2,5 meses

¿No causaría un caos que varios agentes de IA modifiquen el mismo código simultáneamente, chocando entre sí? La razón por la que las empresas pueden adoptar este sistema con seguridad no reside en la «inteligencia» de los agentes, sino en la «estructura» que previene los conflictos. En la práctica, Levi Strauss & Co. implementó 17 agentes de IA especializados en el desarrollo de su aplicación para tiendas, reduciendo el período de desarrollo, que solía tardar 9 meses, a aproximadamente 2,5 meses. Aunque de 5 a 11 agentes independientes revisaron todas las solicitudes de extracción (PR) y confirmaron automáticamente las correcciones, se estableció un control para garantizar que la fusión final la aprobara una persona.

Para operar varios agentes simultáneamente con seguridad, se requieren tres capas de salvaguardas: aislamiento, separación de permisos y aprobación humana. GitHub está implementando estos principios en las sesiones paralelas de la aplicación Copilot mediante «Git Worktree» y en los flujos de trabajo agénticos mediante «Safe Outputs». A continuación, examinaremos concretamente cómo estos tres elementos evitan el caos y garantizan la fiabilidad del trabajo en paralelo.

Los agentes no son servidores, sino «instrucciones de texto»

Es fácil imaginarse los agentes de IA como programas complejos que se ejecutan de forma independiente en servidores de altas prestaciones. Sin embargo, el caso real presentado por Jenny Patchen, directora sénior de Levi Strauss en GitHub Universe 2026 en octubre de 2026, era mucho más simple y transparente ¹, ². En el entorno de desarrollo de Levi, los agentes no eran ejecutables, sino archivos de texto en formato Markdown (.md) ubicados en carpetas específicas dentro de los repositorios de Git.

Estos archivos Markdown contienen las instrucciones que indican al agente qué debe hacer. Los desarrolladores modifican directamente estos archivos de texto para cambiar el comportamiento del agente. Ajustan su perfil de la misma manera que se modifica el código de una aplicación común, y los cambios pasan por la revisión de compañeros a través de PR, gestionándose mediante control de versiones igual que el código tradicional ². Es decir, los agentes no son cajas negras, sino herramientas de desarrollo controlables mediante texto, lo que permite a las empresas gestionar con precisión el comportamiento de la IA.

Primer mecanismo: bloqueo de conflictos físicos mediante Worktrees

Cuando varios agentes empiezan a operar, la primera preocupación son los conflictos de archivos. Si el agente B sobrescribe un archivo inmediatamente después de que el agente A lo haya modificado, el código acabará siendo un desastre. Para resolver este problema, GitHub ha aplicado la función de «Git Worktree» en las sesiones paralelas de la aplicación Copilot.

En el ejemplo de «tailspin-toys» presentado en el blog oficial de GitHub, este método se comparó con «poner a funcionar varias lavadoras a la vez en una lavandería» ³. Esto significa que cada lavadora (sesión) puede operar con la configuración deseada de forma independiente, y que se puede iniciar otra lavadora inmediatamente sin esperar a que termine una ³.

Aunque varias lavadoras trabajen simultáneamente, cada una utiliza su propio espacio independiente, por lo que no interfieren entre sí. Incluso si los agentes desarrollan funciones, revisan código y ejecutan pruebas al mismo tiempo, no se producen conflictos físicos de archivos. Además, los desarrolladores pueden continuar desde el último estado que cada sesión mantiene al cambiar de contexto, reduciendo así los tiempos de espera ³.

Segundo mecanismo: separación de permisos mediante Safe Outputs

Aunque los espacios de trabajo estén aislados y no haya conflictos físicos, si varios agentes pudieran escribir y modificar archivos libremente en el repositorio, este podría convertirse rápidamente en un caos. Existe el riesgo de que la IA, desbordándose, genere multitud de archivos sin sentido. Para prevenir esto, GitHub ha introducido una sofisticada estructura de separación de permisos llamada «Safe Outputs» (salidas seguras).

En la estructura Safe Outputs, los agentes no tienen «permisos de escritura» para escribir directamente archivos en el repositorio de Git o ejecutar comandos ⁴. Cuando un agente detecta un problema durante el trabajo o necesita modificar código, solo deja una «solicitud» en forma de salida estructurada, indicando por ejemplo «registren esto como una incidencia» o «modifiquen este código» ⁴. La «ejecución» real, como la creación de archivos o la modificación de código, la lleva a cabo un trabajo en segundo plano al que se le ha otorgado un permiso estricto y específico ⁴.

Este sistema actúa como una salvaguarda contra los desbordes de una IA incontrolable. Incluso si, por configuración predeterminada, el agente puede acceder automáticamente a la función «create-issue» (crear incidencia), existe un límite estricto de ejecuciones (max: 1) que evita caer en bucles infinitos ⁴. Además, utilizando condiciones «depends-on», es posible controlar el orden, haciendo que las tareas posteriores esperen si las previas no han finalizado ⁴.

Tercer mecanismo: mantenimiento de la capacidad de decisión humana

Aunque el aislamiento técnico y el control de permisos establezcan seguridad, la responsabilidad sobre el resultado final debe recaer en las personas. Levi Strauss implementó 17 agentes especializados para la renovación de su aplicación de tiendas, encargados de escribir requisitos, ejecutar pruebas, realizar escaneos de seguridad, entre otros ². Estos agentes asumieron toda la «ejecución» dentro del ciclo de vida del desarrollo.

No obstante, el principio fundamental de este proceso era que «los agentes ejecutan, los humanos deciden» ². Aunque los 17 agentes interactuaron con herramientas externas para corregir código e incluso realizar confirmaciones (commits), se diseñó el sistema para que la etapa final de «fusión» (Merge), necesaria para aplicar los cambios al entorno productivo, pasara obligatoriamente por la verificación y aprobación de una persona ².

Se eliminaron los 12 traspasos de trabajo y los tiempos de espera entre 6 roles que existían en el proceso anterior, aumentando la velocidad de desarrollo; simultáneamente, la capacidad de decisión y la responsabilidad sobre la aprobación final del proyecto quedaron claramente asignadas a los desarrolladores ².

Siguiendo el flujo operativo real

Podemos observar cómo estos tres mecanismos se combinan y funcionan en un entorno de desarrollo real a través del proceso de añadir una nueva funcionalidad. Este proceso demuestra que la IA no ahorra tiempo simplemente escribiendo código rápidamente.

En primer lugar, un agente de requisitos identifica la solicitud de una nueva funcionalidad y redacta un borrador de especificaciones en formato Markdown para la revisión del desarrollador. Cuando la persona determina la prioridad de estas especificaciones y las aprueba, un agente de compilación (build) redacta el código real basándose en ellas y genera una PR ².

De 5 a 11 agentes de revisión independientes acceden simultáneamente a la PR generada. Si detectan problemas, dejan comentarios directamente en las líneas de código o modifican el código y lo confirman (commitean) en la rama ². En la etapa final, el desarrollador examina de un vistazo los comentarios dejados por los diversos agentes y los resultados de las correcciones automáticas, pulsando finalmente el botón de fusión.

Como resultado, el período de desarrollo de la aplicación Back Pocket de Levi Strauss se redujo de unos 9 meses a 2,5 meses ². Esto no se debe a que la IA haya mejorado la velocidad de codificación humana en sí misma. Es, más bien, el resultado de comprimir estructuralmente el tiempo del proceso al eliminar los tiempos de espera y permitir que cada agente especializado gestione tareas en paralelo. En la era de la compleja colaboración multiagente, garantizar la seguridad en entornos empresariales reside menos en confiar únicamente en la autonomía de la IA y más en proporcionar vías controladas.