Vibe Kanban: un tablero kanban para dirigir agentes de código en paralelo

Una kanban con la que se planifican, ejecutan y revisan tareas mediante agentes de programación (Claude Code, Codex, Gemini CLI, Copilot y otros), y que tras el cierre de la empresa bloop pasa a mantenerse de forma abierta y comunitaria. A 1 de septiembre de 2026 lleva 27.979 estrellas.

Qué es Vibe Kanban

Vibe Kanban es una aplicación de escritorio (con componente web y opción autoalojada) cuyo objetivo declarado en el README es «sacar el 10× más de Claude Code, Codex o cualquier agente de programación». No es un agente en sí: es un orquestador. El ingeniero crea tareas (issues) en un tablero kanban y, cuando quiere ejecutar, crea un espacio de trabajo (workspace) donde un agente recibe una rama git (un worktree), una terminal y un servidor de desarrollo. El usuario puede ver el diff en directo, dejar comentarios en línea que vuelven al agente, previsualizar la app en un navegador integrado y abrir la solicitud de cambios (PR) desde la propia interfaz.

El punto de partida del equipo, expuesto por uno de sus creadores en el anuncio de Hacker News, era la sensación de «estar inútil» esperando 2 a 5 minutos a que el agente terminara una tarea. La propuesta era paralelizar agentes en segundo plano y usar ese tiempo en planificar y revisar, que según su tesis son las actividades que cada vez más tiempo ocupan a los ingenieros.

El producto se construye con un backend en Rust y una frontend en Node.js (requisito Node ≥ 20, pnpm ≥ 8), empaquetada como aplicación de escritorio mediante Tauri, con un servidor MCP propio y capacidad de autoalojamiento con Docker.

Nota sobre la desambiguación: el repositorio BloopAI/vibe-kanban no debe confundirse con el repositorio BloopAI/bloop de la misma organización, que es un motor de búsqueda de código rápido escrito en Rust y un producto anterior y distinto de la empresa. Este informe documenta únicamente vibe-kanban.

Origen

El repositorio se creó el 14 de junio de 2025 en la organización BloopAI. La empresa detrás es bloop (Bloop AI Limited), fundada por Louis Knight-Webb (louiskw) y Gabriel Gordon Hall (ggordonhall), entre otros. Según el anuncio de clausura publicado el 10 de abril de 2026, el equipo «lanzó en junio de 2025».

El anuncio público más visible fue el Show HN del 11 de julio de 2025 (hilo 44533004, 195 puntos, 132 comentarios), donde Louis Knight-Webb presentó el proyecto y describió la motivación: la espera de 2-5 minutos por tarea llevaba a la distracción, y quería una forma de paralelizar agentes y aprovechar ese tiempo productivo.

Historia y línea de tiempo: una cronología neón que va de la creación del repositorio en junio de 2025 al lanzamiento público, la adopción masiva, el anuncio de cierre en abril de 2026 y la transición a un futuro mantenido por la comunidad

El dato narrativo más importante para quien use el proyecto hoy es su final: el 10 de abril de 2026, bloop anunció el cierre de la empresa. El comunicado (firmado por Louis, Gabriel y el equipo de bloop) explica que, aunque «miles de ingenieros de software usan Vibe Kanban cada día», la inmensa mayoría eran usuarios de la versión gratuita y «no pudimos encontrar un modelo de negocio del que entusiasmarnos». Como consecuencia, el proyecto Vibe Kanban continúa como código abierto y mantenido por la comunidad, y la empresa prometió publicar en las semanas siguientes una hoja de ruta para la edición comunitaria. Las funciones remotas (issues, comentarios, proyectos y organizaciones en la nube) permanecieron disponibles 30 días tras el anuncio para después pasar a una arquitectura totalmente local; se emitieron reembolsos de facturas de los 30 días anteriores y se dieron de baja las suscripciones. La última versión incluye una función de exportación de datos.

Transición de empresa a comunidad: a la izquierda una estructura corporativa que se apaga en un degradado de atardecer, a la derecha una red comunitaria vibrante con repositorios de GitHub, hilos de discusión, contribuidores y contenedores Docker locales, con un tablero kanban central que permanece intacto

Este contexto condiciona todo lo demás: el proyecto tiene tracción real (casi 28.000 estrellas) pero su mantenimiento institucional ha cesado, por lo que su futuro depende de la comunidad.

Filosofía y principios

Las ideas verificables que atraviesan el README, los documentos y el anuncio:

El cuello de botella ya no es escribir código, sino planificar y revisar. El README abre: «En un mundo donde los ingenieros pasan la mayor parte de su tiempo planificando y revisando agentes de código, la forma de mayor impacto para entregar más es ser más rápidos planificando y revisando».
Paralelismo de agentes como unidad de trabajo. El valor central es lanzar varios agentes a la vez en espacios aislados (cada uno con su rama, terminal y servidor), para que el humano revise en lote en vez de esperar de forma secuencial.
La revisión es la interfaz, no el chat. El producto pone el diff, los comentarios en línea y la previsualización en el centro, con la premisa de que el ingeniero humano mantiene la calidad.
Neutralidad de agente. No impone un único agente: soporta y alterna entre más de diez, lo que lo convierte en una capa de abstracción sobre los CLI existentes de cada proveedor.

Planificar y revisar como cuello de botella: un ingeniero rodeado de paneles holográficos con tarjetas de tareas, diffs de código, listas de revisión y comentarios en línea, con un tablero kanban a la izquierda y agentes trabajando en paralelo dentro de contenedores de cristal a la derecha

Hay una tensión explícita en la recepción comunitaria (v. «Recepción de la comunidad»): varios usuarios cuestionaron si la premisa de que «los ingenieros pasan la mayoría de su tiempo planificando y revisando» es cierta hoy, y otros objetaron el alcance de los permisos de autenticación de GitHub que la versión inicial solicitaba.

Cómo funciona

El recorrido documentado en la guía Get Started tiene estas fases:

Lanzar con npx vibe-kanban, que abre la UI en el navegador.
Preferencias iniciales: elegir agente de código, IDE y notificaciones.
Inicio de sesión con GitHub o Google (se puede omitir, pero entonces no hay tablero, issues ni funciones de equipo; sí se pueden crear workspaces locales).
Tablero kanban: crear y priorizar issues (título, descripción, prioridad, etiquetas y relaciones padre/hijo).
Crear un workspace: al seleccionarlo, Vibe Kanban crea git worktrees para los repositorios elegidos (sobre las ramas indicadas), lanza el agente con el prompt y la configuración (modelo, nivel de esfuerzo, modo plan). Se pueden conectar varios workspaces a un mismo issue para ejecutar agentes en paralelo, o workspaces sin issue para consultas rápidas.
Revisar: ver los cambios, previsualizar la app en el navegador integrado (con devtools, modo inspección y emulación de dispositivos), comentar en línea.
Fusionar: abrir un PR de GitHub con descripción generada por IA, o fusionar la rama localmente.

Espacios de trabajo aislados como git worktrees: un repositorio central que se ramifica en varias cámaras neón, cada una con terminal, árbol de archivos, servidor de desarrollo local y panel de previsualización, etiquetadas con nombres de rama distintos

Funciones técnicas clave según el README y la documentación:

Más de 10 agentes intercambiables: Claude Code, OpenAI Codex, Gemini CLI, GitHub Copilot, Amp, Cursor Agent CLI, OpenCode, Factory Droid, CCR (Claude Code Router) y Qwen Code.
Servidor MCP propio: desde la pestaña «MCP Servers» se puede añadir el MCP de Vibe Kanban para que un agente cree tickets en el tablero (por ejemplo, «planifica una migración de AWS a Azure y crea un ticket por cada paso»).
Integraciones de control de versiones: GitHub y Azure Repos.
Extensión de VSCode (también Cursor y Windsurf) y configuración de SSH remoto para abrir proyectos remotos en el editor local.
Autoalojamiento de la instancia de «Vibe Kanban Cloud» mediante Docker Compose.

Neutralidad de agente: un módulo central de orquestación con conectores neón intercambiables enchufados, cada uno representando un agente distinto de código, unificados por la misma interfaz de control

Vista de revisión: un visor de diff con líneas resaltadas en colores neón, comentarios en línea que se envían de vuelta al agente, un navegador integrado con emulación de dispositivos y devtools, y un panel de fusión con botones para abrir PR o fusionar localmente.

Experiencia de revisión: un visor de diff de código con líneas cambiadas, añadidas y eliminadas resaltadas, burbujas de comentarios en línea, un navegador integrado con modo de inspección y un panel de fusión con opciones de abrir PR o fusionar localmente

El ecosistema

Repositorios de la organización BloopAI

Además de vibe-kanban, la organización contiene repositorios relacionados con el proyecto (cifras de estrellas recuperadas de la API de GitHub en esta ejecución):

BloopAI/dev-manager-mcp: servidor MCP para «lanzar múltiples servidores de desarrollo en paralelo»; 140 estrellas.
BloopAI/vibe-kanban-web-companion: «edita sitios web en Vibe Kanban»; 44 estrellas.
BloopAI/debugger-mcp: servidor MCP para depuración interactiva; 30 estrellas.
BloopAI/experiments: predicciones, registros de ejecución, trayectorias y resultados de inferencia y evaluación en la tarea SWE-bench; sin estrellas registradas.
BloopAI/bloop: motor de búsqueda de código rápido en Rust (producto anterior y distinto de Vibe Kanban); 9.497 estrellas. Se menciona porque un usuario del hilo de lanzamiento (skeptrune) escribió «recuerdo el motor de búsqueda Bloop original», lo que confirma que es el antecedente de la empresa.

Alternativas, forks y extensiones de la comunidad

La búsqueda de repositorios de GitHub (consulta vibe-kanban, ordenado por estrellas, 314 resultados en total) devolvió varios proyectos derivados o competidores que citan a Vibe Kanban directamente. Entre los más visibles:

knowsuchagency/fulcrum: «¿Y si Openclaw, Vibe Kanban, Vibetunnel y Dokploy tuvieran un bebé?»; 90 estrellas.
automagik-dev/forge: «La plataforma Vibe Coding++™ — orquesta múltiples agentes de IA, experimenta con intentos aislados, entrega código que entiendes. Kanban multiagente con integración MCP»; 89 estrellas.
ariaghora/korlap: «un tablero kanban para hacer vibes»; 75 estrellas.
halilbarim/vibe-stack: «setup Docker para codificación con IA con Vibe-Kanban + Claude Code; secretos seguros, VS Code por navegador, listo para desplegar»; 47 estrellas.
GarrickZ2/grove: «TUI de tipo kanban para codificación IA paralela. Gestiona worktrees git como tareas y ejecuta varios agentes en sesiones tmux aisladas»; 46 estrellas.
qwenode/vibe-kanban-promax: «fork refinado de vibe-kanban con mejor UI, correcciones de usabilidad, modo solo-local y sin necesidad de inicio de sesión»; 13 estrellas.
p-wegner/agentic-kanban: «reimplementación cleanroom de vibe-kanban»; 4 estrellas.
yigitkonur/mcp-better-vibe-kanban: servidor MCP para gestionar tareas y sesiones de Vibe Kanban desde el editor de IA; 5 estrellas.
oculairmedia/vibesync: sincronización bidireccional entre Huly y Vibe Kanban vía MCP; 3 estrellas.
mac-tron/kando: «Pensa. Planifica. Actúa. Piensa y planifica en Obsidian y ejecuta en Vibe Kanban»; 3 estrellas.

Ecosistema MCP, herramientas y extensiones comunitarias: un nodo central «Vibe Kanban MCP» conectado a un tablero kanban, múltiples servidores de desarrollo, un depurador, extensiones de VSCode, Cursor y Windsurf, integración con Docker, GitHub y Azure Repos, rodeado de proyectos comunitarios en órbita como forks, reimplementaciones y TUI

Varios de estos proyectos aparecieron también como respuestas en el hilo de Hacker News o en hilos propios (v. sección de recepción): ericblue/claude-vibekanban (flujo orientado por PRD), flashlan/vibe-kanban-alternative (kanban con memoria persistente mem0), ferrislucas/Circus-Chief (agentes desde el móvil), battysh/batty (equipo de agentes en tmux con control por pruebas) y silo-rs/silo (cada rama con su propio localhost).

Estas cifras son las que devolvió la búsqueda de GitHub durante esta investigación y no constituyen una auditoría de calidad, soporte ni compatibilidad de cada derivado.

Estado oficial / semioficial

Vibe Kanban no ocupa un «estado oficial» en el sentido de marketplace de plugins: es una aplicación autónoma, no un paquete que otros distribuyen. Su estatus relevante tiene dos partes:

Primado funcional (autodeclarado por el equipo en el comunicado de clausura): bloop afirma haber sido «el primero en ofrecer soporte multiagente, comentarios en el diff, previsualización en vivo, edición con clic, acceso remoto y muchas otras funciones que hoy se dan por sentadas». Estas son afirmaciones del propio equipo y no una certificación de un organismo externo.
De facto, y ahora en transición: por su adopción («miles de ingenieros lo usan cada día» según bloop) se volvió una referencia práctica para orquestar agentes en paralelo. Con el cierre de la empresa (abril de 2026), pasa a ser mantenido por la comunidad: el README actual lleva el aviso «Vibe Kanban is sunsetting» y enlaza al anuncio, la última publicación oficial (v0.1.44) es del 24 de abril de 2026 y los servicios remotos se retiran a favor de una arquitectura local.

En la práctica, esto significa que la app local sigue funcionando, pero las funciones de nube (issues compartidos, equipos, organizaciones) quedan obsoletas a mediano plazo y el canal de soporte pasa de la empresa a GitHub Discussions y Discord comunitario.

Guía rápida de uso

Instalación y primer arranque

Prerrequisito: haber autenticado previamente al agente de código que se quiera usar (la lista completa y las instrucciones de cada uno están en la documentación). Después:

npx vibe-kanban

En el primer arranque la aplicación pide el agente de código preferido, el IDE y las preferencias de notificación (cambiables después en el diálogo de ajustes). A continuación ofrece iniciar sesión con GitHub o Google; si se omite («More options» → «I understand, continue without signing in»), se pueden crear workspaces locales pero no el tablero, los issues ni las funciones de equipo. Con sesión, se crea automáticamente una organización personal y un proyecto inicial.

Advertencia de contexto: dado el cierre de bloop, el inicio de sesión y las funciones de nube están en modo de transición. Para un uso duradero conviene planificar la exportación de datos (disponible en la última versión) y considerar el modo local o una alternativa comunitaria (v. «El ecosistema»).

Flujos de trabajo habituales

Planificar y ejecutar una tarea: crear un issue en el tablero → seleccionarlo → «Create workspace», eligiendo repositorio, rama de base, agente y configuración (modelo, esfuerzo, modo plan) → el agente arranca con el prompt → se revisa el diff y se fusiona con «open GitHub PR» o merge local.
Ejecutar en paralelo: conectar varios workspaces al mismo issue (uno por agente/rama) para trabajar una característica grande a la vez; al terminar, revisar cada diff por separado.
Dejar feedback sin salir de la UI: en la vista de workspace, abrir el panel de cambios, comentar en línea sobre el diff y enviar el comentario al agente para que itere antes de fusionar.
Que el agente planifique: añadir el servidor MCP de Vibe Kanban (pestaña «MCP Servers» → «Add Vibe Kanban MCP») y pedir al agente que descompose una tarea grande en tickets (por ejemplo, «planifica una migración de AWS a Azure y crea un ticket por cada paso»).

Flujo completo de tarea a PR fusionado: una tubería horizontal neón que muestra la creación de una tarjeta kanban, el nacimiento de un workspace con rama git, un agente ejecutándose en terminal aislado, revisión del diff en vivo con comentarios en línea, previsualización en navegador integrado, apertura de PR con descripción generada por IA y fusión final en el repositorio

Configuración esencial

Los ajustes que un usuario nuevo toca primero, según la documentación y el README:

Agente por defecto / perfiles de agente (Settings → Agent Profiles & Configuration): configuraciones reutilizables con modo plan, modelo y nivel de permisos, que se aplican al crear intentos de tarea.
Integración de editor (Settings → General / Editor Integration): elegir IDE (VSCode, Cursor, Windsurf) y, para despliegues remotos, el Remote SSH Host y usuario, de modo que los botones «Open in VSCode» generen vscode://vscode-remote/ssh-remote+user@host/path.
Variables de entorno del backend (README): PORT, HOST (por defecto 127.0.0.1), MCP_PORT y, detrás de un reverse proxy o dominio propio, VK_ALLOWED_ORIGINS (v. trampas frecuentes).
Scripts de setup/cleanup por repositorio (Settings → Projects & Repositories): automatizan instalación de dependencias, builds y desmontaje para que cada workspace arranque limpio.
Servidores MCP (Settings → Connecting MCP Servers): añadir servidores para ampliar las herramientas de los agentes dentro de Vibe Kanban.

Trampas frecuentes y soluciones

Error 403 «Forbidden» al autoalojar con dominio propio o reverse proxy (nginx, Caddy, Traefix): el Origin del navegador no coincide con el host esperado por el backend. Solución documentada: fijar VK_ALLOWED_ORIGINS con el origen (u orígenes, separados por comas) donde es accesible la frontend, p. ej. VK_ALLOWED_ORIGINS=https://vk.example.com.
Permisos de GitHub demasiado amplios: en el hilo de lanzamiento varios usuarios (csomar, doritosfan84) objetaron que la app pedía acceso ilimitado a repos privados. El equipo respondió que se necesitaba para abrir PRs y leer resultados de CI; la recomendación práctica derivada por los propios usuarios es usar una GitHub App (permisos por grano) en lugar de una OAuth App. Ante el cierre, conviene minimizar el alcance del acceso que se concede.
Degradación del equipo con varios agentes: Louis Knight-Webb reconoció en el hilo que «el MacBook se vuelve lento tras 4 ejecuciones concurrentes, sobre todo por rustc». Aislar workspaces y limitar el número de agentes simultáneos es la mitigación natural.
MCP en Windows con HOST=0.0.0.0: el README indica usar MCP_HOST=127.0.0.1 explícitamente cuando HOST=0.0.0.0, para que el servidor MCP se conecte correctamente.
Fugas/estado de procesos (documentado en releases): en versiones recientes se corrigieron problemas como «fuga de historial de conversación» (regresión de Zustand a React Context) y la cosecha de grupos de procesos de ejecución al salir; al actualizar a la última versión se reducen.

Integraciones y migración

MCP: Vibe Kanban expone y consume MCP — tanto para añadir servidores de terceros a los agentes como para que un agente cree tickets mediante el propio MCP de Vibe Kanban.
Control de versiones: GitHub (PRs, CI) y Azure Repos; integración con la extensión de VSCode/Cursor/Windsurf.
Autoalojamiento: Docker Compose para desplegar la instancia de «Cloud» en cualquier servidor; túneles (Cloudflare Tunnel, ngrok) o el modo túnel por relay (VK_TUNNEL) para acceso remoto.
Migración / salida: dado el sunset, la última versión incluye exportación de datos. Para continuar de forma autónoma, las vías verificables son el modo totalmente local que bloop anunció, o alternativas comunitarias con intención explícita de funcionamiento local sin login (por ejemplo, el fork qwenode/vibe-kanban-promax, «local-only mode, and no login required», y reimplantaciones cleanroom como p-wegner/agentic-kanban).

Métricas actuales

Medición: 1 de septiembre de 2026, API y registros públicos de GitHub / npm.

Métrica	Valor
Estrellas	27.979
Bifurcaciones	2.998
Suscriptores (watchers reales)	119
Incidencias abiertas indicadas por la API	533
Lenguaje principal	Rust
Licencia	Apache License 2.0
Creación	14 de junio de 2025
Último push	24 de abril de 2026
Última publicación	`v0.1.44`, 24 de abril de 2026
Descargas npm (última semana)	2.091 (2026-08-23 → 2026-08-29)
Descargas npm (último mes)	7.386 (2026-07-31 → 2026-08-29)

Los principales contribuidores que devolvió la API, por número de contribuciones, fueron stunningpixels (878), abcpro1 (257), LSRCT (235), actions-user (213) y anastasiya1155 (112).

Caveats: la API de GitHub expone open_issues_count, que incluye solicitudes de cambios abiertas, por lo que 533 no debe leerse como un conteo exclusivo de incidencias. El campo watchers_count de la respuesta general replica las estrellas; por eso se informa por separado subscribers_count (119) como suscriptores reales. El registro npm vibe-kanban (creado el 20 de junio de 2025, 198 versiones, última 0.1.44) describe el paquete como «envoltura NPX de vibe-kanban y vibe-kanban-mcp»; las descargas caen de forma notable respecto a su apogeo, coherente con el cierre de la empresa.

Recepción de la comunidad

La principal conversación verificable es el Show HN 44533004 (11 de julio de 2025, 195 puntos, 132 comentarios, enviado por louiskw). Muestra entusiasmo real y objeciones concretas, por igual:

Elogio:

lharries: «Lo usé la semana pasada y es excelente — la misma sensación de aumento de productividad que cuando usé Cursor por primera vez», y pidió una versión alojada para colaborar con su equipo.
mrlesk (autor de backlog.md, proyecto similar): «vuestro equipo ha hecho un gran trabajo con Vibe Kanban. Me alegra ver más herramientas que intentan resolver la interacción humano-agente».
swyx señaló que Louis «hizo una charla larga y codeó funciones extra en nuestro meetup de Discord» (video de YouTube enlazado en el hilo).
skeptrune conectó con el pasado del equipo: «recuerdo el motor de búsqueda Bloop original».

Crítica y objeciones:

codingdave: «No es solo caos, es un producto no deseado… los productos como este se construyen sobre la suposición de que la IA ha madurado lo suficiente… Vibe coding aún es [inmaduro]».
csomar: «¿Por qué necesita autenticación de GitHub? Pide acceso ilimitado privado al repo. Para mí es un NO rotundo»; y tras la respuesta del equipo, «entonces debieron usar una GitHub App en vez de una OAuth App, porque la App permite selección por grano».
doritosfan84: «los permisos que pide me parecen una locura… ¿por qué un tablero kanban necesita ver mi código o mis claves de despliegue?»; TeMPOraL matizó que «no es “un tablero kanban”, es un orquestador de agentes de código con forma de tablero kanban».
Sobre la premisa de mercado, barbazoo y bwfan123 cuestionaron que «los ingenieros pasan la mayoría de su tiempo planificando, revisando y orquestando», y deepdarkforest contó que al paralelizar, los agentes «colisionan editando archivos a la vez, pierdo el contexto mental y reescriben pruebas».

Además del Show HN, la búsqueda de Hacker News recuperó hilos menores de proyectos derivados que citan a Vibe Kanban (todos con muy poca tracción): 46939622 (claude-vibekanban, 2 puntos), 49367532 (vibe-kanban-alternative con mem0, 1 punto), 48370360 (Circus Chief, 4 puntos), 47638715 (Batty, 2 puntos) y 47019438 (Silo, 2 puntos). No se encontró un anuncio de lanzamiento con una discusión amplia distinta del Show HN principal, por lo que no se infieren cifras de comentarios que las fuentes no muestran.

Comparación con proyectos similares

Proyecto	Coincidencia verificable	Diferencia verificable
`mrlesk/backlog.md`	Kanban para gestionar trabajo de agentes de código; el propio autor de Vibe Kanban y el de backlog.md se citaron mutuamente en el hilo.	backlog.md se centra en planificación con Markdown/tickets; Vibe Kanban añade workspaces con agente, diff en vivo, previsualización y PRs en la UI.
`knowsuchagency/fulcrum` (90★)	Combina orquestación de agentes con despliegue; se autodescribe como mezcla de Vibe Kanban con otras herramientas.	Se posiciona como fusión de varios proyectos (Openclaw, Vibe Kanban, Vibetunnel, Dokploy), no como kanban de agentes puro.
`automagik-dev/forge` (89★)	Kanban multiagente con integración MCP para orquestar agentes y experimentar con intentos aislados.	Enmarca la experiencia como «Vibe Coding++» con énfasis en experimentación de intentos; distinto stack y marca.
`GarrickZ2/grove` (46★)	Gestiona worktrees git como tareas y ejecuta varios agentes en sesiones aisladas.	Es una TUI (terminal) en tmux con notificaciones por hooks, frente a la app de escritorio + web de Vibe Kanban.
`qwenode/vibe-kanban-promax` (13★)	Fork directo de vibe-kanban.	Añade modo solo-local y sin inicio de sesión, orientado a un uso más ligero tras el sunset.

La comparación más útil no es por popularidad: Vibe Kanban destaca como la capa visual de orquestación de agentes con el mayor número de estrellas del conjunto, pero su ventaja práctica (agentes en paralelo + revisión + PR en una UI) ya la replican varias herramientas más pequeñas; su desventaja actual es la incertidumbre de mantenimiento tras el cierre de bloop.

Cómo contribuir

El README documenta un proceso de contribución específico:

Primero hablar con el equipo: «preferimos que las ideas y cambios se planteen primero al equipo central vía GitHub Discussions o Discord, donde podemos discutir detalles de implementación y alineación con la hoja de ruta existente. Por favor, no abran PR sin antes discutir su propuesta con el equipo».
Feature requests → GitHub Discussions; bugs → issues del repositorio.
Desarrollo local: prerrequisitos Rust (estable), Node.js (≥ 20) y pnpm (≥ 8), más cargo install cargo-watch y cargo install sqlx-cli. Se instalan dependencias con pnpm i y el servidor de desarrollo con pnpm run dev (arranca backend y app web, copiando una DB vacía desde dev_assets_seed).
Build de la web: cd packages/local-web && pnpm run build. Build desde fuente en macOS con ./local-build.sh y prueba con cd npx-cli && node bin/cli.js.

Dado el cierre de la empresa, este flujo queda orientado a la edición comunitaria que bloop anunció como próximo paso; conviene verificar en Discussions/Discord el estado actual de aceptación de contribuciones.

Casos de uso

Ingenieros que ejecutan varios agentes de forma secuencial y pierden tiempo esperando: el valor directo documentado es paralelizar workspaces (uno por agente/rama) y pasar del «esperar 2-5 minutos por tarea» a revisar varios diffs en lote. Cada workspace aporta rama, terminal y servidor aislados.
Equipos que quieren un punto único de revisión y entrega: el flujo issue → workspace → diff con comentarios en línea → PR (con descripción generada por IA) → merge cubre la burocracia de control de versiones dentro de la misma interfaz, con integraciones de GitHub y Azure Repos.
Desarrolladores de aplicaciones web que prueban cambios: el navegador integrado con devtools, modo inspección y emulación de dispositivos permite previsualizar y depurar la app sin cambiar de ventana, con click-to-component para saltar a la fuente.
Personas que orquestan con MCP: el servidor MCP propio y la capacidad de añadir MCP de terceros permiten que un agente cree tickets o acceda a más herramientas dentro de Vibe Kanban, útil para automatizar la planificación.
Usuarios que buscan un camino local y autónomo tras el sunset: con la exportación de datos, el modo local anunciado y el ecosistema de forks «local-only / sin login» (p. ej. vibe-kanban-promax), quienes no quieren depender de servicios de nube pueden mantener el patrón kanban + agentes sin cuenta, asumiendo el mantenimiento comunitario.

Recursos

Repositorio: https://github.com/BloopAI/vibe-kanban
Documentación: https://vibekanban.com/docs (índice LLM: https://vibekanban.com/docs/llms.txt)
Anuncio de clausura / sunset: https://www.vibekanban.com/blog/shutdown
Agentes soportados: https://vibekanban.com/docs/supported-coding-agents
Autoalojamiento (Docker): https://vibekanban.com/docs/self-hosting/deploy-docker
Servidor MCP de Vibe Kanban: https://vibekanban.com/docs/integrations/vibe-kanban-mcp-server
Comunidad: GitHub Discussions (https://github.com/BloopAI/vibe-kanban/discussions) y Discord (https://discord.gg/AC4nwVtJM3)
Registros de paquetes: npm vibe-kanban (https://www.npmjs.com/package/vibe-kanban)
Hilos de Hacker News: Show HN 44533004 (195 pts, 132 comentarios); derivados: 46939622, 49367532, 48370360, 47638715, 47019438
Video (referencia del hilo): charla de Louis Knight-Webb en el meetup de swyx (YouTube enlazado en el hilo 44533004, https://www.youtube.com/watch?v=NCksand7Iwo)

Nota: este artículo combina el README y la documentación de Vibe Kanban, el anuncio de clausura de bloop (10 de abril de 2026), la API de GitHub, el registro npm y los hilos de Hacker News consultados el 1 de septiembre de 2026. Las cifras cambian con el tiempo; el proyecto pasa a mantenimiento comunitario tras el cierre de la empresa.