En resumen: Para ejecutar 10 agentes de programación con IA al mismo tiempo, deja de tratar a cada agente como una terminal a la que debes vigilar. Convierte cada parte del trabajo en una tarea, dale a cada tarea su propia ejecución de agente en un worktree aislado dentro de un Computer conectado, gestiona el seguimiento a través de comentarios en la tarea y permite que los disparadores por eventos inicien las tareas repetitivas. Tu rol es revisar resultados, no supervisar sesiones.
Es totalmente posible ejecutar 10 agentes de programación con IA al mismo tiempo sin tener 10 pestañas de terminal abiertas, y el primer límite con el que te toparás no es el modelo. En su artículo «Exploring Super-agent Design», el equipo de DeepSeek Harness lo expone con total claridad: una persona por lo general solo puede seguir el ritmo de 3 a 5 sesiones activas al mismo tiempo. A partir de ahí, tú te conviertes en el cuello de botella.
Su propuesta es un «superagente»: un coordinador central que interactúa con las personas y distribuye el trabajo a múltiples trabajadores aislados. El artículo describe una arquitectura conceptual, no un producto comercial listo para usar. En esta guía te mostramos una versión simplificada que cualquier equipo puede implementar hoy mismo en un tablero de Sharkly, aprovechando la configuración de Claude Code o Codex con la que ya cuentes.
Una diferencia importante y honesta: el coordinador de DeepSeek es un LLM que decide de forma autónoma quién hace qué. En un tablero, esa decisión la toma una persona, y cada acción deja un registro auditable.
Por qué trabajar con 10 terminales no escala
Gestionar dos o tres agentes de forma manual es viable. Con diez, surgen cuatro problemas al unísono:
- Te conviertes en el enrutador. Cada instrucción, cada confirmación para continuar y cada ajuste posterior tienen que pasar obligatoriamente por ti.
- Los contextos se mezclan. Una corrección pensada para la rama de autenticación termina en la sesión de facturación, o dos agentes editan el mismo checkout de forma simultánea y sobreescriben sus cambios.
- Tu portátil se convierte en el servidor. Si cierras la tapa, todas las sesiones se detienen. Las tareas de larga duración exigen un host que permanezca siempre activo.
- No queda nada documentado. Si una ejecución falla o se desvía, el historial se pierde en el búfer de una terminal que probablemente ya cerraste.
Ya analizamos este impacto en Too Many Terminals. La solución: sacar la coordinación de tu cabeza y trasladarla a un sistema capaz de mantener el estado.
El superagente de DeepSeek adaptado a un tablero de tareas
Cada componente del diseño de DeepSeek cuenta con un equivalente directo en un tablero de gestión de tareas.
| Componente de DeepSeek | Función en el artículo | En un tablero de Sharkly |
|---|---|---|
| Router (Enrutador) | Una sesión de larga duración; interactúa con humanos y distribuye tareas, nunca ejecuta código; un modelo más ligero es suficiente | El tablero junto con la persona que asigna las tareas |
| Workers (Trabajadores) | Una sesión aislada por tarea, utiliza el modelo más potente, nunca interactúa con humanos | Una ejecución de agente por tarea, dentro de su propio worktree |
| Threads (Hilos) | El seguimiento sobre una misma PR o tema de conversación va directo al Worker suscrito | Los comentarios en la tarea reactivan al agente asignado |
| Triggers (Disparadores) | Eventos filtrados primero por código (listas de permitidos) y luego por el modelo (políticas mediante prompts) | Automatizaciones activadas por estado, frases en comentarios, webhooks o programaciones horarias |
| BYOM (Trae tu propio hardware) | El bucle del agente corre en la nube y los entornos en tu propia infraestructura mediante un demonio ligero | Equipos conectados a través de Sharkly Desktop o Sharkly CLI |
| Watchdog (Monitor de control) | Una sesión externa encargada de detectar Workers en bucle o que se desvíen del objetivo | Una revisión programada complementada con el historial de ejecuciones y una validación humana previa |
El filtrado de disparadores en dos fases es un patrón excelente que conviene replicar al pie de la letra. Primero, el código descarta todo lo que puede (repositorio incorrecto, estado no válido) y, solo tras esa validación, el modelo procesa el evento. En un tablero, el disparador actúa como filtro a nivel de código, mientras que las instrucciones de la automatización funcionan como el prompt de política.
Cómo ejecutar 10 agentes de programación con IA en un tablero de Sharkly
No empieces de golpe con diez. Empieza con tres, valida el flujo completo y luego escala progresivamente.
Paso 1: Conecta un Computer y define una concurrencia inicial baja
Un Computer es el host donde se ejecutan tus agentes. Si usas un portátil, instala Sharkly Desktop. Si trabajas con un servidor remoto o una máquina Linux, utiliza la CLI de Sharkly y su servicio local:
# On the remote host, with an install token from the Computers page
sharkly computer register --install-token <install-token>
sharkly daemon status
El servicio local detecta las herramientas instaladas, como Claude Code y Codex, y registra cada una de ellas como un Runtime.
Cada Computer dispone de un límite de tareas concurrentes. Según la documentación de Computers, las ejecuciones en directorios temporales utilizan por defecto el 50% de ese límite, y las tareas adicionales se ponen en cola cuando se alcanza la capacidad máxima. Lo recomendable es empezar con un número conservador: tres ejecuciones paralelas en un único Computer constituyen una buena prueba inicial.
Para tareas de código, utiliza siempre el modo de directorio temporal. Cada ejecución obtiene su propio directorio aislado, y los repositorios pueden trabajar con un git worktree nuevo, evitando así que dos agentes editen la misma copia de trabajo. Si aún no estás familiarizado con los worktrees, te recomendamos leer primero cómo usar git worktrees con agentes de programación con IA.
Paso 2: Crea dos o tres agentes con roles bien diferenciados
Tener diez agentes no significa diseñar diez personalidades distintas. Se trata de definir un número reducido de roles que ejecuten varias tareas en paralelo.
- Constructor (Builder): se encarga de implementar los cambios en el código. Asígnale tu modelo más avanzado, tal como propone DeepSeek para sus Workers.
- Revisor (Reviewer): examina el diff y los criterios de aceptación de la tarea para aportar observaciones.
- Corrector (Fixer): resuelve las pruebas fallidas y atiende los comentarios de la revisión.
Los agentes, Crews y Computers no consumen licencias de usuario, por lo que crear un nuevo rol no supone ningún coste adicional por asiento.
Paso 3: Define tareas completamente autónomas
La mayoría de las configuraciones en paralelo fallan en este punto. Cualquier tarea que dependa de cambios no integrados provenientes de otra tarea acabará bloqueada o generará conflictos.
Redacta cada tarea definiendo con claridad tres elementos: un único objetivo o resultado esperado, los archivos o el módulo sobre los que tiene control, y una comprobación verificable por cualquier persona. Un ejemplo efectivo sería: «Añadir limitación de peticiones (rate limiting) a /api/upload; el comando npm test -- upload pasa sin errores». En cambio, una descripción como «Mejorar la API» resulta ambigua y problemática.
Si dos tareas necesitan modificar el mismo archivo, ejecútalas siempre de manera secuencial.
Paso 4: Asigna la tarea y centraliza el seguimiento en ella
Asigna cada tarea a un agente. Aquellas que se encuentren fuera del Backlog pueden iniciar su ejecución de inmediato; las tareas en el Backlog permanecerán en espera hasta que se trasladen a un estado de preparación (Ready).
Las aclaraciones y solicitudes de cambio deben canalizarse exclusivamente mediante comentarios en la tarea, nunca a través de conversaciones paralelas por chat. Cuando un miembro del equipo comenta en una tarea asignada a un agente, puede desencadenar una nueva ejecución; además, Sharkly agrupa de forma inteligente los comentarios sucesivos para no generar ejecuciones pendientes duplicadas. Este mecanismo materializa el concepto de Thread propuesto por DeepSeek: la conversación permanece indisolublemente vinculada al trabajo en curso.
El uso de una palabra clave predefinida, como /revise, acompañada de las indicaciones del cambio, facilita la identificación inmediata de las solicitudes de ajuste.
Paso 5: Transforma los eventos recurrentes en automatizaciones
Una Automation vincula un conjunto de instrucciones a un agente o Crew mediante uno o varios disparadores. Tal como detalla la documentación de Automations, existen cuatro tipos de disparadores disponibles, además de la ejecución manual mediante «Run now»:
- Programación temporal (Schedule): una expresión cron de cinco campos junto con una zona horaria.
- Estado de la tarea (Task status): se activa cuando una tarea pasa a un estado determinado.
- Frase en comentarios (Comment phrase): se dispara cuando un comentario contiene una frase concreta (sin distinguir mayúsculas de minúsculas).
- Webhook: una URL privada que recibe peticiones POST, con soporte opcional para firma de solicitudes.
Una consideración importante señalada en la documentación: actualmente, la coincidencia por estado o frases en comentarios aplica a nivel de toda la organización y no está limitada a un único Space. Por ello, conviene redactar las instrucciones de modo que el agente inspeccione primero la tarea que activó el evento (su prefijo de título o su Space correspondiente) y detenga su ejecución si no coincide. Este paso representa la segunda fase de filtrado de DeepSeek, articulada directamente mediante un prompt.
Paso 6: Incorpora un monitor de control y un filtro de revisión humana
DeepSeek implementa un Watchdog independiente para identificar Workers que entren en bucle o se aparten del objetivo. Puedes emular este comportamiento con una automatización programada que detecte ejecuciones que sobrepasen con creces su tiempo habitual, apoyándote en los estados de ejecución que registra Sharkly: en cola (queued), en ejecución (running), completada (completed), fallida (failed) o cancelada (canceled).
Asimismo, establece siempre un punto de control humano al final del flujo: un estado de revisión donde una persona valide y apruebe el diff antes de integrarlo. La capacidad de revisión define tu techo operativo real, por lo que te recomendamos leer Human Review Is the Bottleneck antes de escalar más allá de cinco agentes. Para saber qué métricas y señales supervisar durante la ejecución, consulta cómo monitorizar agentes de programación que se ejecutan en paralelo.
Cuánto cuesta ejecutar diez agentes
El coste total se divide en dos conceptos independientes: el consumo de tokens del modelo y la capa de coordinación.
Tokens. Sharkly no comercializa tokens. Las ejecuciones se facturan directamente contra el plan de API, Claude Code o Codex vinculado a cada Runtime. Explicamos detalladamente este enfoque en Por qué una plataforma de agentes no debería venderte tokens.
El paralelismo incrementa el consumo de tokens. Los resultados de las pruebas realizadas por DeepSeek ilustran muy bien este punto. Evaluaron alrededor de 300 mensajes distribuidos en unas 20 solicitudes de trabajo con programación simulada, realizando 5 ejecuciones en cada caso, y presentan estos datos con carácter orientativo.
| Configuración (datos de DeepSeek) | Tiempo de tarea p50 | Tiempo de tarea p95 | Tokens leídos de caché por ejecución |
|---|---|---|---|
| Superagente | 12,4 min | 15,7 min | 23,2 M |
| Sesión individual con subagentes y prompt neutral | 20,4 min | 29,5 min | 6,1 M |
| Sesión individual con subagentes y prompt centrado en delegación | 13,8 min | 29,0 min | 10,8 M |
En el caso de la sesión con prompt neutral, el sistema no delegó ni una sola vez a lo largo de cinco ejecuciones. La contrapartida es evidente: se consumen más tokens a cambio de obtener tiempos de resolución sensiblemente más cortos y predecibles. Nosotros no replicamos estas pruebas de forma independiente.
La plataforma. A fecha de 4 de noviembre de 2026, la página de precios de Sharkly indica que la plataforma es gratuita para organizaciones de hasta 5 integrantes. El plan Team tiene un precio de 7 $ por persona al mes con facturación anual. Los asientos aplican exclusivamente a usuarios humanos.
Casos de uso ideales para este patrón
- Reducción de backlog técnico: resolución de veinte incidencias pequeñas e independientes, cada una con su propia tarea y un flujo de constructor más revisor.
- Corrección de pruebas tras una actualización: una tarea por cada paquete con pruebas rotas, ejecutándose cada una en su propio worktree.
- Sincronización simultánea entre código y documentación: un disparador por estado que activa a un agente de documentación en cuanto una tarea de funcionalidad pasa a revisión.
- Colas de trabajo nocturnas: procesamiento de tareas en un Computer remoto siempre activo para que puedas revisar los resultados a primera hora de la mañana.
Si deseas comparar los diferentes entornos donde pueden operar tus agentes, el artículo Codex Cloud frente a tus propios Computers analiza las ventajas de cada opción.
Comienza con tres
Llegar a diez agentes en paralelo es la meta, no el punto de partida. Conecta un primer Computer, configura un constructor y un revisor, define tres tareas con resultados claramente verificables y asígnalas. Supervisa un ciclo completo: ejecución, comentarios, ajustes y revisión final. Cuando ese flujo funcione de manera predecible y fluida, incrementa la concurrencia en dos tareas y añade tu primera automatización.
Preguntas frecuentes
¿Cuántos agentes de programación con IA puede gestionar una sola persona?
El equipo de DeepSeek sitúa el límite práctico entre 3 y 5 sesiones activas cuando debes supervisar cada una manualmente. Es posible gestionar un número mucho mayor si el trabajo se estructura como tareas con resultados definidos por escrito, ya que pasarás a revisar entregables en lugar de monitorear sesiones en tiempo real.
¿Puedo ejecutar varios agentes de Claude Code en el mismo repositorio?
Sí, siempre que cada ejecución opere en su propio directorio. El modo de directorio temporal asigna a cada tarea un espacio de trabajo aislado, y las ejecuciones sobre repositorios pueden crear un git worktree nuevo e independiente, evitando que agentes concurrentes pisen sus modificaciones.
¿Qué ocurre si asigno más tareas de las que mi Computer puede procesar?
Las tareas sobrantes se colocan en cola. Cada Computer cuenta con un límite de concurrencia, y las ejecuciones arrancan a medida que se libera capacidad. Una tarea en cola también aguardará si el Computer no está en línea o si su Runtime no se encuentra disponible.
¿Necesito un servidor en la nube para ejecutar agentes en paralelo?
No necesariamente. Puedes utilizar tu propio portátil como Computer instalando Sharkly Desktop. Para ejecuciones prolongadas o durante la noche, conectar un servidor remoto o un equipo Linux mediante la CLI de Sharkly garantiza que el procesamiento continúe aunque tu portátil entre en suspensión.
¿Un tablero equivale exactamente al superagente de DeepSeek?
No exactamente. El Router de DeepSeek es un LLM que toma decisiones de asignación de forma autónoma. En un tablero, la asignación de tareas recae en una persona, mientras que las automatizaciones se encargan de gestionar los eventos y flujos repetitivos.
