Cómo lanzar varios agentes en paralelo

Aprende a dividir tareas complejas entre múltiples agentes que trabajan simultáneamente. Multiplica la velocidad de desarrollo sin sacrificar calidad.

¿Qué son los agentes en paralelo?

Los agentes en paralelo son múltiples instancias de IA ejecutando tareas diferentes al mismo tiempo. En lugar de que un solo agente haga todo secuencialmente (tarea A → tarea B → tarea C), lanzas varios agentes que trabajan simultáneamente (tarea A + tarea B + tarea C a la vez).

El resultado: una tarea que llevaría 30 minutos secuencial se completa en 5-10 minutos con 3-4 agentes paralelos.

¿Cuándo usar agentes en paralelo?

No todas las tareas se benefician del paralelismo. Estas son las que más:

• Features independientes — crear varios componentes de UI que no comparten estado aún
• Refactor por capas — un agente refactoriza modelos, otro controladores, otro tests
• Documentación + código — un agente escribe el código, otro la documentación, otro los tests
• Migración de datos — diferentes lotes de datos migrados en paralelo
• Code review — varios agentes revisan diferentes partes del código simultáneamente
• Análisis de seguridad — un agente audita dependencias, otro busca secretos, otro revisa lógica auth

La regla de oro: si dos tareas pueden hacerse en cualquier orden sin afectarse mutuamente, pueden ejecutarse en paralelo.

Cómo funciona en OpenCode

OpenCode expone la herramienta task que lanza subagentes independientes. Cada subagente tiene su propio contexto, sus propias herramientas y trabaja sin interferir con otros. El flujo es:

• Tú — diseñas el plan y divides el trabajo
• Task tool — lanza los agentes en paralelo
• Subagentes — cada uno ejecuta su tarea con acceso completo a herramientas
• Resultados — vuelven a ti para integración y revisión final

Cada subagente puede leer, escribir y modificar archivos del proyecto. Si dos agentes modifican el mismo archivo, el último en terminar sobrescribe los cambios del primero. Por eso la división del trabajo es clave.

División del trabajo: la clave del éxito

El paso más importante antes de lanzar agentes es dividir el trabajo correctamente. Un buen plan evita conflictos y solapamientos:

1. Identifica archivos independientes

Cada agente debe trabajar en archivos diferentes. Si dos agentes necesitan modificar el mismo archivo, o lo haces secuencial o rediseñas el plan para que uno espere al otro.

// MAL PLAN — dos agentes modifican el mismo archivo
Agente 1: Añadir función login() a auth.ts
Agente 2: Añadir función register() a auth.ts
// → El segundo sobrescribe al primero

// BUEN PLAN — archivos independientes
Agente 1: Crear auth.service.ts (lógica de login)
Agente 2: Crear auth.controller.ts (ruta HTTP)
Agente 3: Crear auth.test.ts (tests)
// → Sin conflictos, trabajan en paralelo

2. Define el contexto de cada agente

Cada subagente necesita saber qué hacer, dónde hacerlo y qué convenciones seguir. Un prompt bien estructurado marca la diferencia:

Prompt débil:
"Crea el componente UserList"

Prompt fuerte:
"Crea el componente UserList en /components/users/UserList.tsx.
Sigue el patrón de UserCard en /components/users/UserCard.tsx.
Usa TypeScript, TailwindCSS, export default function.
Props: users: User[], onSelect: (id: string) => void.
Estados: loading (spinner), empty ("No hay usuarios"), error (mensaje rojo), datos (tabla)."

3. Especifica el formato de salida

Dile al agente qué debe devolver exactamente cuando termine. Así sabrás si cumplió sin tener que leer todo su trabajo:

"/api/users.ts → crear endpoint GET /api/users con paginación"
Cuándo termines, dime:
1. Ruta exacta del archivo creado
2. Qué hace el endpoint
3. Cómo probarlo (curl)

Ejemplo práctico 1: Crear 3 componentes independientes

Tienes que crear Header, Footer y Sidebar para una web. Son componentes independientes que no comparten archivos. El plan:

// Tú le dices a OpenCode:
"Voy a crear 3 componentes de layout. Lanza 3 agentes en paralelo:

Agente 1 — Crea el Header
Archivo: components/layout/Header.tsx
Props: title: string, navItems: NavItem[]
Estilos: sticky top-0 con backdrop-blur, logo a izquierda, nav centrado, avatar a derecha
Estado responsive: menú hamburguesa en mobile

Agente 2 — Crea el Footer  
Archivo: components/layout/Footer.tsx
Props: companyName: string, links: FooterLink[]
Columnas: 4 columnas en desktop, 2 en tablet, 1 en mobile
Año dinámico con new Date().getFullYear()

Agente 3 — Crea el Sidebar
Archivo: components/layout/Sidebar.tsx
Props: items: SidebarItem[], collapsed: boolean
Animación: transición width 300ms entre colapsado/expandido
Iconos de lucide-react

Cada agente: dime al final la ruta del archivo creado."

OpenCode lanza 3 agentes simultáneamente. Cada uno crea su archivo sin saber de los otros. En segundos tienes los 3 componentes listos.

Ejemplo práctico 2: Refactor por capas

Necesitas refactorizar un módulo de autenticación. En lugar de hacerlo secuencial, divides el trabajo por capas:

"Refactoriza el módulo de auth en 3 agentes paralelos:

Agente 1 — Modelos y tipos
Archivos: types/auth.ts, models/User.ts
Lee el schema de BD en database/schema.sql
Define tipos TypeScript e interfaces que reflejen ese schema
Incluye DTOs para login, register, forgot-password

Agente 2 — Servicio y lógica  
Archivos: services/auth.service.ts
Implementa las funciones: login, register, logout, refreshToken, forgotPassword
Usa los tipos del Agente 1 (types/auth.ts)
Inyecta dependencias via constructor

Agente 3 — Tests
Archivo: tests/auth.test.ts
Tests unitarios para login exitoso, login fallido, token expirado, registro duplicado
Usa mocks para el servicio

Todos los agentes: dime qué archivos creaste y qué funciones exportaste."

Ejemplo práctico 3: Feature completa

Una feature real implica frontend + backend + tests. Con agentes en paralelo puedes desarrollar las 3 capas simultáneamente:

"Implementa la feature 'Lista de amigos' en 3 agentes:

Agente 1 — Backend
Archivos: routes/friends.ts, services/friends.service.ts
Endpoints: GET /friends, POST /friends/request, POST /friends/accept
Lee el modelo User y usa los patrones de auth.service.ts
Validación con Zod, errores con HTTP exceptions

Agente 2 — Frontend
Archivos: components/friends/FriendList.tsx, FriendRequest.tsx
Lee el diseño de UserCard.tsx para mantener consistencia
FriendList: tabla con avatar, nombre, email, acciones
FriendRequest: formulario de búsqueda por email + botón enviar
Estados: loading, empty, error, datos

Agente 3 — Tests E2E  
Archivos: tests/friends.test.ts
Tests: enviar solicitud, aceptar, rechazar, listar amigos
Usa fetch y asserts básicos

Usad los mismos tipos/interfaces para la respuesta API:
{ success: boolean, data: any, error?: string }"

Buenas prácticas

• Divide por archivos, no por funciones. Cada agente debe tener sus propios archivos destino. Si dos agentes escriben en el mismo archivo, el último gana
• Define interfaces compartidas de antemano. Si los agentes necesitan tipos comunes, defínelos en el prompt principal para que todos los usen
• Pide un resumen a cada agente. Al final de cada tarea, pide al agente que liste los archivos creados/modificados. Así puedes verificar sin releer todo
• No más de 4-5 agentes por lote. Cada agente gasta tokens y contexto. Más de 5 satura la ventana de contexto del orquestador y reduce la calidad de las respuestas
• Usa nombres de archivo únicos. Si dos agentes crean un archivo llamado utils.ts en diferentes rutas, no hay conflicto. Si lo crean en la misma ruta, sí
• Haz una pasada de integración al final. Después de que todos los agentes terminen, pide a un agente que revise los cambios y unifique estilos, imports y convenciones

Contraindicaciones

El paralelismo no siempre es la mejor opción. Evítalo cuando:

• Las tareas comparten estado mutable. Si dos agentes modifican la misma variable global, base de datos o archivo de configuración
• La tarea es exploratoria. Si no sabes exactamente qué archivos crear o qué solución implementar, un solo agente explorando es más efectivo que varios divergiendo
• El proyecto es muy pequeño. Para cambios de 1-2 archivos, el overhead de lanzar agentes en paralelo no compensa
• Hay dependencias secuenciales estrictas. Si la tarea B necesita el resultado de la tarea A, no puedes paralelizarlas