Modo "fleet" en GitHub Copilot CLI: guía práctica para lanzar agentes en paralelo

Durante años, la promesa de la IA en el desarrollo fue que te ayudaría a escribir código más rápido. Autocomplete aquí, sugerencia allá... Útil, y aunque nos parecía un avance tremendo en la época, era muy limitado. Pero hoy en día ya no llega con una IA que completa tus frases, sino que hablamos de varios agentes que trabajan para ti en segundo plano en tareas distintas, como un equipo.

Eso es exactamente lo que ofrece el comando /fleet en GitHub Copilot CLI. Es una funcionalidad que te permite lanzar múltiples agentes en paralelo desde la terminal. En lugar de esperar a que un agente termine para empezar el siguiente, los pones a todos a funcionar al mismo tiempo. El resultado puede ser un salto de productividad importante, pero solo en los casos apropiados.

En este artículo te explico qué es, cómo funciona, cómo empezar a usarlo y cómo sacarle partido.

¿Qué es /fleet y por qué existe?

Cuando usas Copilot CLI en modo agente le encargas una tarea y esperas. El agente razona, ejecuta pasos, te devuelve algo. Funciona bien para tareas concretas y acotadas, y muchas veces realmente es lo que vas a necesitar.

Pero a veces te interesa hacer varias cosas a la vez: refactorizar un módulo, escribir test para otro y actualizar la documentación de un tercero. O actualizar varios archivos de documentación en paralelo. Las puedes hacer en secuencia pero, si realmente son independientes, no hay necesidad de que cada una bloquee a la siguiente hasta terminar.

/fleet nace para resolver eso. Te permite definir varias tareas en un solo comando y lanzarlas en paralelo (aunque con cierta coordinación si fuese necesario).

Cada una se ejecuta en su propio subagente, de forma independiente. Tú puedes seguir haciendo otras cosas mientras los agentes trabajan.

Cómo lanzar tu primera flota de agentes con Copilot /fleet

La sintaxis básica es más sencilla de lo que parece.

Dentro de Copilot CLI solo tienes que escribir /fleet seguido de un prompt que describa las tareas que quieres llevar a cabo.

Por ejemplo, desde la terminal en la que tengas abierto Copilot CLI ejecuta, por ejemplo:

/fleet Escribe tests unitarios para el módulo `auth/login.ts`, añade JSDoc a todas las funciones públicas de `utils/helpers.ts` y Genera un `CHANGELOG.md` con los cambios de los últimos 10 commits.

Ya está. No tienes que hacer nada más.

El orquestador que está detrás de esta característica analiza las instrucciones y:

1. Descompone tu tarea en elementos de trabajo discretos con dependencias.

2. Identifica qué elementos pueden ejecutarse en paralelo y cuáles deben esperar.

3. Despacha elementos independientes como subagentes en segundo plano, todos ejecutándose a la vez.

4. Comprueba su finalización y, si es necesario, envía la siguiente oleada.

5. Verifica los resultados y sintetiza los resultados finales.

   O sea, el orquestador analiza lo que le pides y se encarga de todo lo demás. Con este comando, tres agentes arrancan a la vez. Uno escribe tests, otro documenta funciones, otro genera el changelog. En paralelo. Cuando terminan, cada uno te presenta su resultado para que lo revises y decidas si lo aplicas.

   También lo puedes lanzar desde un script o directamente desde la línea de comandos sin entrar en Copilot CLI, usando el modificador -p (para ejecutar un prompt):

copilot -p "/fleet Aquí tu prompt" --no-ask-user

Es necesario añadirle al final el flag --no-ask-user para que pueda funcionar desatendido y no te pida confirmación de nada, ya que de este modo no tienes interfaz para responder a preguntas.

Los subagentes que se crean no pueden comunicarse directamente entre sí: solo el orquestador puede encargarse de su coordinación.

Cada subagente tiene su propia ventana de contexto (o sea, sus instrucciones y respuestas van a parte de los demás), pero comparten el mismo sistema de archivos.

Una cosa importante, que muchas veces no es evidente, es que las tareas que decida crear Fleet van a ser en paralelo por defecto, pero es posible indicarle dependencias entre ellas en el propio prompt. Por ejemplo, si le damos 3 tareas para ejecutar, le podemos decir que las dos primeras se ejecuten en serie, pero las dos últimas pueden ser en paralelo. Al indicárselo explícitamente el orquestador puede ejecutarlas de la manera apropiada.

Algunos consejos para este primer contacto:

• Empieza con 2-3 tareas, no lances 10 de golpe hasta que tengas experiencia con la herramienta.
• Usa tareas con ámbito claro y acotado (un archivo, un módulo, una función).
• Revisa siempre los resultados antes de hacer commit. Los agentes no son infalibles.

Cómo escribir buenos prompts para /fleet

Como casi siempre, la calidad de lo que obtienes depende casi completamente de lo bien que definas cada tarea. Un prompt vago produce un resultado vago, y eso al final se magnifica cuando tienes varios agentes trabajando a la vez.

Algunas reglas a tener en cuenta para lanzar tareas con /fleet son:

• Sé específico con el archivo o módulo: en lugar de "mejora el código", escribe "refactoriza la función fetchUserData en api/users.ts para usar async/await en lugar de callbacks".
• Asegura el acceso exclusivo a los archivos: si dos tareas podrían acceder a la vez al mismo archivo, no uses Fleet o asegúrate de que se van a ejecutar en serie y no en paralelo. Dado que todos los agentes trabajan sobre el mismo sistema de archivos y sin bloqueos, podrías tener problemas grandes al permitir que los dos agentes escriban al mismo archivo. Puede pasar cualquier cosa.
• Haz que los prompts de cada subtarea tengan la info que necesitan: dado que cada subagente se ejecuta de manera independiente y con su propio contexto, si hay datos importantes en tu conversación anterior (antes de /fleet), asegúrate de que la vuelves a poner en el prompt, pues no tendrá acceso a esa conversación anterior.
• Incluye el criterio de éxito cuando puedas: por ejemplo: "escribe tests para cart.service.ts con cobertura de los casos de error" es mucho más útil que "escribe tests para el carrito".

Un prompt bien escrito para un agente de /fleet se parece más a un ticket de Jira bien redactado que a una instrucción de chatbot. Cuanto más concreto, mejor.

Tampoco te olvides de que, una vez lanzado el Fleet puedes mandarle nuevas instrucciones que modifiquen lo que está haciendo en tiempo real. O sea, si empieza a trabajar y no te gusta lo que ves, puedes mandar instrucciones adicionales para cada tarea o incluso pedirle que te informe sobre qué está pasando: Dime qué subagentes están en marcha y en qué estado está cada uno.

Cuándo usar /fleet y cuándo no tiene sentido

El comando /fleet de GitHub Copilot CLI no es la respuesta a todo. Hay situaciones donde aporta mucho y otras donde añade complejidad innecesaria.

Es una herramienta ideal para tareas que pueden dividirse en partes independientes, como realizar cambios en varios archivos a la vez o desarrollar funciones que abarcan distintos niveles del sistema.

Aunque ofrece grandes ventajas para proyectos complejos y paralelos, no es necesario para trabajos sencillos en un solo archivo, donde el uso estándar de Copilot sigue siendo más eficiente (te ahorras el análisis previo, la generación de los subagentes y su coordinación).

Para aprovecharlo al máximo, lo mejor es empezar con tareas pequeñas y claras, aprendiendo a coordinar el trabajo conforme se gana experiencia. En definitiva, su valor real aparece cuando se utiliza para distribuir el esfuerzo en procesos que requieren una ejecución simultánea de una manera natural.

No es para todos los días, pero sí es interesante conocerlo.