Claude Squad vs Conductor vs tmux: configuraciones de agentes DIY

Empezaste ejecutando dos agentes de código a la vez porque uno solo era demasiado lento. Ahora ejecutas cinco, y lo difícil no es lanzarlos. Lo difícil es recordar qué terminal tiene a qué agente, qué cambió cada uno, qué rama es segura para fusionar y si el que se quedó callado hace cuarenta minutos terminó o se quedó atascado. El paralelismo fue la victoria fácil. Mantenerlo bajo control es el impuesto que pagas todos los días después.

Ese impuesto es lo que intentan reducir las herramientas DIY para agentes en paralelo. Conductor, Claude Squad y los scripts caseros de tmux más git worktree resuelven todos el mismo primer problema: darle a cada agente su propio espacio de trabajo aislado para que varias ejecuciones avancen al mismo tiempo sin pisarse los archivos entre sí. Lo resuelven bien, y para un desarrollador en solitario en una sola máquina pueden ser todo lo que necesitas. Esta es una comparativa honesta de qué hace cada una, dónde se detiene cada una y la línea en la que la gestión de ventanas se convierte, sin ruido, en un problema de equipo.

Esa línea es donde entra Sharkly, y es el flujo de trabajo que este artículo te guía a recorrer. Sharkly no reemplaza a Claude Code, Codex ni a ningún runner DIY. Es la capa compartida de Tareas, Computadoras, contexto y revisión que rodea a las herramientas que ya usas, para que el trabajo de los agentes siga visible desde la solicitud hasta el lanzamiento en lugar de desaparecer en terminales privadas. Si tu configuración todavía cabe en una pantalla, quédatela. Si dejó de caber hace semanas, la segunda mitad de este artículo es para ti.

TL;DR

Conductor, Claude Squad y tmux puro más git worktrees son tres formas de ejecutar varios agentes de código con IA en paralelo en tu propia máquina. Conductor es una app gratuita para Mac diseñada para ejecuciones locales en solitario. Claude Squad es una app de terminal multiplataforma que añade un conmutador sobre sesiones de tmux y git worktrees. Tmux puro más scripts de worktree te dan control total y cero abstracción. Las tres dominan la ejecución en paralelo. Ninguna se diseñó para dar a un equipo visibilidad compartida, revisión o traspasos, y ese es exactamente el punto en el que das el salto a una capa de orquestación como Sharkly.

El verdadero cuello de botella no es el paralelismo

El aislamiento es un problema resuelto. Un git worktree permite que un repositorio haga checkout de varias ramas en directorios separados a la vez, de modo que cada agente edita su propia copia del código y hace commit en su propia rama. Sin árbol de trabajo compartido, sin diffs a medio aplicar que chocan entre sí. Todas las herramientas de esta comparativa se apoyan en esa misma primitiva. Si quieres conocer la mecánica a fondo, nuestra guía sobre git worktrees con agentes de código con IA cubre los comandos y los inconvenientes.

Entonces, si el aislamiento es gratis, ¿por qué ejecutar muchos agentes sigue sintiéndose caótico? Porque el trabajo que produce un agente tiene que ir a algún sitio donde un humano pueda encontrarlo, leerlo, juzgarlo y actuar en consecuencia. En una sola máquina, ese «algún sitio» es tu propia memoria a corto plazo más un búfer de scroll. Eso aguanta con dos agentes. Se deshilacha con cinco. Y se rompe en el momento en que una segunda persona necesita saber qué hizo alguno de tus agentes.

Aquí está la división que importa. Ejecutar agentes en paralelo es un problema de tiempo de ejecución: lanza el proceso, dale un directorio aislado, déjalo trabajar. Revisar y coordinar lo que producen es un problema de flujo de trabajo: dónde vive el resultado, quién lo acepta, qué pasa con los que se atascan. Las herramientas DIY son excelentes para el primer problema. Las tres secciones siguientes juzgan cada una según sus propios términos, y después veremos qué le ocurre al segundo problema a medida que crece tu configuración.

Conductor: la app gratuita para Mac para ejecuciones paralelas en solitario

Conductor es una app de escritorio nativa para Mac que ejecuta varios agentes de Claude Code en paralelo. La apuntas a un repositorio, describes un cambio y lanza cada ejecución en su propio espacio de trabajo respaldado por un git worktree. En lugar de hacer malabares con pestañas de terminal, obtienes una vista en ventanas: una columna por agente, cada una con su propia conversación, diff y estado. Pasas de una a otra igual que pasarías de un chat a otro.

Lo que hace bien es eliminar la contabilidad de terminales para una sola persona. No escribes nada de tmux. No recuerdas qué panel es cuál. La app rastrea los worktrees, te muestra los diffs en un visor de diffs de verdad y te deja saltar entre agentes sin perder el hilo. Para un desarrollador en solitario en un Mac que quiere ejecutar tres o cuatro sesiones de Claude Code sobre una misma base de código sin volverse loco, es una respuesta limpia y de baja fricción. Es gratis de descargar y no hay nada que configurar en un servidor porque no hay servidor.

Los límites son la otra cara de esas fortalezas. Conductor es exclusivo de macOS, así que un compañero de equipo en Linux no puede compartir tu configuración. Está construido en torno a Claude Code como tiempo de ejecución, no a una mezcla de agentes. Y es una app de escritorio monousuario: los espacios de trabajo, los diffs y las decisiones viven en tu Mac. Otro ingeniero no puede abrir tu Conductor y ver qué están haciendo tus agentes, y no hay un registro compartido de quién aceptó qué cambio. Eso no es un defecto. Es un alcance. Conductor es una cabina para un solo piloto.

Usa Conductor cuando seas un desarrollador en solitario en un Mac ejecutando Claude Code y quieras el camino más rápido de «muchas terminales» a «una ventana tranquila». Busca otra cosa cuando una segunda persona necesite ver, revisar o hacerse cargo de alguna de esas ejecuciones.

Claude Squad: tmux y worktrees con una TUI encima

Claude Squad es una aplicación de terminal de código abierto que gestiona varios agentes en espacios de trabajo aislados. Por debajo hace lo que un ingeniero cuidadoso escribiría a mano en un script: crea un git worktree por agente y ejecuta cada agente dentro de su propia sesión de tmux, y luego pone encima una interfaz de texto para que puedas listar tus agentes, entrar en cualquiera de ellos y ver cuáles están trabajando, esperando o han terminado. Es multiplataforma, funciona en macOS y Linux, y no está atada a un único tiempo de ejecución. Puede controlar Claude Code, Codex, Aider y otros agentes de CLI, lo que la convierte en la favorita de los desarrolladores que mezclan herramientas. El código fuente está en el repositorio de Claude Squad en GitHub.

Lo atractivo es que te da la ergonomía de una herramienta de verdad sin ocultar las primitivas en las que confías. Sigues teniendo worktrees y tmux, así que nada es magia y todo es inspeccionable, pero dejas de escribir el pegamento a mano. Levantar un nuevo agente es una pulsación de tecla, no un ritual de tres comandos. Pausar un agente libera sus recursos y conserva su rama. Si ya vives en la terminal y quieres una flota de agentes por la que ir tabulando, Claude Squad acierta en un punto dulce que los scripts puros y las apps de escritorio no alcanzan. Nuestro tutorial sobre cómo ejecutar varios agentes de Claude Code en paralelo muestra el mismo patrón de tmux y worktree que esta herramienta automatiza.

Sus límites son los límites de la terminal en la que vive. El estado es local a tu máquina y a tu shell. Cuando cierras la sesión, la imagen compartida se cierra con ella. No hay una línea de tiempo que un manager pueda abrir, ni un lugar donde un revisor que no seas tú pueda aceptar o rechazar un cambio, ni una cola de la que un compañero pueda sacar la siguiente tarea. Claude Squad es un centro de mando magnífico para un solo operador. Nunca intentó ser el sistema de registro de un equipo, y pedirle que lo sea es pedírselo a la herramienta equivocada.

Usa Claude Squad cuando seas un desarrollador que vive en la terminal, ejecute una mezcla de agentes en una máquina y quiera un conmutador rápido sin renunciar a los worktrees y a tmux. Busca otra cosa cuando las ejecuciones deban poder asignarse a otras personas o revisarse por alguien que no esté sentado a tu teclado.

Tmux puro más git worktrees: los scripts que tú controlas

La configuración DIY más honesta es también la más antigua: unos cuantos scripts de shell que crean worktrees y abren ventanas de tmux, una por agente. Tiene esta pinta.

# one worktree and one branch per parallel unit of work
git worktree add ../app-auth    -b feature/auth
git worktree add ../app-billing -b feature/billing

# a named tmux window per agent, launched in its worktree
tmux new-window -n auth    -c ../app-auth    'claude'
tmux new-window -n billing -c ../app-billing 'claude'

Dos comandos por funcionalidad y ya tienes agentes aislados ejecutándose en paralelo, cada uno en su propia rama, cada uno en una ventana etiquetada a la que puedes saltar con una pulsación de tecla. Envuélvelo en un bucle y puedes lanzar una docena. Nada se interpone entre tú y las herramientas. Puedes leer cada línea, cambiar cualquiera de ellas y no cuesta nada más que el tiempo de escribirlo.

Para cierto tipo de desarrollador esta es la respuesta correcta para siempre, y merece respeto en lugar de intentar disuadir a nadie de ella. Entiendes exactamente qué se ejecuta porque lo escribiste tú. No hay proveedor, ni una actualización que rompa tu flujo, ni una abstracción que se filtre en el momento equivocado. Si tus necesidades son estables y personales, los scripts que controlas superan a las herramientas que alquilas.

El coste aparece a medida que crece tu configuración, y aparece en forma de mantenimiento, no de funcionalidades. La limpieza depende de ti: los worktrees obsoletos se acumulan hasta que git worktree prune y un barrido con tmux kill-session se vuelven parte de tu rutina. Las colisiones de nombres dependen de ti. Un agente que se cae deja una ventana muerta y una rama a medio terminar, y darse cuenta de eso depende de ti. Y nada de eso sale de tu máquina, así que en el momento en que un compañero pregunta «qué entregaron tus agentes esta semana», la única respuesta vive en tu búfer de scroll. Los scripts escalan tu rendimiento. No escalan tu capacidad de compartir el resultado.

Usa tmux puro y scripts de worktree cuando quieras control total, disfrutes siendo dueño de tus herramientas y el público del trabajo seas tú. Busca otra cosa cuando te descubras reconstruyendo el seguimiento de estado, la limpieza y la lógica de traspaso que empieza a parecerse a un producto que no pretendías escribir.

Comparativa: qué hace bien cada configuración DIY

Las dos últimas filas no son una crítica. Son el patrón. Cada una de estas herramientas está construida para un solo operador en una sola máquina, y dentro de ese alcance van de buenas a excelentes. La columna vacía es la misma en las tres, y es la columna que importa el día en que el trabajo deja de ser solo tuyo. Para un mapa más amplio de la categoría, consulta nuestra visión general de la orquestación de agentes de IA.

La línea de graduación: cuando la gestión de ventanas deja de ser el problema

Aquí está la señal. Dejas de preguntar «cómo ejecuto más agentes a la vez» y empiezas a hacer preguntas que las herramientas DIY no pueden responder:

• ¿Quién ha revisado los cambios de mis agentes?
• Si estoy de baja, ¿puede un compañero ver qué está en marcha y hacerse cargo?
• ¿Dónde está el registro de por qué aceptamos este diff y rechazamos aquel?
• ¿Qué ejecuciones están bloqueadas, por qué y desde cuándo?

Esas son preguntas de flujo de trabajo, no de tiempo de ejecución. Ningún conmutador mejor ni un visor de diffs más bonito las responde, porque la pieza que falta no está en tu pantalla. Es un lugar compartido donde viva el trabajo. Esta es la línea de graduación: el día en que tu cuello de botella pasa de gestionar ventanas a gestionar visibilidad, revisión y traspasos.

Sharkly está construido para el otro lado de esa línea. Mantiene el contexto, el progreso, los bloqueos, los resultados y la revisión humana visibles desde la solicitud hasta el lanzamiento, en un único flujo de trabajo compartido en lugar de dispersos entre terminales privadas. La división del trabajo es deliberada: Claude Code, Codex y herramientas similares se encargan de la ejecución; Sharkly gestiona la asignación a nivel de equipo, las Computadoras conectadas, el contexto de las tareas, el progreso, los bloqueos, los resultados y la revisión humana a través de esas herramientas. Conservas los runtimes y los worktrees en los que ya confías. Añades la capa que permite que más de una persona vea y dirija el trabajo.

La tranquilidad importa tanto como el mecanismo. Adoptar Sharkly no te pide reconstruir tu proceso ni abandonar tus herramientas. Tú aportas tu propia suscripción: el uso de modelos continúa a través de las suscripciones o claves de API configuradas en las herramientas que tu equipo ya ejecuta. Conectas una Computadora, apuntas Sharkly a los mismos repositorios y empiezas a enrutar el trabajo sin desmontar nada. Si estás sopesando esto frente a un tablero local, nuestro artículo sobre la alternativa a Vibe Kanban cubre el mismo camino de conservar lo que ya tienes.

Cómo se ve el mismo flujo de trabajo en paralelo en Sharkly

Las herramientas DIY le dan a cada agente un worktree y una ventana. Sharkly le da a cada unidad de trabajo una Tarea, y deja que los Agentes la ejecuten en worktrees aislados de la misma manera, con una diferencia: el resultado vuelve a la Tarea en lugar de quedarse en tu búfer de scroll.

Una Tarea es la unidad principal de trabajo en Sharkly. Reúne el objetivo, el alcance, el diff, la discusión y la revisión en un único registro compartido. Cuando asignas una Tarea a un Agente, el Agente la reclama, trabaja en su propio worktree aislado, ejecuta el typecheck, las pruebas y la compilación, y luego adjunta el resumen del cambio, los resultados de la verificación y los límites conocidos a esa Tarea. La siguiente persona que mire no necesita tu terminal. Abre la Tarea.

La versión útil más pequeña es deliberadamente aburrida. Conecta una Computadora, crea un Agente y asígnale una Tarea de bajo riesgo, tal como lo plantea nuestro tutorial de la primera tarea. A partir de ahí, la historia en paralelo escala tal como tus scripts querían: varios Agentes reclaman Tareas listas y trabajan al mismo tiempo, cada uno aislado, mientras el frontend, el backend, la corrección de errores y la cobertura de pruebas avanzan en paralelo. La diferencia con un muro de ventanas de tmux es que cada ejecución es asignable a una persona, revisable por alguien que no eres tú y rastreable a posteriori.

El contrato entre humanos y agentes es donde la capa de revisión se gana su lugar. Los agentes investigan, ejecutan, prueban e informan. Las personas marcan la dirección, conceden autoridad y aceptan el resultado. La automatización se detiene donde se requiere el juicio del equipo, y devuelve una entrega con contexto completo y evidencia inspeccionable. Una configuración DIY puede ejecutar los agentes. No puede sostener ese contrato, porque no tiene un lugar compartido donde una persona distinta de ti acepte o rechace. Si quieres conocer la mecánica de esa puerta, nuestra nota sobre agentes en segundo plano de Cursor recorre un flujo de revisión similar.

Ejemplo práctico, con la forma que usan los equipos. Una tarea como SH-312 dice «añadir limitación de tasa a la API pública». Un Agente define el alcance, trabaja en su worktree, ejecuta las pruebas y devuelve un resumen más el diff a la Tarea. Tu revisor abre SH-312, lee la evidencia y acepta o solicita cambios. Cuando estabas solo, todo ese ciclo vivía en tu cabeza y en una terminal. Ahora vive en algún sitio que el equipo puede ver, que es exactamente el objetivo de graduarse.

Quién debería quedarse y quién ya lo ha superado

Una comparativa que solo vende hacia arriba no es honesta, así que aquí va la versión clara. Mucha gente no debería cambiar, y las herramientas anteriores son el hogar adecuado para ellos.

• Quédate en Conductor si eres un desarrollador solo en Mac que quiere ejecuciones de Claude Code en paralelo en una ventana tranquila y nadie más necesita verlas. Hace ese trabajo de forma limpia y no le pide nada a un servidor.
• Quédate en Claude Squad si vives en la terminal, ejecutas una mezcla de runtimes y quieres un conmutador rápido sobre worktrees y tmux para tu propio trabajo. Es un centro de mando sólido para un solo operador.
• Quédate con tmux puro y scripts de worktree si valoras el control total, tu flujo de trabajo es estable y eres el único público del resultado. Las herramientas propias superan a las alquiladas cuando las necesidades son personales.
• Pasa a Sharkly cuando el trabajo deje de ser solo tuyo: cuando un compañero necesite revisar una ejecución, cuando alguien tenga que hacerse cargo mientras estás fuera, cuando un manager necesite ver qué está bloqueado o cuando te des cuenta de que estás reconstruyendo a mano la lógica de estado y traspaso. Nuestra visión general de la orquestación traza dónde se encuentran las capas.

El par de decisión para toda la categoría es corto. Usa una herramienta DIY cuando la restricción sea tu propia máquina y tu propio tiempo. Usa una capa de orquestación cuando la restricción sea el entendimiento compartido de tu equipo sobre lo que hicieron los agentes. La mayoría de los desarrolladores empiezan a la izquierda y cruzan la semana en que aparece el nombre de una segunda persona en el trabajo.

Escenarios del mundo real

El constructor en solitario que se queda donde está. Un desarrollador freelance entrega funcionalidades para clientes con tres o cuatro agentes de Claude Code en un Mac. Conductor o Claude Squad es toda la respuesta, y añadir una capa de equipo sería peso sin recompensa. Quedarse es la decisión correcta.

El equipo de dos que acaba de cruzar la línea. Un fundador y un primer ingeniero ejecutaban cada uno sus propios scripts de tmux. Ninguno podía revisar el trabajo del agente del otro sin compartir pantalla. Mover las ejecuciones a Tareas compartidas en Sharkly hizo que cada uno pudiera abrir el diff del otro, aceptarlo y fusionarlo, sin cambiar los runtimes que ya usaban.

El líder que estandariza un escuadrón. Un líder técnico con cinco ingenieros descubrió que cada uno tenía un script de worktree ligeramente distinto y ninguna revisión compartida. Los Agentes compartidos y un flujo de Tareas común convirtieron cinco configuraciones privadas en un flujo de trabajo que el equipo podía reutilizar, mientras cada ingeniero conservaba su propia Computadora y su propia suscripción de modelo.

Preguntas frecuentes

¿Cuál es la diferencia entre Claude Squad y Conductor? Claude Squad es una app de terminal multiplataforma que gestiona agentes sobre tmux y git worktrees y admite varios runtimes. Conductor es una app de escritorio para macOS centrada en ejecutar Claude Code en una interfaz de ventanas. Ambas aíslan cada ejecución en su propio worktree; la diferencia es terminal frente a app nativa, y multiplataforma frente a solo Mac.

¿Necesito Claude Squad o Conductor si ya uso git worktrees? No necesariamente. Ambas son comodidades sobre la misma primitiva de worktree. Si te sientes cómodo escribiendo unos cuantos comandos de tmux y git worktree, los scripts puros te dan el mismo aislamiento con más control. Las herramientas te compran ergonomía y limpieza, no una capacidad nueva.

¿Pueden estas herramientas DIY gestionar la revisión de equipo? No, y no pretenden hacerlo. Conductor, Claude Squad y los scripts de tmux mantienen el estado en una máquina para un operador. La revisión compartida, la aceptación por otra persona y un registro duradero de las decisiones son funcionalidades de flujo de trabajo que viven en una capa de orquestación, no en un runner local. Consulta nuestro artículo sobre la alternativa a Vibe Kanban para esa distinción.

¿Es Sharkly un reemplazo de Claude Code o Claude Squad? No. Sharkly no reemplaza a Claude Code, Codex ni otras herramientas de ejecución. Añade la capa compartida de Tareas, Computadoras, contexto, control y revisión alrededor de las herramientas que tu equipo ya usa. Conservas tus runtimes y tus worktrees y ganas visibilidad a nivel de equipo por encima.

¿Pasar a Sharkly significa renunciar a los git worktrees? No. Sharkly también ejecuta Agentes en worktrees aislados, así que el aislamiento en el que confías se mantiene. Lo que cambia es adónde va el resultado: vuelve a una Tarea compartida en lugar de a un búfer de terminal privado.

¿Cómo mantengo mi uso de modelos y mis costes cuando hago el cambio? Tú aportas tu propia suscripción. El uso de modelos continúa a través de las suscripciones o claves de API configuradas en las herramientas que tu equipo conecte, y la cuota de modelos depende de esas herramientas, planes y cuentas de API. Sharkly añade la capa de coordinación, no una nueva relación de facturación.

¿Listo para cruzar la línea? Descarga Sharkly, conecta una Computadora y asigna un requisito real a un solo Agente. Conserva los runtimes y worktrees en los que ya confías y deja que el trabajo empiece a volver a un lugar que todo tu equipo pueda ver. La documentación cubre cada concepto con más profundidad en docs.sharkly.ai.