App desktop open source de Kanban que executa agentes em paralelo em todos os cartões

 (kanbots.dev)
1 pontos por GN⁺ 8 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • KanBots é um app desktop que executa Claude Code e Codex em paralelo em cada cartão Kanban e mostra em tempo real o progresso, as decisões e os custos no quadro
  • Cada execução fica isolada em um git worktree separado no branch kanbots/issue-N, e é possível criar um quadro adicionando uma pasta e atribuir agentes por cartão
  • O Autopilot percorre personas como produto, engenharia, revisor e testador com paralelismo máximo de 4, divide o trabalho e atualiza o backlog
  • Os agentes param nos pontos em que é preciso tomar uma decisão e apresentam opções; o usuário pode continuar escolhendo um número, reenviando com ajustes ou usando /spec, /review, /split
  • O app desktop adota uma abordagem local-first com licença MIT gratuita, enquanto o Cloud oferece sincronização de equipe, notificações e dashboards por US$ 19 por assento/mês

Conceitos básicos do KanBots

  • KanBots é um app desktop que executa agentes Claude Code e Codex em paralelo por cartão em um quadro Kanban
  • Cada agente roda em um git worktree separado no branch kanbots/issue-N, e o quadro atualiza em tempo real o progresso, os pedidos de decisão e os custos
  • Ao adicionar uma pasta, o quadro é criado, e é possível atribuir agentes Claude Code ou Codex a vários cartões
  • No modo de execução automática, as personas dividem o trabalho, executam em paralelo e revisam os resultados
  • O app desktop é gratuito, sob licença MIT, baseado em doações e funciona com abordagem local-first

Estrutura do produto e preços

  • Desktop OSS

    • O Desktop é local-first, sem conta, sem telemetria, gratuito para sempre e sob licença MIT
    • Suporta macOS, Linux e Windows e inclui todos os recursos
    • Os principais recursos incluem execução paralela de agentes, execução automática, prompts de decisão, personas embutidas e personalizadas, análise de custos em tempo real, biblioteca de receitas, kanbots-mcp-server, importação do Sentry, modo GitHub Issues, prévia de branch, criação de rascunho de PR, suporte a Claude Code e Codex e hook de pre-push

  • Cloud para equipes

    • O Cloud é um produto multiusuário hospedado, enquanto os agentes continuam rodando localmente no hardware do usuário
    • O preço é de US$ 19 por assento/mês, ou US$ 190 com cobrança anual
    • Além dos recursos OSS, oferece presença em tempo real no quadro, notificações de atribuição para membros da equipe, sincronização entre dispositivos, notificações no Slack, agregação de custos de toda a organização, edição colaborativa de cartões em tempo real, dashboard de atividade de agentes por organização e Managed GitHub App
    • Os recursos Enterprise incluem logs de auditoria, SSO / SCIM, REST API e PAT, além de webhooks de saída
    • Os recursos exclusivos do Cloud são limitados ao que faz sentido apenas quando há outras pessoas ou outros dispositivos; tudo o que uma única pessoa usa em uma única máquina está incluído no OSS

Ferramentas compatíveis e integrações

  • Suporta as CLIs Claude Code e Codex
  • Suporta GitHub Issues e trabalho com PRs
  • Suporta importação de erros do Sentry
  • Cursor e Claude Desktop podem ser integrados como clientes MCP
  • O armazenamento local usa SQLite
  • O shell desktop é baseado em Electron

Recursos principais

  • Execução paralela de cartões

    • É possível executar agentes simultaneamente em vários cartões, e cada execução acontece em seu próprio git worktree e branch kanbots/issue-N
    • O quadro atualiza em tempo real o andamento da execução, os pedidos de decisão do agente e o custo acumulado

  • Execução automática e personas

    • É possível conectar personas como produto, engenharia, revisor e testador, e definir paralelismo de até 4
    • O orquestrador percorre as personas em round-robin, divide issues de nível superior em tarefas menores e atualiza o backlog com as tarefas descobertas pelos agentes
    • Personas podem criar outras personas

  • Execução centrada em decisões

    • Os agentes param quando encontram uma decisão necessária e exibem opções
    • O usuário pode continuar a execução escolhendo um número, reenviando com ajustes ou usando comandos com barra como /spec, /review, /split
    • Em vez de alterar silenciosamente a árvore de trabalho, o sistema deixa um fluxo de decisões revisável

  • Integração com Claude Code e Codex

    • Claude Code ou Codex podem ser usados no mesmo quadro, no mesmo worktree e na mesma interface de decisões
    • O KanBots trata os dois formatos de stream por trás de um único AgentCliAdapter
    • É possível usar o claude /login existente ou OPENAI_API_KEY

  • Armazenamento local-first

    • Todos os dados ficam dentro de .kanbots/, ao lado do repositório
    • Banco de dados SQLite, configurações e worktrees ficam armazenados localmente
    • Não há conta em nuvem, telemetria, servidor HTTP, nem o código sai da máquina

  • Análise de custos e limites de orçamento

    • Fornece agregação de custos por execução, cartão e projeto
    • Um medidor de custo se acumula durante o trabalho dos agentes
    • É possível definir limites por execução e por sessão, e a execução é interrompida ao atingir o orçamento

  • Fluxo de trabalho com GitHub

    • É possível trabalhar com issues reais do GitHub usando um PAT pessoal
    • Dá para promover um worktree a commit ou abrir um rascunho de PR com um clique
    • Um hook de pre-push impede que os agentes publiquem por conta própria

  • Servidor MCP

    • O kanbots-mcp-server expõe o quadro por meio do Model Context Protocol
    • Cursor, Claude Desktop ou qualquer ferramenta que entenda MCP podem operar o quadro
    • O quadro se torna uma ferramenta utilizável por outros agentes

Fluxo de trabalho dentro do app

  • Autopilot

    • Selecione uma ou mais personas, defina o paralelismo e inicie a execução automática
    • Até 4 slots paralelos percorrem a lista de personas em round-robin
    • Cada slot obtém atomicamente a próxima persona, e o agente divide issues de nível superior em subtarefas durante o andamento
    • A execução para ao concluir ou ao atingir o orçamento da sessão
    • A tela de exemplo mostra Claude Opus 4.7, esforço medium, paralelismo 2 e as personas Product Manager e Senior Engineer selecionadas

  • Decisions

    • A thread de execução transmite em tempo real todos os tool_use e tool_result
    • Quando o agente chega a um ponto que exige julgamento, ele pausa a execução e apresenta opções numeradas
    • O campo de resposta aceita comandos como /spec, /review, /split
    • No exemplo de implementação de token de redefinição de senha, aparecem opções como JWT de uso único, token opaco armazenado no banco, magic link ou explicar primeiro os trade-offs
    • A tela de execução mostra modelo, tempo decorrido, número de tokens, custo, status, prioridade, pasta, worktree, branch, branch base e autor

  • Personas

    • Uma persona é um trecho nomeado de prompt de sistema
    • Personas padrão vêm incluídas no app, e o usuário pode criar, salvar e reutilizar novas personas
    • Personas personalizadas são armazenadas localmente naquela máquina
    • Os exemplos padrão incluem Product Manager, Senior Engineer, UX Designer, Growth Lead e Reliability Engineer

  • Providers

    • Claude Code e Codex podem ser usados por trás de um único AgentCliAdapter
    • Reaproveita o claude /login ou codex login existente, sem necessidade de conta extra ou gerenciamento adicional de chaves
    • É possível alternar de provedor a cada execução
    • A CLI do Codex exige que codex esteja no PATH, e a criação de rascunhos de issue e a análise do Sentry continuam rodando no Claude
    • O login do Codex pode abrir auth.openai.com no navegador ou usar a variável de ambiente OPENAI_API_KEY

  • Tasks

    • Novas tarefas oferecem templates de correção de bug, recurso, refatoração, revisão e spike
    • É possível escolher entre spec-first, executar imediatamente após criar ou enfileirar para depois
    • O título é usado como nome do branch e título do PR
    • spec-first executa /spec, refina os critérios de aceitação e deixa a tarefa aguardando aprovação
    • Uma nova tarefa cria um worktree limpo e gera um branch em .kanbots/worktrees/issue-N com base na main

  • Chat

    • Há um agente genérico para fazer perguntas sobre o workspace
    • O agente conhece o repositório, os testes e o estado do git, e responde às perguntas
    • É apresentado um exemplo que encontra rotas de API sem rate limiting, adiciona rateLimit({ windowMs: 60_000, max: 10 }) a /api/login e /api/signup, e depois escreve testes até que passem

Como o Autopilot funciona

  • O Autopilot é um modo que recebe issues e orçamento e atualiza o backlog por conta própria
  • O orquestrador percorre a lista de personas em round-robin e executa até 4 slots em paralelo
  • Ele divide issues de alto nível em subtarefas e continua ciclando até o trabalho convergir ou o limite de custo ser atingido
  • O exemplo mostra paralelismo 4, modelo opus 4.7, orçamento de sessão de US$ 25.00 com US$ 4.27 usados e o estado do 14º ciclo

  • Seleção da lista de personas

    • É possível usar as personas padrão ou definir, salvar e reutilizar prompts de sistema próprios
    • Personas personalizadas não saem da máquina

  • Configuração do paralelismo

    • O paralelismo pode ser definido de 1 a 4
    • Cada slot obtém atomicamente a próxima persona por meio de um contador round-robin
    • Quatro agentes podem rodar ao mesmo tempo com quatro perspectivas e quatro worktrees

  • Divisão de tarefas

    • Quando um agente descobre trabalho, ele cria novos cartões no quadro
    • Ciclos posteriores assumem os novos cartões, e o backlog cresce e encolhe sob o orquestrador

  • Parada por orçamento ou conclusão

    • O orçamento de custo por sessão limita o gasto total
    • O botão de parar encerra a execução pai e todas as execuções filhas
    • Execuções em andamento concluem a iteração atual de forma limpa

Modo QA

  • O modo QA executa typecheck, tests, lint, build e e2e dentro do worktree
  • Se necessário, pode iniciar e monitorar o servidor de desenvolvimento
  • Para cada verificação que falhar, atribui uma execução de correção em uma issue filha derivada
  • Repete até que as verificações passem

Forma de distribuição e encerramento

  • O app desktop OSS é oferecido gratuitamente, sob licença MIT e sem conta
  • O foco está em colocar todas as execuções dos agentes sobre um Kanban para torná-las visíveis, passíveis de decisão e isoladas
  • Quando a equipe precisa compartilhar o quadro, pode migrar para o Cloud
  • Os formatos de download são macOS .dmg, Windows .exe e Linux .AppImage / .tar.xz

Leituras relacionadas

1 comentários

 
GN⁺ 8 시간 전
Comentários do Hacker News

  • Continuo me perguntando como as pessoas recebem os resultados de um agente trabalhando a noite toda
    Mesmo em repositórios de projetos paralelos pessoais, sinto que o resultado de 30 minutos planejando e 30 minutos implementando já fica grande demais para revisar. Depois de uns 5 minutos, às vezes acabo mandando a IA refazer, mesmo enquanto o código ainda está jorrando

    • A narrativa atual se concentra em dizer que a IA escreve todo ou a maior parte do código, mas na prática acho que a proporção de código revisado por humanos provavelmente está se aproximando de zero muito mais rápido do que as pessoas percebem ou admitem
    • Boa parte dessa atividade de agentes é vasculhar o que já foi feito antes e impor restrições à força para tornar um pouco previsível o que vai aparecer na mesa na hora da revisão
      Pessoalmente, uma estrutura de arquivos rígida também ajuda. Revisar um arquivo de 3.000 linhas que acabou de ser gerado é o pior cenário, e eu não aceitaria esse tipo de resultado nem de uma pessoa nem de uma máquina. Quando fica dividido em vários arquivos, cada um no lugar certo, a carga cognitiva diminui
      Às vezes também reviso junto conversando com o agente. Pergunto, por exemplo, quais são os arquivos mais importantes para revisar primeiro
      Gosto de deixar as mudanças preparadas na pilha de “LGTM”. Se depois precisar de ajustes, peço ao agente: “revise as mudanças não staged. Aqui eu queria que fosse feito de outra forma”
    • Ninguém revisa código. Os gerentes também não querem que a gente revise código, porque isso vira gargalo
      Se algo der errado, ou seja, se surgir um bug, a gente corrige conforme aparece. É uma era muito triste da engenharia de software. Se já existiu engenharia no nosso setor, agora ela em grande parte desapareceu, e estamos só chutando com arquivos de skills do tipo “não introduza bugs” ou “você não é inquilino, é dono”
      O nível de esforço é baixo e o grau de determinismo também é muito baixo. Aplicativos grandes como o GitHub estão ficando fora do ar repetidamente por causa de lixo gerado por IA, e isso aparece com ainda mais frequência em sistemas menos conhecidos. O mesmo vale para a nossa empresa e para outros SaaS que usamos
      Gerentes de produto nunca ligaram para código, gerentes de engenharia não ligam para código tanto quanto ligavam quando eram engenheiros. Diretores não se importam nem um pouco com código, e o CTO agora nem sabe mais como o código se parece
      Nós estamos no fim dessa corrente e sempre tivemos orgulho de escrever código bem-feito e de fácil manutenção, porque entendíamos profundamente que bons sistemas são construídos sobre bom código. Mas agora estamos nos colocando em risco, e justamente nós, os engenheiros, somos quem já não liga mais para o código, enquanto a IA amplifica esse problema
    • Normalmente eu trabalho com a meta de que, depois de uma noite inteira do Claude, sobrem no final cerca de 500 linhas de código
      A maior parte do tempo é gasta testando várias abordagens e resumindo tudo para me entregar uma diferença relativamente pequena que eu consiga revisar e ajustar
    • Tenho a mesma dúvida. O que costumo ouvir de quem realmente opera isso bem é que não olham o código, ou pelo menos não olham em detalhe
      Pessoalmente, sempre acabo mexendo em alguma coisa no resultado que o agente produz. Fico pensando se preciso largar esse controle

  • Isso me lembra o Vibe Kanban(https://vibekanban.com/), que uso para gerenciar agentes de codificação na maioria dos projetos
    Infelizmente, os desenvolvedores do Vibe Kanban concluíram que não viam um caminho de monetização e pararam de investir no projeto. Como é open source, dá para rodar localmente ou fazer fork, mas o avanço parou e ainda restam bugs irritantes a corrigir. Eu pessoalmente não tenho tempo para manter
    Eu toparia pagar pelo Vibe Kanban, então é uma pena. Só que eu não precisava dos recursos do plano pago. Olhando para trás, talvez eu devesse simplesmente ter pago
    Vou testar o Kanbots também. Acho que ele pode copiar sem medo os recursos do Vibe Kanban. Em especial, o suporte remoto e o botão “Open in VS Code” são essenciais para mim. No meu caso, esse botão abre o cliente local do VSCode apontando para um servidor remoto do VSCode

    • O Vibe Kanban é realmente um tesouro em termos de recursos úteis
      Nas últimas 1–2 semanas, estive trabalhando para levar a nova ferramenta à paridade funcional com o VK e ainda adicionar melhorias extras. Também publiquei algumas capturas de tela no Discord do Vibe Kanban. Quando estiver pronta para lançamento, espero que atenda bem ao seu caso de uso também
      Minha ferramenta mira recursos melhores que o VK tanto no quadro Kanban quanto no espaço de trabalho dos agentes, e também inclui sistemas adicionais como gerenciamento de janelas no desktop, plugins, integração do VSCode no navegador e uma UI renderizada no servidor ao estilo do htmx
      A abordagem de acesso remoto também é diferente. Em vez de subir um servidor web no notebook para acessar agentes de programação remotos, como no OpenClaw, eu hospedo tudo e acesso a UI de desktop remoto pelo navegador

  • O fato de ser “local-first, sem servidor. Tudo fica em .kanbots/ ao lado do repositório: banco SQLite, configuração, worktrees. Sem conta na nuvem, sem telemetria, sem servidor HTTP. Esta é a edição desktop open source” é um requisito básico para eu considerar adotar uma ferramenta dessas

    • Não sei ao certo ao que “ferramenta dessas” se refere
      Se a IA for do tipo agente, eu esperaria que qualquer gerente de produto conseguisse passar uma hora conversando e integrar Jira com algum loop de agente
      Jira, Trello, Linear e Basecamp todos têm API, e imagino que também exista CLI para o agente usar. Não deveria ser necessário um desenvolvedor ou um SaaS para fazê-lo entender que, quando uma tarefa começa, o ticket é checked out e traz as instruções, e quando termina vai para DONE
    • Pela página, parece dizer que, mesmo usando localmente, esse recurso exige login em conta na nuvem para funcionar, então resolvi nem tentar
      Sinceramente, parece legal. Mas já existem várias ferramentas que parecem legais

  • Originalmente, a palavra “Kanban” foi usada pela Toyota para descrever um sistema de cartões, e esse sistema servia a alguns objetivos importantes, como evitar trabalho demais ao mesmo tempo e visualizar o trabalho
    De modo geral, Kanban era usado para gerenciar o fluxo de trabalho para que defeitos não passassem adiante
    Mas esta ferramenta parece mais “empurrar a geração do máximo possível de trabalho em paralelo”. Ela não gerencia um fluxo de entregas com qualidade, nem limita o trabalho em andamento. Só enfia tudo nos agentes e torra tokens como se não houvesse amanhã
    Chamar isso de “Kanban” me incomoda muito. Parece até blasfêmia

  • Quando tentei deixar agentes rodando sem supervisão, tive mais frustração do que sucesso
    Acredito que a tecnologia vai chegar lá no fim, mas no momento cada agente precisa de uma IDE, e juntar o trabalho depois é um incômodo

  • Estou compartilhando um projeto open source recente. É um quadro Kanban com agentes paralelos
    Estou tentando melhorá-lo com mais recursos, e seria ótimo se vocês contribuíssem no repositório, seja com código ou com ideias

    • Bom trabalho. Já tentei fazer meus próprios agentes rodarem Kanban, classificando por workflow dentro de um projeto Jira existente, então foi legal ver este projeto hoje no HN
      Acho que vai ser divertido acompanhar o andamento do trabalho
    • Vale a pena conferir o post sobre minions no blog de engenharia da Stripe. A direção parece parecida

  • Isso não é basicamente o que o Windsurf já está fazendo? No fim, todas essas UIs são só maquiagem em cima de agentes
    [0] https://windsurf.com/blog/windsurf-2-0

    • Existem alguns apps que ajudam a passar trabalho para agentes a partir de um quadro Kanban
      Para mim, era necessário um fluxo com mais intervenção humana. Não combina comigo entregar para o agente sem conseguir ver bem o conjunto de mudanças nem ter chance de corrigir a direção
      https://www.agentkanban.io conecta, por meio de uma extensão, o quadro de tarefas ao GitHub Copilot Chat no VS Code, de modo que você ganha tanto o gerenciamento das tarefas quanto a captura de contexto que vai da conversa para a tarefa. Assim dá para aproveitar as vantagens do ambiente maior de execução que é o VS Code junto com recursos de gerenciamento de tarefas e projeto
    • Não vejo o problema aqui. Tem algum?
      O próprio Linear também está trabalhando diretamente nessa direção
    • O Windsurf é open source?

  • O que não entendo nessas ferramentas é como elas lidam com a subida da infraestrutura para worktrees diferentes
    Por exemplo, se houver uma webapp, cada worktree precisa subir sua própria infraestrutura e ficar acessível por uma URL local exclusiva. Só assim dá para ver localmente as mudanças de cada worktree ou permitir que um agent-browser automatize a verificação visual
    No momento uso Docker para a infraestrutura, e cada serviço roda no seu próprio contêiner. Tenho um script ./app worktree create worktreename, que cria a worktree “worktreename” e depois sobe toda a infraestrutura Docker com um prefixo como “WORKTREENAME”. Assim, todas as URLs ficam acessíveis em worktreename.myapp.test, enquanto a worktree principal usa simplesmente myapp.test
    Está funcionando bem por enquanto, mas eu gostaria de migrar para um desses apps se algum deles fosse compatível com esse conceito

    • Tínhamos o mesmo problema no trabalho, então pedi ao CC para criar uma ferramenta CLI em bun bem simples para criar, remover e listar worktrees
      Essa CLI preenche um arquivo .env com a URL e o banco de dados daquela worktree e sobe um servidor de desenvolvimento numa porta exclusiva com o pacote open source portless, da Vercel. Assim cada worktree ganha sua própria URL
    • Vale a pena conferir o emdash.sh. Cada tarefa sobe sua própria worktree, com variáveis de ambiente predefinidas sendo injetadas
      Isso inclui EMDASH_PORT, uma porta exclusiva dentro de uma faixa de 10 portas. É muito útil ao rodar vários serviços dentro de um único monorepo
    • Eu uso scripts shell para criar e remover worktrees
      O script shell encontra uma porta exclusiva não utilizada entre todas as worktrees existentes e a atribui ao .env local quando a worktree é criada. Quando a worktree é mesclada e removida, a porta também é liberada
      Segredos que não são por worktree eu não coloco no .env local; injeto via shell
      Honestamente, escrever scripts locais assim para automatizar o trabalho de desenvolvimento foi bem simples, e se integra bem com todas as outras ferramentas CLI. Por isso ainda não experimentei apps com GUI. Não sei se conseguiriam competir com uma configuração local sob medida que já funciona exatamente do jeito que eu quero
    • Não seria só usar direnv? A porta da página local hospedada precisaria de algum ajuste, mas bastaria pegar um hash com base no nome da worktree, definir N=mod(...) e usar port=default_port+N
      É só pedir para o Claude configurar. Ele resolve com um único prompt

  • “'kanbots' está danificado e não pode ser aberto. Você deve movê-lo para a lixeira”
    Um erro apropriado demais para encontrar pela primeira vez em um software de vibe coding

  • Isso não é só o vibe-kanban?
    https://github.com/BloopAI/vibe-kanban

    • Pode existir concorrência
    • Está literalmente no Bloop. É original do Bloop