App de escritorio Kanban de código abierto que ejecuta agentes en paralelo en todas las tarjetas

• KanBots es una app de escritorio que ejecuta Claude Code y Codex en paralelo en cada tarjeta Kanban, y muestra en tiempo real el progreso, las decisiones y el costo en el tablero
• Cada ejecución queda aislada en un git worktree separado de la rama kanbots/issue-N, y puedes crear un tablero soltando una carpeta y asignar agentes por tarjeta
• Autopilot recorre personas como producto, ingeniería, revisor y tester con un paralelismo máximo de 4, divide el trabajo y actualiza el backlog
• Los agentes se detienen en los puntos donde hace falta tomar una decisión y presentan opciones; el usuario puede continuar eligiendo un número, corrigiendo y reenviando, o usando /spec, /review y /split
• La app de escritorio adopta una licencia MIT gratuita y un enfoque local-first, mientras que Cloud cuesta $19 al mes por asiento y ofrece sincronización de equipo, notificaciones y dashboards

---

Conceptos básicos de KanBots

• KanBots es una app de escritorio que ejecuta en paralelo agentes de Claude Code y Codex por tarjeta dentro de un tablero Kanban
• Cada agente se ejecuta en un git worktree separado de la rama kanbots/issue-N, y el tablero actualiza en tiempo real el progreso, las solicitudes de decisión y el costo
• Al agregar una carpeta se crea un tablero, y puedes asignar agentes Claude Code o Codex a varias tarjetas
• En el modo de ejecución automática, las personas dividen el trabajo, lo ejecutan en paralelo y revisan los resultados
• La app de escritorio es gratuita, con licencia MIT, basada en donaciones y funciona con un enfoque local-first

Composición del producto y precios

• Desktop OSS

  • Desktop funciona local-first, sin cuenta, sin telemetría, gratis para siempre y con licencia MIT
  • Es compatible con macOS, Linux y Windows, e incluye todas las funciones
  • Entre las funciones principales están la ejecución paralela de agentes, ejecución automática, prompts de decisión, personas integradas y personalizadas, análisis de costos en tiempo real, biblioteca de recipes, kanbots-mcp-server, importación de Sentry, modo GitHub Issues, vista previa de ramas, creación de borradores de PR, soporte para Claude Code y Codex, y hooks pre-push

• Cloud para equipos

  • Cloud es un producto multiusuario hospedado, mientras que los agentes se ejecutan localmente en el hardware del usuario
  • El precio es de $19 al mes por asiento, o $190 con facturación anual
  • Además de las funciones OSS, ofrece presencia en tiempo real en el tablero, notificaciones de asignación a miembros del equipo, sincronización entre dispositivos, notificaciones de Slack, agregación de costos a nivel organización, edición colaborativa de tarjetas en tiempo real, dashboard de actividad de agentes por organización y Managed GitHub App
  • Las funciones Enterprise incluyen logs de auditoría, SSO / SCIM, REST API y PAT, y webhooks salientes
  • Las funciones exclusivas de Cloud se limitan a las que solo tienen sentido cuando hay otra persona u otro dispositivo; lo que usa una sola persona en una sola máquina está incluido en OSS

Herramientas compatibles e integraciones

• Compatible con las CLI de Claude Code y Codex
• Compatible con trabajo sobre GitHub Issues y PR
• Compatible con importación de errores desde Sentry
• Cursor y Claude Desktop pueden integrarse como clientes MCP
• El almacenamiento local usa SQLite
• El shell de escritorio está basado en Electron

Funciones clave

• Ejecución paralela por tarjeta

  • Se pueden ejecutar agentes al mismo tiempo en varias tarjetas, y cada ejecución avanza en su propio git worktree y rama kanbots/issue-N
  • El tablero actualiza en tiempo real el progreso de la ejecución, las solicitudes de decisión de los agentes y el costo acumulado

• Ejecución automática y personas

  • Puedes conectar personas como producto, ingeniería, revisor y tester, y configurar el paralelismo hasta un máximo de 4
  • El orquestador recorre las personas en round-robin, divide los issues principales en tareas hijas y actualiza el backlog con el trabajo que descubren los agentes
  • Una persona puede crear otras personas

• Ejecución centrada en decisiones

  • Cuando los agentes encuentran una decisión necesaria, se detienen y muestran opciones
  • El usuario puede continuar eligiendo un número, corrigiendo y reenviando, o usando comandos slash como /spec, /review y /split
  • En lugar de cambiar el árbol de trabajo en silencio, se conserva un flujo de decisiones revisable

• Integración con Claude Code y Codex

  • Claude Code o Codex pueden usarse en el mismo tablero, el mismo worktree y la misma interfaz de decisiones
  • KanBots maneja ambos formatos de stream detrás de un único AgentCliAdapter
  • Puedes usar claude /login existente o OPENAI_API_KEY

• Almacenamiento local-first

  • Todos los datos se guardan dentro de .kanbots/ junto al repositorio
  • La base de datos SQLite, la configuración y los worktrees se almacenan localmente
  • No hay cuenta en la nube, telemetría ni servidor HTTP, y el código no sale de la máquina

• Análisis de costos y límites de presupuesto

  • Proporciona agregación de costos por ejecución, por tarjeta y por proyecto
  • El medidor de costos se acumula mientras trabajan los agentes
  • Se pueden configurar límites por ejecución y por sesión, y la ejecución se detiene al llegar al presupuesto

• Flujo de trabajo con GitHub

  • Puedes trabajar con issues reales de GitHub usando un PAT personal
  • Puedes promover un worktree a commit o abrir un PR en borrador con un clic
  • Un hook pre-push evita que el agente publique por sí solo

• Servidor MCP

  • kanbots-mcp-server expone el tablero mediante Model Context Protocol
  • Cursor, Claude Desktop o cualquier herramienta que entienda MCP puede operar sobre el tablero
  • El tablero se convierte en una herramienta que otros agentes pueden usar

Flujo de trabajo interno de la app

• Autopilot

  • Seleccionas una o más personas, defines el paralelismo y arrancas la ejecución automática
  • Hasta 4 slots en paralelo recorren en round-robin la lista de personas
  • Cada slot toma atómicamente la siguiente persona, y los agentes dividen los issues principales en tareas hijas mientras avanzan
  • Se detiene al completarse o al alcanzar el presupuesto de la sesión
  • La pantalla de ejemplo muestra Claude Opus 4.7, esfuerzo medium, paralelismo 2 y las personas Product Manager y Senior Engineer seleccionadas

• Decisions

  • El hilo de ejecución transmite en tiempo real todos los tool_use y tool_result
  • Cuando el agente llega a un punto que requiere criterio, pausa la ejecución y presenta opciones numeradas
  • El campo de respuesta acepta comandos como /spec, /review y /split
  • En el ejemplo de implementación de token para restablecimiento de contraseña, se muestran opciones como JWT de un solo uso, token opaco guardado en la DB, magic link o explicar primero los trade-offs
  • La pantalla de ejecución muestra modelo, tiempo transcurrido, cantidad de tokens, costo, estado, prioridad, carpeta, worktree, rama, rama base y autor

• Personas

  • Una persona es un fragmento de system prompt con nombre
  • Las personas predeterminadas vienen incluidas en la app, y el usuario puede escribir, guardar y reutilizar nuevas personas
  • Las personas personalizadas se almacenan localmente en esa máquina
  • Los ejemplos incluidos por defecto son Product Manager, Senior Engineer, UX Designer, Growth Lead y Reliability Engineer

• Providers

  • Claude Code y Codex pueden usarse detrás de un mismo AgentCliAdapter
  • Reutiliza claude /login o codex login existentes, sin necesidad de cuentas adicionales ni manejo extra de claves
  • Puedes cambiar de proveedor en cada ejecución
  • La CLI de Codex requiere que codex esté en el PATH, y la redacción de borradores de issues y el análisis de Sentry siguen ejecutándose en Claude
  • El login de Codex puede abrir auth.openai.com en el navegador o usar la variable de entorno OPENAI_API_KEY

• Tasks

  • Las tareas nuevas ofrecen plantillas para corrección de bugs, funciones, refactorización, review y spike
  • Puedes elegir entre empezar con spec-first, ejecutar de inmediato al crear o poner en cola para después
  • El título se usa como nombre de la rama y del PR
  • spec-first ejecuta /spec, refina los criterios de aceptación y deja la tarea pendiente de aprobación
  • Una tarea nueva crea un worktree limpio y genera una rama bajo .kanbots/worktrees/issue-N con base en main

• Chat

  • Se ofrece un agente general para hacer preguntas sobre el workspace
  • El agente conoce el repositorio, las pruebas y el estado de git, y responde preguntas
  • Se muestra un ejemplo para encontrar rutas API sin rate limiting, agregar rateLimit({ windowMs: 60_000, max: 10 }) a /api/login y /api/signup, y luego escribir pruebas hasta que pasen

Cómo funciona Autopilot

• Autopilot es un modo que toma issues y presupuesto y actualiza el backlog por su cuenta
• El orquestador recorre la lista de personas en round-robin y ejecuta hasta 4 slots en paralelo
• Divide los issues principales en tareas hijas y sigue iterando hasta que el trabajo converge o se alcanza el límite de costo
• El ejemplo muestra paralelismo 4, modelo opus 4.7, presupuesto de sesión de $25.00 con $4.27 usados y estado del ciclo 14

• Selección de lista de personas

  • Puedes usar las personas predeterminadas o definir tus propios system prompts para guardarlos y reutilizarlos
  • Las personas personalizadas no salen de la máquina

• Configuración de paralelismo

  • El paralelismo puede configurarse de 1 a 4
  • Cada slot toma atómicamente la siguiente persona mediante un contador round-robin
  • Cuatro agentes pueden ejecutarse al mismo tiempo con cuatro perspectivas y cuatro worktrees

• División de tareas

  • Cuando un agente descubre trabajo, crea una nueva tarjeta en el tablero
  • Luego los ciclos siguientes toman esas nuevas tarjetas, y el backlog crece y se reduce bajo el orquestador

• Detención por presupuesto o finalización

  • El presupuesto de costo por sesión limita el gasto total
  • El botón de detener termina la ejecución padre y todas las ejecuciones hijas
  • Las ejecuciones en curso completan limpiamente su iteración actual

Modo QA

• Modo QA ejecuta typecheck, tests, lint, build y e2e dentro del worktree
• Si hace falta, puede iniciar y supervisar el servidor de desarrollo
• Para cada verificación fallida, asigna una ejecución de corrección en un issue hijo derivado
• Repite hasta que las verificaciones pasen

Forma de entrega y cierre

• La app de escritorio OSS se ofrece gratis, con licencia MIT y sin cuenta
• Se enfatiza un flujo donde todas las ejecuciones de agentes se visualizan sobre Kanban, pueden decidirse y quedan aisladas
• Cuando un equipo necesita compartir el tablero, puede cambiar a Cloud
• Los formatos de descarga son macOS .dmg, Windows .exe y Linux .AppImage / .tar.xz

[GN⁺]

Comentarios en Hacker News

• Sigo preguntándome cómo recibe la gente los resultados del trabajo nocturno de los agentes
  Incluso en repositorios de proyectos personales, siento que el resultado de 30 minutos de planificación y 30 minutos de implementación ya es demasiado grande para revisar. Después de unos 5 minutos, a veces termino diciéndole a la IA que lo rehaga incluso mientras sigue soltando código

  • La narrativa actual se centra en que la IA escribe todo o la mayor parte del código, pero en la práctica parece que la proporción de código revisado por humanos se está acercando a 0 mucho más rápido de lo que la gente percibe o quiere admitir
  • Gran parte de esa actividad de agentes consiste en repasar lo ya construido e imponer restricciones para que, al momento de revisar, el resultado que llegue al escritorio sea más o menos predecible
    Personalmente, una estructura de archivos sólida también ayuda. Revisar un archivo de 3,000 líneas recién generado es lo peor, y no aceptaría ese tipo de resultado ni de una persona ni de una máquina. Si está dividido en varios archivos en los lugares correctos, baja la carga cognitiva
    A veces también reviso junto con el agente mientras conversamos. Por ejemplo, le pregunto cuál es el archivo más importante que debería revisar primero
    Me gusta dejar los cambios preparados en una pila de “LGTM”. Si después hace falta corregir algo, le digo al agente: “Revisa los cambios no preparados. Aquí me habría gustado que lo hicieras de otra forma”
  • Nadie revisa el código. Los gerentes tampoco quieren que revisemos el código. Es un cuello de botella
    Si algo sale mal, o sea, si aparece un bug, se arregla en el momento. Es una época muy triste para la ingeniería de software. Si alguna vez hubo ingeniería en nuestra industria, ya casi no queda, y ahora andamos adivinando con archivos de skills como “por favor no metas bugs” o “no eres inquilino, eres dueño”
    El nivel de esfuerzo es bajo y el determinismo también es muy bajo. Apps grandes como GitHub se siguen cayendo por basura generada por IA, y en sistemas menos conocidos se ve todavía más seguido. Lo mismo pasa en nuestra empresa o en otros SaaS que usamos
    A los product managers nunca les importó mucho el código, a los managers de ingeniería ya no les importa tanto como cuando eran ingenieros, a los directores no les importa en absoluto, y el CTO ya ni sabe cómo se ve el código
    Nosotros estamos al final de la cadena y siempre nos enorgullecimos de escribir código útil y mantenible porque sabíamos profundamente que los buenos sistemas se construyen sobre buen código. Pero ahora nos estamos poniendo en riesgo, y quienes ya no cuidan el código somos precisamente los ingenieros, mientras la IA amplifica ese problema
  • Normalmente mi meta es que, después de que Claude trabaje toda la noche, al final queden unas 500 líneas de código
    La mayor parte del tiempo se va en probar distintos enfoques y resumirlos, para luego dejarme una diferencia relativamente pequeña que yo pueda revisar y corregir
  • Yo también tengo la misma duda. La respuesta que normalmente escucho de quienes realmente lo usan bien es que no miran el código, o al menos no en detalle
    Personalmente, siempre termino retocando algo de lo que produce el agente. Me pregunto si debería soltar ese control

• Esto me recuerda a Vibe Kanban(https://vibekanban.com/), que es lo que uso para gestionar agentes de código en la mayoría de los proyectos
  Lamentablemente, los desarrolladores de Vibe Kanban concluyeron que no veían un camino claro de monetización y dejaron de invertir en el proyecto. Como es open source, todavía se puede correr en local o hacer un fork, pero el desarrollo se detuvo y aún quedan bugs molestos por arreglar. Yo no tengo tiempo para mantenerlo por mi cuenta
  Me da pena, porque sí habría estado dispuesto a pagar por Vibe Kanban. Solo que no necesitaba las funciones del plan de pago. Viéndolo en retrospectiva, quizá debí pagar de todos modos
  También voy a probar Kanbots. Hasta podría copiar agresivamente las funciones de Vibe Kanban. En especial, el soporte remoto y el botón “Open in VS Code” son claves para mí. En mi caso, ese botón abre un cliente local de VSCode que apunta a un servidor remoto de VSCode

  • Vibe Kanban es realmente un tesoro en cuanto a funciones útiles
    Durante la última o las últimas dos semanas he estado trabajando en llevar una nueva herramienta al nivel de paridad funcional con VK, además de meter mejoras adicionales. También subí algunas capturas al Discord de Vibe Kanban. Cuando esté lista para lanzarse, espero que también encaje bien con tu caso de uso
    Mi herramienta apunta a tener mejores funciones que VK tanto en el tablero Kanban como en el espacio de trabajo de agentes, y también incluye sistemas adicionales como gestión de ventanas de escritorio, plugins, integración de VSCode en el navegador y una UI renderizada en servidor parecida a htmx
    El enfoque de acceso remoto también es distinto. En vez de levantar un servidor web en una laptop para acceder a agentes remotos de coding, se hospeda todo al estilo OpenClaw y se accede a una UI de escritorio remoto desde el navegador

• El hecho de que sea “local-first, sin servidor. Todo está en .kanbots/ junto al repositorio: base de datos SQLite, configuración, worktrees. Sin cuenta en la nube, sin telemetría, sin servidor HTTP. Esta es la edición de escritorio open source” es una condición básica para considerar adoptar una herramienta así

  • No sé a qué se refiere exactamente con “una herramienta así”
    Si la IA es agéntica, esperaría que cualquier product manager pudiera pasar una hora conversando e integrar Jira con algún loop de agentes
    Jira, Trello, Linear y Basecamp tienen API, y supongo que también habrá CLI que los agentes puedan usar. No debería hacer falta un desarrollador ni un SaaS para hacerles entender que, al empezar una tarea, se hace checkout del ticket, se toman sus instrucciones y al terminar se mueve a DONE
  • En la página dice que, incluso si lo usas en local, para que esta función opere hace falta iniciar sesión con una cuenta en la nube, así que decidí no probarlo
    Si soy sincero, sí se ve genial. Pero ya hay bastantes herramientas que se ven geniales

• La palabra “Kanban” originalmente la usó Toyota para describir un sistema de tarjetas, y ese sistema servía para cumplir varios objetivos importantes, como no hacer demasiadas cosas al mismo tiempo y visualizar el trabajo
  En general, Kanban se usaba para gestionar el flujo de trabajo de forma que no pasaran defectos
  Pero esta herramienta se parece más a “empujar para que se genere en paralelo la mayor cantidad de trabajo posible”. No gestiona el flujo de entregables de calidad ni limita el trabajo. Solo le avienta todo a los agentes y quema tokens como loco
  De verdad me molesta que a esto le llamen “Kanban”. Se siente casi como una blasfemia

• Cuando he dejado correr agentes sin supervisión, he tenido más frustraciones que éxitos
  Creo que la tecnología eventualmente llegará a eso, pero por ahora cada agente necesita su propio IDE y además fusionar el trabajo es engorroso

• Comparto un proyecto open source reciente. Es un tablero Kanban con agentes en paralelo
  Quiero mejorarlo con más funciones, y agradecería contribuciones al repositorio, ya sea código o ideas

  • Buen trabajo. Yo había probado hacer que agentes internos ejecutaran Kanban clasificando por workflow dentro de proyectos existentes de Jira, así que me dio gusto ver este proyecto hoy en HN
    Parece que va a ser entretenido seguir cómo evoluciona
  • Te recomendaría revisar el post de minions en el blog de ingeniería de Stripe. La dirección se ve parecida

• ¿No es básicamente lo que ya está haciendo Windsurf? Al final, todas estas interfaces no son más que adorno montado sobre un agente
  [0] https://windsurf.com/blog/windsurf-2-0

  • Hay varias apps que ayudan a pasarle cosas a agentes desde un tablero Kanban
    Yo necesitaba un flujo más con intervención humana. No me sirve una forma de entregarle algo al agente sin poder ver bien el conjunto de cambios ni tener oportunidad de cambiar el rumbo
    https://www.agentkanban.io conecta, mediante una extensión, el tablero de tareas con GitHub Copilot Chat en VS Code, de modo que obtienes tanto gestión de tareas como captura de contexto desde el chat hacia las tareas. Así puedes aprovechar las ventajas del entorno de ejecución superior que es VS Code junto con funciones de gestión de tareas y proyectos
  • No veo cuál sería el problema aquí. ¿Lo hay?
    Linear también está trabajando directamente en esta dirección
  • ¿Windsurf es open source?

• Lo que no entiendo de estas herramientas es cómo manejan el levantamiento de infraestructura entre distintos worktrees
  Por ejemplo, si tienes una webapp, cada worktree debería levantar su propia infraestructura y poder accederse mediante una URL local única. Solo así puedes ver localmente los cambios de cada worktree o hacer que un agente, con algo como agent-browser, automatice la verificación visual
  Actualmente uso Docker para la infraestructura, y cada servicio corre en su propio contenedor. Tengo un script ./app worktree create worktreename, y ese script crea el worktree “worktreename” y luego levanta toda la infraestructura de Docker anteponiendo un prefijo tipo “WORKTREENAME”. Así, todas las URL quedan accesibles en worktreename.myapp.test, mientras que el worktree principal usa simplemente myapp.test
  Por ahora funciona bien, pero estaría bueno poder migrar a una de estas apps si alguna fuera compatible con este concepto

  • En el trabajo teníamos el mismo problema, así que le pedí a CC que me hiciera una herramienta CLI en bun súper simple para crear, borrar y listar worktrees
    Ese CLI llena el archivo .env con la URL y la base de datos correspondientes para ese worktree, y levanta un servidor de desarrollo en un puerto único usando portless, el paquete open source de Vercel. Así cada worktree obtiene su propia URL
  • Deberías revisar emdash.sh. Cada tarea levanta su propio worktree y se le inyectan variables de entorno predefinidas
    Eso incluye EMDASH_PORT, que es un puerto único dentro de un rango de 10 puertos. Es muy útil cuando ejecutas varios servicios dentro de un solo monorepo
  • Yo uso scripts de shell para crear y eliminar worktrees
    El script de shell encuentra un puerto único libre entre todos los worktrees existentes y lo asigna al .env local al crear el worktree. Cuando el worktree se fusiona y se elimina, el puerto también se libera
    Los secretos que no son por worktree no los dejo en el .env local, sino que los inyecto desde shell
    Sinceramente, escribir este tipo de scripts locales para automatizar trabajo de desarrollo fue muy sencillo, y además se integran bien con cualquier otra herramienta CLI. Por eso todavía no he probado ninguna app con GUI. No sé si puedan competir con una configuración local hecha a medida que funciona exactamente como yo quiero
  • ¿No bastaría con usar direnv? Habría que ajustar el puerto que hospeda la página local, pero podrías tomar N=mod(...) a partir de un hash basado en el nombre del worktree y luego hacer port=default_port+N
    Solo pídele a Claude que te lo configure. Lo va a resolver con un solo prompt

• “‘kanbots’ está dañado y no se puede abrir. Debe moverlo a la Papelera”
  Es un error demasiado apropiado para encontrárselo por primera vez en software de vibe coding

• ¿Esto no es simplemente vibe-kanban?
  https://github.com/BloopAI/vibe-kanban

  • Puede haber competencia
  • Literalmente está en Bloop. Es original de Bloop.