Empiezas con una terminal y Claude Code. Luego llega una segunda tarea, así que abres otra terminal y lanzas Codex en ella. Un arreglo de frontend va a una tercera. Ahora estás saltando entre tres ventanas con Alt+Tab, intentando recordar cuál te está esperando, cuál hizo una pregunta hace diez minutos y cuál terminó en silencio y está ahí sin hacer nada mientras tú quemas atención en las otras dos. Nada está en llamas. Pero te has convertido en la pieza que enruta el trabajo entre los agentes, y ese trabajo escala peor que cualquiera de ellos.
Las terminales no son el costo. Tú lo eres. Cuando los agentes se ejecutan a mano, cada decisión sobre lo que pasa después vive en un solo lugar: tu cabeza. Qué agente recibe la siguiente tarea, si el último diff es seguro, qué falló mientras leías otra ventana. Esa coordinación es trabajo real, no está remunerado y crece más rápido que el número de agentes que añades.
Este artículo desglosa lo que realmente cuesta ejecutar agentes de programación a mano, dónde se esconde la factura hasta que se acumula, y el flujo de trabajo que elimina la mayor parte de ese costo. Sharkly es la capa de gestión que se sitúa por encima de tus agentes: conservas Claude Code, Codex o el entorno de ejecución que ya uses, y Sharkly mantiene las tareas, el aislamiento y la revisión en un único lugar compartido en vez de repartidos por un muro de terminales.
Resumen
Ejecutar agentes de programación a mano parece gratis porque ninguna herramienta cobra por ello. El costo real es tu atención: te conviertes en el enrutador entre agentes, en la memoria de lo que hace cada uno y en el único revisor que tiene que ponerse al día con cada ventana. Ese costo se mantiene bajo con dos o tres agentes y se dispara a partir de cinco. Puedes seguir haciéndolo manualmente o enrutar tus agentes actuales a través de una capa de tareas como Sharkly que asigna el trabajo, aísla cada ejecución y devuelve cada resultado a una Tarea para su revisión.
El problema no son las terminales, eres tú
Aquí va una definición que merece la pena recordar: una terminal es donde se ejecuta un agente; una tarea es el trabajo sobre el que se ejecuta. Cuando gestionas agentes a mano, nada conecta ambos conceptos excepto tú. La terminal muestra la salida. No sabe cuál era la tarea, si está terminada ni quién decide qué pasa después. Tú aportas todo eso de memoria, ventana a ventana.
Por eso «demasiadas terminales» es un síntoma, no la enfermedad. Dividir un agente en cinco paneles con tmux no reduce la coordinación; solo la reorganiza. Sigues manteniendo el mapa de qué panel posee qué tarea, cuál está en ejecución y cuál terminó y necesita que una persona lo revise. El mapa no vive en ningún lugar compartido, así que en el momento en que te alejas se queda obsoleto, y en el momento en que un compañero lo necesita, no existe.
Lo que realmente cuesta ejecutar agentes a mano
La factura se paga en atención, y la atención tiene un precio medible. Cuando alternas entre tareas no relacionadas, no retomas al instante. La investigación sobre trabajo de conocimiento interrumpido de Gloria Mark y sus colegas, publicada en CHI 2008, descubrió que las personas tardan una media de más de veinte minutos en volver a una tarea interrumpida después de que las aparten de ella. El resumen de la American Psychological Association sobre la investigación del cambio de tarea sitúa la pérdida de productividad por alternar entre tareas en hasta un 40 por ciento. Cada vez que un agente termina y giras hacia otra ventana, pagas alguna versión de ese impuesto.
Ejecutar agentes a mano convierte ese cambio en tu bucle principal. Aquí es donde se acumula el costo:
| Costo oculto | A qué se parece cuando se hace a mano | Por qué se acumula |
|---|---|---|
| Enrutamiento | Decides qué agente recibe cada nueva tarea, de memoria | Más agentes significa más emparejamientos que retener en la cabeza |
| Recarga de contexto | Vuelves a leer cada terminal para recordar qué estaba haciendo | Cada cambio reinicia el reloj para volver a entrar en esa tarea |
| Deriva de estado | Cada terminal lleva su propia rama, entorno y ediciones a medias | Dos tareas en un mismo directorio se corrompen en silencio mutuamente |
| Acumulación de revisiones | Eres el único que vio ocurrir cada ejecución | El trabajo terminado espera a la única persona que puede revisarlo |
| Sin registro compartido | El estado vive en tu sesión, no en un lugar que un compañero pueda ver | Si te alejas, el progreso se vuelve invisible; nadie puede retomarlo |
Ninguno de estos problemas se manifiesta como un fallo. Se manifiestan como un día que pareció ajetreado y produjo tres PR fusionados en lugar de ocho, sin un momento concreto que puedas señalar como el problema.
Los modos de fallo se esconden hasta que se acumulan
Con dos agentes, puedes mantener todo el mapa en la memoria de trabajo y el costo es casi nulo. Merece la pena decirlo claramente, porque es donde la mayoría de los consejos exageran el problema: si ejecutas uno o dos agentes en una sola máquina y revisas cada uno antes de empezar el siguiente, todavía no necesitas una capa de gestión. Mantén las piezas móviles en cero.
La ecuación cambia cuando el trabajo se solapa en el tiempo o en el estado. Ejecuta tres agentes en el mismo checkout y te toparás con el problema de aislamiento que se trata en varios agentes de programación en el mismo repositorio: dos agentes tocan los mismos archivos y uno sobrescribe al otro en silencio. Resuélvelo con un worktree por tarea, la disciplina que se explica en worktrees para agentes de programación, y cambias un problema de fusión por un problema de contabilidad: qué directorio corresponde a qué tarea, cuál es seguro eliminar, cuál está revisando una persona en ese momento. Resuélvelo con más terminales y vuelves al punto de partida, solo que con más ventanas.
El último costo es el silencioso. Cuando cada ejecución ocurre en una terminal privada, el trabajo terminado no tiene otro destino que tu atención. La revisión se convierte en el cuello de botella, porque eres la única persona que vio trabajar al agente y la única que puede decir si el diff es bueno. Los agentes en paralelo no ayudan si revisar su salida se serializa en una sola persona. Esa es la trampa que se describe en por qué el mejor agente de programación importa menos que cómo los gestionas: el modelo se volvió más rápido, y tu cola de revisión no.
Qué elimina la capa de gestión
Un tablero de tareas elimina la parte que hacías a mano: ser el tejido conectivo entre los agentes y el trabajo. En Sharkly, la Tarea es la unidad que posee la ejecución. Asignas una Tarea a un Agente, y Sharkly prepara un worktree aislado para ella en una Computadora conectada, ejecuta allí la sesión del agente y devuelve el diff, los registros y cualquier bloqueo a esa Tarea. El enrutamiento, el aislamiento y el registro que mantenías en la cabeza pasan a ser propiedades de la Tarea.
Eso mantiene limpia la división del trabajo. Los agentes investigan, ejecutan, prueban e informan; las personas marcan la dirección, conceden autoridad y aceptan el resultado. Sharkly no sustituye a Claude Code, Codex ni al entorno de ejecución que ya uses; esos se encargan de la ejecución. Añade la tarea compartida, la Computadora conectada y la capa de revisión a su alrededor, para que el contexto, el progreso, los bloqueos, los resultados y la revisión humana permanezcan visibles desde la solicitud hasta el lanzamiento en lugar de dispersarse por cinco sesiones que solo tú puedes ver. Cuando necesitas observar varias ejecuciones a la vez, para eso sirve realmente un panel de control de agentes, y es la razón por la que los equipos acaban queriendo la capa por encima de Claude Code y Codex en vez de otra terminal.
Si ya ejecutas varios agentes, ese es el flujo de trabajo en torno al cual está construido Sharkly. Puedes seguir enrutando a mano entre terminales, o ejecutar tus agentes de programación actuales a través de Sharkly y dejar que el tablero se encargue del mapa.
Cuándo está bien hacerlo a mano y cuándo no
La regla de decisión honesta es breve:
- Ejecuta los agentes a mano cuando tengas uno o dos, en una sola máquina, y revises cada uno antes de que empiece el siguiente. La sobrecarga de cualquier herramienta aún no merece la pena.
- Pasa a una capa de tareas cuando aparezca un tercer agente, el trabajo abarque más de un repositorio o alguien distinto de ti necesite ver qué se está ejecutando. Ese es el punto en el que el costo de coordinación deja de caber en la cabeza de una persona.
La señal no es el número de terminales. Es el momento en que te sorprendes preguntándote «espera, ¿en qué ventana estaba eso?». Esa pregunta es el impuesto de coordinación manifestándose como una frase, y es el mismo caos de agentes que un tablero de tareas existe para acabar.
Preguntas frecuentes
¿No basta con tmux o un multiplexor de terminales? Organiza las ventanas; no elimina la coordinación. Sigues manteniendo qué panel posee qué tarea, qué terminó y quién lo revisa. Un multiplexor resuelve el espacio en pantalla. El costo de ejecutar agentes a mano es la atención, no los píxeles.
¿Cuántos agentes puedo ejecutar a mano antes de que duela? La mayoría de las personas está bien con uno o dos y empieza a notarlo en torno a tres o cinco, sobre todo si abarcan más de un repositorio. El número exacto depende de cuánto dura cada tarea y cuánta revisión necesita. La señal es cuando enrutar y releer ventanas ocupa más de tu día que la revisión en sí.
¿Un tablero de tareas hace más rápidos a mis agentes? No, y Sharkly no lo afirma. Los agentes se ejecutan a la misma velocidad. Lo que cambia es tu sobrecarga: el enrutamiento, el aislamiento y la revisión dejan de vivir en tu cabeza y empiezan a volver a una Tarea donde el trabajo es visible y revisable.
¿Y mantener el contexto entre sesiones? Las terminales privadas lo pierden en el momento en que las cierras. Vincular una ejecución a una Tarea mantiene juntos el objetivo, el diff y la discusión, que es el problema de mantener el contexto entre sesiones resuelto a nivel de registro en lugar de con la memoria.
¿Puedo seguir usando Claude Code y Codex juntos de esta forma? Sí. Sharkly gestiona el trabajo en torno a las herramientas; no las sustituye. Consulta cómo ejecutar Claude Code y Codex juntos para ver el patrón.
