Una sesión de Gemini CLI es un único agente trabajando en un directorio. En cuanto quieres que una segunda tarea avance al mismo tiempo —corregir un bug mientras se ejecuta un refactor, escribir tests mientras se integra una funcionalidad—, abres otra terminal. Y luego una tercera. En una hora tienes cuatro pestañas, cuatro directorios de trabajo y ninguna respuesta clara a una pregunta sencilla: qué agente está haciendo qué y cuál acaba de tocar el archivo que estabas a punto de editar.
Lanzar varias tareas de Gemini a la vez no es difícil de arrancar. Lo difícil es no perder el hilo. Cada instancia es rápida por sí sola; el coste está en la coordinación, y la coordinación es justo lo que la terminal nunca te da.
Este artículo repasa la configuración manual para agentes de Gemini CLI en paralelo, señala el modo de fallo que acecha en cada paso y muestra en qué punto entra en juego un tablero de tareas. Ese tablero de tareas es Sharkly, una plataforma todo en uno para dirigir y gestionar Agentes. Sharkly no sustituye a Gemini CLI. Añade la capa compartida de tareas, Computer, contexto y revisión alrededor de los runtimes que tu equipo ya utiliza, de modo que las ejecuciones en paralelo sigan siendo asignables y trazables en lugar de quedar repartidas entre pestañas.
Qué significa «agentes en paralelo» con Gemini CLI
Gemini CLI ejecuta un agente por proceso. Lee el directorio actual, carga el archivo de contexto GEMINI.md si existe y resuelve tu prompt en ese único árbol de trabajo. No hay ningún despachador integrado que reparta un objetivo entre varios subagentes y te devuelva el trabajo fusionado.
Así que, en la práctica, «agentes Gemini en paralelo» significa una sola cosa: varios procesos de gemini ejecutándose a la vez, cada uno en su propio entorno aislado y con su propia tarea. Gemini CLI es de código abierto y se puede usar gratis con una cuenta personal de Google, y por eso precisamente mucha gente levanta cuatro a la vez. El cuello de botella nunca fue arrancarlos, sino evitar que cuatro ejecuciones independientes choquen en el mismo repositorio y saber, una hora después, qué produjo cada una.
Es el mismo problema de coordinación que aparece con Claude Code o Codex. Cambia el runtime; el caos, no.
La configuración manual, paso a paso
Esta es la versión mínima que funciona de Gemini CLI en paralelo, junto con lo que se rompe en cada paso.
Paso 1: dale a cada agente su propio árbol de trabajo. No ejecutes dos agentes en la misma carpeta. Usa un git worktree por tarea para que cada checkout sea físicamente independiente:
git worktree add ../repo-auth feature/auth
git worktree add ../repo-tests chore/tests
git worktree add ../repo-bugfix fix/login-redirect
Qué falla si te lo saltas: dos agentes editando el mismo checkout se sobrescriben entre sí a mitad de ejecución. Uno reformatea un archivo que el otro tiene a medias y ambos dejan el árbol en un estado que ninguno de los dos pretendía. Los worktrees dan a cada agente una rama limpia y un directorio limpio. Profundizamos en ello en git worktrees para agentes de programación con IA.
Paso 2: arranca un Gemini CLI por worktree. Abre una terminal en cada directorio e inicia una sesión:
cd ../repo-auth && gemini
Para ejecuciones sin supervisión, usa el modo no interactivo para que el agente reciba un único prompt y termine:
cd ../repo-tests && gemini -p "Add unit tests for the session module. Run the suite before finishing."
Qué falla: una sesión interactiva se detiene en la primera petición de permiso y se queda esperando. Vuelves veinte minutos después y te encuentras con un agente que no ha hecho nada porque necesitaba un «sí». Decide de antemano qué ejecuciones son interactivas y cuáles son headless, y dale a las headless un prompt que incluya su propio paso de verificación.
Paso 3: aísla el contexto por tarea. Cada worktree puede llevar su propio GEMINI.md con las reglas de esa tarea: qué tocar, qué dejar en paz y cómo ejecutar los tests.
Qué falla: un único archivo de contexto compartido entre todos los agentes hace que una instrucción pensada para la tarea de autenticación se cuele en la tarea de tests. Limita el contexto al árbol al que pertenece.
Paso 4: vigila la cuota. Todas las instancias en ejecución consumen los mismos límites de la cuenta. Cuatro agentes devorando un refactor grande alcanzan los límites de peticiones antes que uno solo, y un agente limitado falla en silencio en una pestaña que no estás mirando.
Qué falla: una ejecución se atasca por un error de cuota y no te enteras hasta que miras esa pestaña. No hay ninguna vista compartida que te avise de que un agente se ha detenido. Si estás emparejando las tareas más pesadas con el modelo adecuado, qué modelo para cada tarea de programación cubre ese equilibrio.
Con tres o cuatro tareas, esto funciona. Ramas reales, aislamiento real, paralelismo real y ninguna herramienta adicional.
Dónde deja de escalar la configuración por tu cuenta
La configuración manual no se rompe en la ejecución, sino en todo lo que la rodea. Fíjate en lo que ocurre a medida que aumentan las tareas.
Pierdes el mapa. Con cuatro terminales puedes mantenerlo todo en la cabeza. Con ocho, repartidas en dos repositorios, ya no. ¿Qué pestaña es la del agente de autenticación? ¿La ejecución de tests terminó o murió por un error de cuota? Monitorizar agentes de programación en paralelo es un trabajo para el que la terminal nunca se diseñó.
Los resultados se dispersan. Cada agente deja su trabajo como un diff en una rama y un muro de scrollback en una pestaña que acabarás cerrando. No hay un registro compartido de qué cambió cada ejecución, por qué, ni si superó sus propios tests. Cuando un compañero pregunta qué hizo la corrección del login, la respuesta vive en una terminal que ya no existe.
La revisión no tiene dónde alojarse. Los agentes en paralelo producen diffs en paralelo, y cada uno sigue necesitando que una persona lo acepte. Leer cuatro ramas sin resumen, sin resultados de verificación y sin contexto es más lento de lo rápidos que fueron los agentes. La velocidad que ganaste en la ejecución la devuelves en la revisión.
Aquí va el par de decisiones honesto. Si lanzas tres o cuatro tareas de Gemini de vez en cuando, quédate con la configuración de worktrees de arriba: es sencilla, funciona, y un tablero de tareas solo sería una carga innecesaria. Plantéate uno cuando las ejecuciones en paralelo se vuelvan lo habitual: varios agentes, más de un repositorio, más de una persona que necesita ver el progreso y una revisión que debe ser trazable en lugar de recordada. En ese momento merece la pena comparar las herramientas que gestionan agentes en paralelo.
Qué aporta un tablero de tareas
Un tablero de tareas cambia la unidad de trabajo: de «una pestaña de terminal» a «una Tarea». Ese único cambio es lo que le falta a la configuración por tu cuenta.
Con Sharkly, asignas una Tarea a un Agente respaldado por Gemini CLI. El Agente reclama la Tarea, trabaja en un worktree aislado, y la ejecución, los bloqueos, los resultados y los comentarios posteriores vuelven a la línea temporal de la Tarea en lugar de desaparecer en terminales privadas. Ejecuta varias a la vez y cada una será una fila que puedes ver, no una pestaña que tienes que buscar. Gemini CLI sigue escribiendo el código; Sharkly gestiona la asignación, los Computers conectados, el contexto y la revisión de todas las ejecuciones.
El reparto de trabajo se mantiene claro. Los agentes investigan, ejecutan, prueban y reportan. Las personas marcan el rumbo, conceden autoridad y aceptan el resultado. La automatización se detiene donde se requiere el criterio del equipo, y cada ejecución vuelve con un resumen de cambios y sus propios resultados de verificación, de modo que aceptar o rechazar un diff es cuestión de un vistazo y no de una excavación arqueológica. El contexto, el progreso, los bloqueos, los resultados y la revisión humana permanecen visibles desde la petición hasta el lanzamiento.
Conservas lo que ya tienes. Sharkly no te pide que abandones Gemini CLI ni que te comprometas con un único runtime. Como es neutral respecto al proveedor, el mismo tablero de tareas ejecuta agentes de Claude Code y Codex junto a los de Gemini, así que tu flujo de trabajo sobrevive a cualquiera que sea el próximo gran agente que aparezca. Esa neutralidad es la clave: gestionas tus agentes en un único sitio, sin cambiar de ecosistema cada vez que sale uno nuevo.
La checklist que puedes aplicar hoy mismo
Repasa esto antes de tu próximo lote de tareas de Gemini en paralelo:
- [ ] Un git worktree por tarea; nunca dos agentes en el mismo checkout.
- [ ] Un
GEMINI.mdacotado a cada tarea, no un único archivo compartido entre todas. - [ ] Las ejecuciones headless usan
gemini -pcon un paso de verificación integrado para que no se atasquen esperando una confirmación. - [ ] Un límite conocido de instancias concurrentes para que la cuota compartida no frene una ejecución que no puedes ver.
- [ ] Un único lugar que responda a «qué agente está con qué y qué ha terminado» sin abrir todas las pestañas.
- [ ] Cada ejecución completada deja un resumen de cambios y resultados de tests que una persona puede revisar, no solo un diff en una rama.
Los cuatro primeros puedes cubrirlos esta misma noche con worktrees y terminales. Los dos últimos son donde se agota la configuración manual. Si ya ejecutas varios agentes de Gemini CLI a la vez, Sharkly te da un único lugar donde asignar sus tareas, seguir su progreso y revisar sus resultados. Puedes construirte tú mismo la capa de coordinación o ejecutar tus agentes de programación actuales a través de Sharkly y pasar directamente a la parte que escala.
