Alternativa a Vibe Kanban: dónde ejecutar tus agentes de programación ahora

Construiste un hábito en torno a un tablero. Una columna por tarea, un agente de programación por tarjeta, cada uno trabajando en su propio git worktree para que nada chocara. Era una forma limpia de ejecutar tres o cuatro agentes a la vez y aun así revisar sus diffs de uno en uno. Después, la empresa que mantenía la herramienta cerró su nube y llegó la pregunta incómoda: ¿dónde ejecutas ahora tus agentes de programación y esa respuesta escala más allá de un portátil y una persona?

Si buscas una alternativa a Vibe Kanban, no estás buscando un sustituto de Claude Code o Codex. Estás buscando la capa que rodea a esos runtimes: el lugar que le entrega una tarea a cada agente, mantiene su trabajo aislado y te muestra qué cambió antes de que se fusione nada. Esta guía recorre esa capa. Le da a Vibe Kanban todo el crédito por el patrón que demostró, marca la línea exacta donde se detiene un tablero local y muestra cómo Sharkly la cruza hacia tareas compartidas, Crews y Sprints para todo un equipo.

TL;DR

Vibe Kanban fue pionero del modelo de un tablero por agente: ejecutar varios agentes de programación en paralelo, cada uno en su propio worktree, y revisar su resultado en un tablero kanban en tu máquina. Sharkly mantiene ese modelo y le añade la capa de equipo: un registro de Task compartido, Computers conectados, Crews, Sprints y revisión humana desde la solicitud hasta el despliegue. Si trabajas en solitario en una sola máquina, un tablero local es suficiente. Si un equipo necesita contexto compartido y una puerta de revisión, ahí es donde entra Sharkly.

El problema que realmente resuelve una alternativa a Vibe Kanban

Vibe Kanban acertó en algo que la mayoría de las herramientas pasó por alto. Cuando ejecutas varios agentes de programación con IA a la vez, la parte difícil no son los modelos. Son las colisiones. Dos agentes editando los mismos archivos, resultados dispersos entre pestañas de terminal y ninguna vista única de qué tarea está terminada, cuál está bloqueada y cuál se torció sin que nadie se diera cuenta.

La respuesta del tablero por agente era elegante. Dale a cada tarea su propia tarjeta. Dale a cada tarjeta su propio git worktree para que el agente trabaje en una rama aislada dentro de un directorio aislado. Deja que Claude Code, Gemini CLI, Codex u otro runtime hagan el trabajo dentro de ese entorno aislado y luego trae el diff de vuelta para revisarlo. Convirtió «tengo cinco agentes y no tengo idea de qué hizo ninguno» en un tablero que de verdad se podía leer. Si quieres la mecánica de ese patrón en paralelo por sí solo, nuestra guía sobre cómo ejecutar varios agentes de Claude Code en paralelo cubre la configuración del worktree en detalle.

La brecha nunca estuvo en el patrón. La brecha es lo que un tablero local no puede alcanzar. Un tablero en tu máquina es un tablero para ti. Tu compañero de equipo no puede ver la tarea, no puede tomar una tarjeta bloqueada, no puede revisar el diff antes de que se fusione y no puede saber desde el otro lado de la sala si el sprint va por buen camino. Cuando el trabajo es en solitario, está bien. Cuando el trabajo es de un equipo, la pieza que falta es un registro compartido, y eso es otro tipo de herramienta.

Lo que Vibe Kanban demostró, sin rodeos

Dale a la herramienta su mejor versión, porque se la ganó. Vibe Kanban trató las ejecuciones de agentes como unidades de trabajo de primer nivel en lugar de sesiones de terminal desechables. Convirtió el aislamiento por worktree en la opción predeterminada, para que los agentes en paralelo dejaran de pisarse entre sí. Hizo barato cambiar de runtime, para que no quedaras atado a un solo modelo. Y convirtió la revisión en un paso más, no en algo secundario, poniendo el diff delante de ti antes de mover una tarjeta a terminado.

Esas cuatro ideas son correctas, y cualquier alternativa seria tiene que mantenerlas todas. Una alternativa a Vibe Kanban que elimine el aislamiento por worktree, o que oculte el diff, o que te encierre en un único runtime es un retroceso, sin importar qué más añada. El listón que puso el tablero es el suelo, no el techo.

Lo que cambió es la historia de mantenimiento. El proyecto es de código abierto y todavía puede ejecutarse en local, pero las funciones en la nube operadas por la empresa se eliminaron y las correcciones continuas ahora dependen de colaboradores de la comunidad. Para un desarrollador en solitario eso puede ser perfectamente aceptable. Para un equipo que apuesta a la herramienta un trimestre entero de entregas, «depende de quien aparezca» es un riesgo real que hay que sopesar, y es la razón honesta por la que ahora mismo hay intención de migrar.

Dónde termina el tablero local y dónde continúa Sharkly

Aquí está el par de decisiones, planteado tal como se resuelve en la práctica.

Usa un tablero local cuando seas una sola persona en una sola máquina, las tareas sean solo tuyas y nadie más necesite ver el trabajo hasta que abras un pull request. La configuración de un tablero por agente es ligera, se ejecuta donde tú trabajas y añade cero sobrecarga de coordinación porque no hay nadie más con quien coordinarse. Optar por una plataforma de equipo en ese caso es matar moscas a cañonazos.

Usa Sharkly cuando las ejecuciones de agentes dejen de ser privadas. En el momento en que una segunda persona necesita asignar una tarea, retomar un bloqueo o revisar un diff antes de que se fusione, un tablero que vive en tu portátil se convierte en el cuello de botella. Esa es la línea. Sharkly es la capa que rodea los mismos runtimes que ya usas y hace que cada ejecución sea asignable, visible y revisable por el equipo, no solo por ti.

Una definición rápida, de manual, porque el resto depende de ella. Una Task es la unidad principal de trabajo en Sharkly. Contiene el objetivo, el Agent asignado, el runtime, el progreso, los bloqueos, el diff resultante y la revisión humana, todo en un único registro compartido. Donde una tarjeta de un tablero local es tuya, una Task es del equipo.

Y un límite, porque un lector que migra desde un tablero asumirá lo contrario si no se aclara. Sharkly no sustituye a Claude Code, Codex ni Gemini. No ejecuta el modelo ni escribe el código. Añade la tarea compartida, el Computer conectado, el contexto, el control y la capa de revisión alrededor de las herramientas de ejecución que tu equipo ya usa. Si te encantaba que Vibe Kanban te dejara cambiar de runtime con libertad, Sharkly conserva esa libertad y le pone un equipo alrededor.

La ruta de migración: conserva tus runtimes, conserva tus repos y añade la capa de revisión

Lo mejor de dejar atrás un tablero que se apaga es lo poco que tienes que renunciar. No estás reconstruyendo tu stack. Conservas las partes que funcionaban y añades la que faltaba.

Conserva tus runtimes. Claude Code, Codex, Gemini CLI, OpenCode, Cline y el resto siguen ejecutando exactamente igual que antes. El uso de modelos continúa a través de las suscripciones o claves de API ya configuradas en esas herramientas. Tú traes tu propia suscripción; Sharkly no se interpone entre el agente y el modelo. Si quieres la base conceptual de lo que hacen estos runtimes, nuestra explicación sobre qué significa el coding agéntico para los equipos de desarrollo fija los términos.

Conserva tus repos y tu hábito de worktrees. Sharkly ejecuta agentes en worktrees aislados en Computers conectados, el mismo aislamiento en el que confiabas, ahora vinculado a una Task compartida en lugar de a una tarjeta local. El frontend, el backend, la corrección de errores y la cobertura de pruebas pueden avanzar al mismo tiempo sin chocar, que es exactamente la razón por la que existía el modelo de un tablero por agente.

Añade la capa de revisión que te faltaba. Esta es la parte nueva. La ejecución, los bloqueos, los resultados y el debate de seguimiento vuelven a la línea temporal de la Task, donde el equipo puede verlos. Un Agent investiga, ejecuta, prueba e informa. Las personas marcan la dirección, conceden autoridad y aceptan el resultado. La automatización se detiene donde se requiere el criterio del equipo y devuelve una entrega con todo el contexto y evidencias inspeccionables. Esa última frase es el contrato que un tablero local no podía hacer cumplir, porque no había ningún equipo al otro lado.

Así que la migración es aditiva. Conecta un Computer, apunta Sharkly a los runtimes que ya tienes y empieza a enrutar trabajo sin rehacer el proceso que tu equipo ya entiende. El tablero te enseñó a ejecutar agentes en paralelo. Sharkly deja que el resto del equipo participe.

Del tablero individual al sistema de equipo: Crews, Sprints y Projects

Una vez que las ejecuciones son compartidas, se abren tres capacidades que un tablero de un solo usuario no podía ofrecer.

Crews, para trabajo que necesita más de un agente. Un Crew es un grupo reutilizable de personas y Agents coordinado por un Agent líder. Para trabajo pequeño y bien definido no lo necesitas: asigna la Task a un solo Agent y mantén las piezas móviles a cero. Usa un Crew cuando el Agent líder necesite interpretar un objetivo más amplio, incorporar a otros Agents y devolver sus resultados a una única Task. Esa es la regla honesta. Un Crew es palanca cuando el trabajo es genuinamente multiparte, y lastre cuando no lo es.

Sprints y Projects, para un seguimiento que sobrevive a una sola tarjeta. Un tablero local muestra las tareas que tienes delante hoy. Un Sprint hace seguimiento de la finalización, la propiedad, las dependencias, los cambios de alcance y los bloqueos a lo largo de un conjunto de trabajo en el tiempo. Para un equipo híbrido de personas y Agents, esa es la diferencia entre «los agentes hicieron algunas cosas esta semana» y un plan sobre el que de verdad puedes reportar. Nuestra introducción a la orquestación de agentes de IA para equipos de desarrollo explica por qué la capa de coordinación, y no los modelos, es donde se gana o se pierde el rendimiento del equipo.

Transparencia de equipo, por defecto y no por compartir pantalla. Mantén el contexto, el progreso, los bloqueos, los resultados y la revisión humana visibles desde la solicitud hasta el despliegue. En un tablero local, la visibilidad terminaba en tu monitor. En un sistema compartido, la ventaja no viene de abrir más chats de IA. Viene de compartir roles, reglas, contexto y flujos de trabajo para que una buena configuración se convierta en una capacidad que todo el equipo reutiliza.

Vibe Kanban vs. Sharkly: una comparación justa

Lee la tabla como una división del trabajo, no como un marcador. Para un desarrollador en solitario que quiere un tablero local gratuito y nada más, el proyecto mantenido por la comunidad puede seguir siendo la decisión correcta, y no hay nada de qué avergonzarse por quedarse ahí. Para un equipo que necesita que las ejecuciones sean compartidas, asignables y revisables, el tablero siempre iba a quedarse sin espacio, y Sharkly es donde los mismos runtimes siguen funcionando con el equipo añadido. Puedes descargar Sharkly y conectar un Computer para ver la diferencia en trabajo real.

Errores comunes al dejar atrás un tablero local

• Tratarlo como un simple reemplazo. No buscas otro tablero. Buscas la capa de equipo que el tablero nunca tuvo. Si la alternativa solo reproduce columnas y tarjetas, no resolvió nada.
• Abandonar el aislamiento por worktree para ir más rápido. El aislamiento es la razón por la que los agentes en paralelo no chocan. Consérvalo. Cualquier herramienta que haga que los agentes compartan un directorio de trabajo te devuelve el problema.
• Añadir un Crew para trabajo de un solo agente. Recurre a un Crew solo cuando el objetivo necesite de verdad un Agent líder que coordine a los miembros. Para una tarea bien acotada, un Agent y cero piezas móviles es la respuesta correcta.
• Saltarte la puerta de revisión para sentirte productivo. El sentido de la capa es que las personas acepten el resultado. Fusionar diffs de agentes sin revisar porque es más rápido devuelve exactamente la seguridad que todo el sistema existe para ofrecer.
• Migrarlo todo el primer día. Empieza con un requisito real y una Task de bajo riesgo. Demuestra el ciclo y luego amplíalo.

Conclusión

Vibe Kanban demostró un patrón que vale la pena conservar: los agentes funcionan mejor en paralelo, aislados en sus propios worktrees, con la revisión como un paso real. Ese patrón es ahora el suelo, y cualquier alternativa a Vibe Kanban que lo abandone va hacia atrás.

• El modelo de un tablero por agente era correcto; agentes en paralelo, aislados por worktree y con revisión de diffs es la forma adecuada.
• Un tablero local termina en una persona y una máquina. El trabajo compartido necesita un registro compartido.
• Sharkly conserva tus runtimes, tus repos y tu hábito de worktrees, y añade la capa de equipo a su alrededor.
• Una Task reúne el objetivo, el runtime, el progreso, los bloqueos, el diff y la revisión en un solo lugar.
• Crews, Sprints y Projects convierten ejecuciones paralelas en un plan sobre el que un equipo puede reportar.
• Los agentes investigan, ejecutan, prueban e informan; las personas marcan la dirección, conceden autoridad y aceptan el resultado.

Si estás decidiendo dónde ejecutar tus agentes de programación a continuación, conserva las herramientas que tu equipo ya usa y añade la capa que hace que las ejecuciones sean asignables y trazables. Conecta un Computer, crea un Agent y asígnale algo aburrido. Luego deja que el resto del equipo vea cómo el trabajo vuelve a la Task. Empieza en Sharkly, y la documentación cubre cada concepto con más profundidad en docs.sharkly.ai.

Preguntas frecuentes

¿Vibe Kanban sigue siendo utilizable después del cierre de Bloop? Sí. El proyecto es de código abierto y todavía puede ejecutarse en local. Las funciones en la nube operadas por la empresa se eliminaron, y las correcciones y actualizaciones ahora dependen de colaboradores de la comunidad. Para uso en solitario puede estar bien; para un equipo que depende de ella para sus entregas, vale la pena sopesar el riesgo de mantenimiento.

¿Sharkly sustituye a Claude Code o Codex? No. Sharkly no sustituye a Claude Code, Codex ni otras herramientas de ejecución. Esos runtimes realizan la ejecución. Sharkly añade la tarea compartida, el Computer, el contexto, el control y la capa de revisión a su alrededor. Sigues usando los mismos agentes.

¿Tengo que renunciar a ejecutar agentes en worktrees paralelos? No. Sharkly ejecuta agentes en worktrees aislados en Computers conectados, el mismo aislamiento en el que se basaba el modelo de un tablero por agente. El frontend, el backend y las pruebas pueden avanzar a la vez sin chocar. Consulta cómo ejecutar varios agentes de Claude Code en paralelo para ver el patrón subyacente.

¿En qué consiste realmente migrar desde un tablero local? Conserva tus runtimes y tus repos. Conecta un Computer, apunta Sharkly a las herramientas de ejecución que ya usas y empieza a enrutar el trabajo como Tasks compartidas. El uso de modelos continúa a través de las suscripciones o claves de API ya configuradas en esas herramientas, así que la facturación no cambia.

¿Cuándo no debería usar Sharkly? Cuando seas una sola persona en una sola máquina y nadie más necesite ver o revisar el trabajo, un tablero local es suficiente. Sharkly se gana su lugar en el momento en que una segunda persona necesita asignar, retomar o revisar la ejecución de un agente.

¿Cuál es la diferencia entre una tarjeta y una Task? Una tarjeta de un tablero local es tuya y vive en tu máquina. Una Task es el registro compartido del equipo: contiene el objetivo, el Agent asignado, el runtime, el progreso, los bloqueos, el diff y la revisión humana, y los resultados de la ejecución vuelven a ella.