Une application de bureau open source de Kanban qui exécute des agents en parallèle sur toutes les cartes

 (kanbots.dev)
1 points par GN⁺ 8 시간 전 | 1 commentaires | Partager sur WhatsApp
  • KanBots est une application de bureau qui exécute Claude Code et Codex en parallèle pour chaque carte Kanban et affiche en temps réel la progression, les décisions et les coûts sur le tableau
  • Chaque exécution est isolée dans un git worktree distinct sur la branche kanbots/issue-N, et il est possible de créer un tableau en déposant un dossier puis d’assigner un agent à chaque carte
  • Autopilot fait tourner des personas comme produit, ingénieur, relecteur et testeur avec un parallélisme maximal de 4, répartit le travail et met à jour le backlog
  • Les agents s’arrêtent lorsqu’un jugement est nécessaire et proposent des options ; l’utilisateur peut continuer via un choix numéroté, une nouvelle soumission modifiée, /spec, /review ou /split
  • L’application de bureau adopte une approche local-first sous licence MIT gratuite, tandis que la version Cloud propose la synchronisation d’équipe, des notifications et des tableaux de bord pour 19 $/mois par siège

Concept de base de KanBots

  • KanBots est une application de bureau qui exécute en parallèle des agents Claude Code et Codex au niveau des cartes d’un tableau Kanban
  • Chaque agent s’exécute dans un git worktree distinct sur la branche kanbots/issue-N, et le tableau met à jour en temps réel l’avancement, les demandes de décision et les coûts
  • En ajoutant un dossier, un tableau est créé, et plusieurs cartes peuvent se voir attribuer un agent Claude Code ou Codex
  • En mode d’exécution automatique, des personas se répartissent le travail, l’exécutent en parallèle et vérifient les résultats
  • L’application de bureau est gratuite, sous licence MIT, financée par les dons et fonctionne selon une approche local-first

Composition du produit et tarification

  • Bureau OSS

    • Desktop suit une approche local-first, sans compte, sans télémétrie, gratuite à vie et sous licence MIT
    • Il prend en charge macOS, Linux et Windows, et inclut toutes les fonctionnalités
    • Parmi les fonctions principales figurent l’exécution parallèle d’agents, l’exécution automatique, les invites de décision, les personas intégrées et personnalisées, l’analyse des coûts en temps réel, une bibliothèque de recettes, kanbots-mcp-server, l’import Sentry, le mode GitHub Issues, l’aperçu des branches, la création de brouillons de PR, la prise en charge de Claude Code et Codex, ainsi que les hooks pre-push

  • Cloud pour les équipes

    • Cloud est un produit hébergé multi-utilisateur, tandis que les agents s’exécutent localement sur le matériel des utilisateurs
    • Le prix est de 19 $ par mois et par siège, ou 190 $ par an avec facturation annuelle
    • En plus des fonctions OSS, il fournit la présence en temps réel sur le tableau, les notifications d’assignation des membres d’équipe, la synchronisation entre appareils, les notifications Slack, l’agrégation des coûts à l’échelle de l’organisation, l’édition collaborative de cartes en temps réel, des tableaux de bord d’activité des agents par organisation et une Managed GitHub App
    • Les fonctions Enterprise incluent les journaux d’audit, SSO / SCIM, une API REST avec PAT, ainsi que des webhooks sortants
    • Les fonctions réservées au Cloud sont limitées à celles qui ont du sens lorsqu’il y a d’autres personnes ou d’autres appareils ; tout ce qui sert à une seule personne sur une seule machine est inclus dans l’OSS

Outils pris en charge et intégrations

  • Prend en charge les CLI Claude Code et Codex
  • Prend en charge les tâches GitHub Issues et PR
  • Prend en charge l’import des erreurs Sentry
  • Cursor et Claude Desktop peuvent être intégrés en tant que clients MCP
  • Le stockage local utilise SQLite
  • Le shell de bureau est fourni sur base d’Electron

Fonctionnalités clés

  • Exécution parallèle des cartes

    • Il est possible d’exécuter simultanément des agents sur plusieurs cartes, et chaque exécution se déroule dans son propre git worktree et sur sa propre branche kanbots/issue-N
    • Le tableau met à jour en temps réel la progression des exécutions, les demandes de décision des agents et l’accumulation des coûts

  • Exécution automatique et personas

    • Il est possible de chaîner des personas comme produit, ingénieur, relecteur et testeur, avec un parallélisme réglable jusqu’à 4
    • L’orchestrateur parcourt les personas en round-robin, découpe les sujets de haut niveau en sous-tâches et met à jour le backlog avec les tâches découvertes par les agents
    • Une persona peut en créer d’autres

  • Exécution centrée sur la décision

    • Les agents s’arrêtent lorsqu’ils rencontrent une décision nécessaire et affichent des options
    • L’utilisateur peut poursuivre via un choix numéroté, une resoumission après modification ou des commandes slash comme /spec, /review et /split
    • Au lieu de modifier silencieusement l’arbre de travail, le système laisse un flux de décisions vérifiable

  • Intégration de Claude Code et Codex

    • Claude Code ou Codex peuvent être utilisés sur le même tableau, dans le même worktree et avec la même interface de décision
    • KanBots gère les deux formats de flux derrière un unique AgentCliAdapter
    • Il est possible de réutiliser un claude /login existant ou OPENAI_API_KEY

  • Stockage local-first

    • Toutes les données se trouvent dans .kanbots/ à côté du dépôt
    • La base SQLite, la configuration et les worktrees sont stockés en local
    • Il n’y a ni compte cloud, ni télémétrie, ni serveur HTTP, et le code ne quitte pas la machine

  • Analyse des coûts et plafonds budgétaires

    • Fournit des agrégations de coûts par exécution, par carte et par projet
    • Un compteur de coûts s’accumule pendant le travail des agents
    • Il est possible de définir des limites par exécution et par session, et l’exécution s’arrête lorsque le budget est atteint

  • Workflow GitHub

    • Il est possible de traiter de vrais issues GitHub avec un PAT personnel
    • Les worktrees peuvent être promus en commits ou transformés en brouillons de PR en un clic
    • Des hooks pre-push empêchent les agents de publier par eux-mêmes

  • Serveur MCP

    • kanbots-mcp-server expose le tableau via le Model Context Protocol
    • Cursor, Claude Desktop ou tout outil compatible MCP peuvent manipuler le tableau
    • Le tableau devient ainsi un outil utilisable par d’autres agents

Workflow interne de l’application

  • Autopilot

    • On choisit une ou plusieurs personas, on définit le parallélisme, puis on lance l’exécution automatique
    • Jusqu’à 4 slots parallèles parcourent la liste des personas en round-robin
    • Chaque slot récupère atomiquement la persona suivante, et les agents découpent en cours d’exécution les sujets de haut niveau en sous-tâches
    • L’exécution s’arrête à la fin ou lorsque le budget de session est atteint
    • L’écran d’exemple montre Claude Opus 4.7, un effort medium, un parallélisme de 2, avec les personas Product Manager et Senior Engineer sélectionnées

  • Decisions

    • Le fil d’exécution diffuse en temps réel tous les tool_use et tool_result
    • L’agent interrompt l’exécution lorsqu’un jugement est nécessaire et présente des options numérotées
    • Le champ de réponse accepte des commandes comme /spec, /review et /split
    • Dans l’exemple d’implémentation de jeton de réinitialisation de mot de passe, des options comme JWT à usage unique, jeton opaque stocké en base, magic link ou explication préalable des compromis sont affichées
    • L’écran d’exécution affiche le modèle, le temps écoulé, le nombre de tokens, le coût, l’état, la priorité, le dossier, le worktree, la branche, la branche de base et l’auteur

  • Personas

    • Une persona est un fragment de prompt système nommé
    • Des personas par défaut sont incluses dans l’application, et l’utilisateur peut en écrire de nouvelles, les enregistrer et les réutiliser
    • Les personas personnalisées sont stockées localement sur la machine concernée
    • Les exemples par défaut incluent Product Manager, Senior Engineer, UX Designer, Growth Lead et Reliability Engineer

  • Providers

    • Claude Code et Codex peuvent être utilisés derrière un seul AgentCliAdapter
    • Un claude /login ou codex login existant peut être réutilisé, sans compte supplémentaire ni gestion de clé supplémentaire
    • Il est possible de changer de fournisseur à chaque exécution
    • La CLI Codex exige que codex soit présent dans le PATH, et la rédaction de brouillons d’issues ainsi que l’analyse Sentry restent exécutées via Claude
    • La connexion Codex peut ouvrir auth.openai.com dans le navigateur ou utiliser la variable d’environnement OPENAI_API_KEY

  • Tasks

    • Les nouvelles tâches proposent des modèles pour correction de bug, fonctionnalité, refactorisation, revue et spike
    • Le mode de démarrage permet de choisir entre spec-first, exécution immédiate après création ou mise en file pour plus tard
    • Le titre est utilisé comme nom de branche et comme titre de PR
    • spec-first exécute /spec, affine les critères d’acceptation et laisse la tâche en attente d’approbation
    • Une nouvelle tâche crée un fresh worktree et génère une branche sous .kanbots/worktrees/issue-N à partir de main

  • Chat

    • Un agent générique est fourni pour poser des questions sur le workspace
    • L’agent connaît le dépôt, les tests et l’état git, et répond aux questions
    • Un exemple montre comment trouver une route API sans rate limiting, ajouter rateLimit({ windowMs: 60_000, max: 10 }) à /api/login et /api/signup, puis écrire des tests qui passent

Fonctionnement d’Autopilot

  • Autopilot est un mode qui prend des issues et un budget pour mettre à jour le backlog de manière autonome
  • L’orchestrateur parcourt une liste de personas en round-robin et exécute jusqu’à 4 slots en parallèle
  • Il découpe les sujets de haut niveau en sous-tâches et boucle jusqu’à ce que le travail converge ou que la limite de coût soit atteinte
  • L’exemple affiche un parallélisme de 4, le modèle opus 4.7, un budget de session de 25,00 $ dont 4,27 $ utilisés, et l’état du 14e cycle

  • Sélection de la liste de personas

    • Il est possible d’utiliser les personas par défaut ou de définir, enregistrer et réutiliser ses propres prompts système
    • Les personas personnalisées ne quittent pas la machine

  • Réglage du parallélisme

    • Le parallélisme peut être réglé de 1 à 4
    • Chaque slot récupère atomiquement la persona suivante via un compteur round-robin
    • Quatre agents peuvent s’exécuter simultanément avec quatre perspectives et quatre worktrees

  • Découpage du travail

    • Lorsqu’un agent découvre une tâche, il crée une nouvelle carte sur le tableau
    • Les cycles suivants récupèrent ces nouvelles cartes, et le backlog grandit puis se réduit sous l’orchestrateur

  • Arrêt sur budget ou à l’achèvement

    • Un budget de coût par session limite la dépense totale
    • Le bouton d’arrêt termine l’exécution parente et toutes les exécutions enfants
    • Les exécutions en cours terminent proprement leur itération actuelle

Mode QA

  • Le mode QA exécute typecheck, tests, lint, build et e2e à l’intérieur du worktree
  • Il peut démarrer et surveiller un serveur de développement si nécessaire
  • Pour chaque vérification échouée, il assigne une exécution de correction dans un issue enfant dérivé
  • Il répète le processus jusqu’à ce que les vérifications passent

Distribution et conclusion

  • L’application de bureau OSS est fournie gratuitement, sous licence MIT et sans compte
  • Elle met l’accent sur un flux où toutes les exécutions d’agents sont visualisées sur un Kanban, rendues décisionnelles et isolées
  • Les équipes peuvent passer au Cloud lorsqu’elles doivent partager le tableau
  • Les formats de téléchargement sont macOS .dmg, Windows .exe, Linux .AppImage / .tar.xz

À lire aussi

1 commentaires

 
GN⁺ 8 시간 전
Commentaires sur Hacker News

  • Je me demande toujours comment les gens accueillent les résultats produits pendant la nuit par des agents
    Même sur un dépôt de projet perso, j’ai l’impression qu’un résultat issu de 30 minutes de planification et 30 minutes d’implémentation est déjà trop gros à relire. Au bout d’environ 5 minutes, il m’arrive de demander à l’IA de recommencer alors même que le code continue d’affluer

    • Le récit dominant en ce moment insiste sur l’idée que l’IA écrit tout ou la majeure partie du code, mais en pratique, j’ai l’impression que la part de code réellement relue par un humain se rapproche de zéro bien plus vite que les gens ne le réalisent ou ne veulent l’admettre
    • Une grande partie de cette activité d’agent consiste à parcourir ce qui a déjà été fait et à imposer des contraintes pour rendre le résultat qu’on retrouvera sur le bureau au moment de la relecture un peu plus prévisible
      À mon avis, une structure de fichiers solide aide aussi. Relire un fichier de 3 000 lignes qui vient d’être généré, c’est l’enfer, et je n’accepterais pas ce genre de sortie d’un humain pas plus que d’une machine. Si c’est réparti en plusieurs fichiers au bon endroit, la charge cognitive baisse
      Parfois, je fais aussi la revue en discutant avec l’agent. Par exemple, je lui demande quels sont les fichiers les plus importants à relire en premier
      J’aime bien mettre les changements en staging dans une pile « LGTM ». Si des corrections sont nécessaires ensuite, je dis à l’agent : « relis les changements non indexés. J’aurais préféré une autre approche ici »
    • Personne ne relit le code. Et les managers ne veulent pas non plus qu’on le relise. C’est un goulot d’étranglement
      Si quelque chose ne va pas, autrement dit s’il y a un bug, on le corrige au fil de l’eau. C’est une époque très triste pour l’ingénierie logicielle. S’il y a un jour eu de l’ingénierie dans notre industrie, il n’en reste plus grand-chose aujourd’hui, et on se contente de bricoler avec des fichiers de skills du genre « n’introduis pas de bugs » ou « tu n’es pas locataire, tu es propriétaire »
      Le niveau d’effort est faible et le déterminisme l’est aussi. De grosses apps comme GitHub se dégradent à cause des déchets générés par l’IA, et c’est encore plus fréquent sur des systèmes moins connus. Même chose dans notre boîte ou dans d’autres SaaS qu’on utilise
      Les product managers ne se sont jamais vraiment souciés du code, les engineering managers s’en soucient moins qu’à l’époque où ils étaient ingénieurs. Les directeurs ne s’en préoccupent pas du tout, et les CTO ne savent même plus à quoi ressemble le code aujourd’hui
      Nous sommes au bout de la chaîne, et comme nous savions intimement que les bons systèmes reposent sur du bon code, nous étions fiers d’écrire du code utile et maintenable. Mais aujourd’hui, nous nous mettons nous-mêmes en danger, et ceux qui ne se soucient plus du code, ce sont justement nous, les ingénieurs, l’IA ne faisant qu’amplifier ce problème
    • En général, quand Claude a travaillé toute la nuit, j’essaie qu’il ne reste au final qu’environ 500 lignes de code
      L’essentiel du temps sert à tester différentes approches puis à les résumer, pour me livrer un diff relativement réduit que je peux relire et corriger
    • Je me pose la même question. En pratique, la réponse qu’on entend le plus souvent de la part de ceux qui semblent bien utiliser ces outils, c’est qu’ils ne regardent pas le code, ou du moins pas en détail
      Personnellement, je finis toujours par retoucher d’une manière ou d’une autre ce que produit l’agent. Je me demande s’il faut que j’abandonne ce besoin de contrôle

  • Ça me fait surtout penser à Vibe Kanban(https://vibekanban.com/), que j’utilise pour gérer les agents de code sur la plupart de mes projets
    Malheureusement, les développeurs de Vibe Kanban ont estimé qu’ils ne voyaient pas de voie de monétisation et ont arrêté d’investir dans le projet. Comme c’est open source, on peut toujours l’exécuter en local ou le forker, mais les améliorations se sont arrêtées et il reste encore quelques bugs pénibles à corriger. Je n’ai pas le temps de le maintenir moi-même
    J’aurais volontiers payé pour Vibe Kanban, ce qui rend ça d’autant plus dommage. Cela dit, je n’avais pas besoin des fonctions du forfait payant. Avec le recul, j’aurais peut-être dû payer quand même
    Je vais aussi essayer Kanbots. Il pourrait sans doute reprendre très librement les fonctionnalités de Vibe Kanban. En particulier, la prise en charge du distant et le bouton « Open in VS Code » sont essentiels pour moi. Dans mon cas, ce bouton ouvre un client VSCode local pointant vers un serveur VSCode distant

    • Vibe Kanban est une vraie mine d’or côté fonctionnalités utiles
      Depuis une à deux semaines, je travaille à amener ce nouvel outil au niveau de parité fonctionnelle avec VK, puis à l’améliorer davantage. J’ai aussi posté quelques captures d’écran sur le Discord de Vibe Kanban. J’espère que, quand tout sera prêt pour la sortie, il correspondra aussi bien à votre cas d’usage
      Mon outil vise à faire mieux que VK à la fois sur le tableau Kanban et sur l’espace de travail des agents, avec en plus des systèmes comme la gestion des fenêtres du bureau, des plugins, une intégration de VSCode dans le navigateur, et une UI rendue côté serveur à la manière de htmx
      L’approche d’accès distant est aussi différente. Au lieu de lancer un serveur web sur un laptop pour accéder à un agent de code distant, j’héberge l’ensemble comme OpenClaw et j’accède à une UI de bureau distant depuis le navigateur

  • Le fait que ce soit « local first, sans serveur. Tout est dans .kanbots/ à côté du dépôt : base de données SQLite, configuration, worktrees. Aucun compte cloud, aucune télémétrie, aucun serveur HTTP. Ceci est l’édition desktop open source » est une condition de base pour envisager l’adoption d’un outil de ce type

    • Je ne vois pas bien ce que recouvre « ce type d’outil »
      Si l’IA est agentique, je m’attends à ce que n’importe quel product manager puisse discuter une heure avec elle et intégrer Jira à une boucle d’agent
      Jira, Trello, Linear et Basecamp ont tous des API, et il doit sûrement exister des CLI utilisables par des agents. Il ne devrait pas falloir de développeur ni de SaaS pour lui faire comprendre qu’au début du travail, le ticket doit être checkout avec ses instructions, puis déplacé en DONE à la fin
    • La page dit que même en local, la fonctionnalité nécessite une connexion à un compte cloud, donc j’ai décidé de ne pas essayer
      Franchement, ça a l’air cool. Mais il y a déjà pas mal d’outils qui ont l’air cool

  • À l’origine, le mot « Kanban » était utilisé par Toyota pour décrire un système de cartes qui remplissait quelques objectifs essentiels, notamment éviter d’avoir trop de travail en cours en même temps et visualiser le travail
    Plus globalement, Kanban servait à gérer le flux de travail pour éviter que les défauts ne passent à travers
    Or cet outil ressemble plutôt à « injecter tout le travail imaginable pour en générer un maximum en parallèle ». Il ne gère pas le flux de livrables de qualité, ne limite pas le travail en cours, il balance simplement tout aux agents et brûle des tokens comme un fou
    Le fait d’appeler ça « Kanban » m’agace vraiment. J’y vois presque un blasphème

  • Chaque fois que j’ai essayé de faire tourner des agents sans supervision, j’ai eu plus de frustrations que de réussites
    Je crois que la technologie finira par y arriver, mais pour l’instant chaque agent a besoin de son propre IDE et fusionner le travail reste pénible

  • Je partage ici un projet open source récent. C’est un tableau Kanban avec des agents parallèles
    J’essaie encore de l’améliorer avec davantage de fonctionnalités, et toute contribution au dépôt, que ce soit du code ou des idées, est la bienvenue

    • Beau travail. J’ai déjà essayé de faire tourner mon propre Kanban avec des agents maison en classant un projet Jira existant par workflow, donc ça me fait plaisir de voir ce projet aujourd’hui sur HN
      Ce sera intéressant de suivre son évolution
    • Vous devriez jeter un œil à l’article sur les minions du blog développeur de Stripe. La direction semble assez proche

  • En gros, ce n’est pas déjà ce que fait Windsurf ? Au final, toutes ces UI ne sont qu’un habillage posé par-dessus des agents
    [0] https://windsurf.com/blog/windsurf-2-0

    • Il existe quelques apps qui aident à déléguer aux agents depuis un tableau Kanban
      Moi, j’avais besoin d’un flux avec davantage d’intervention humaine. Une approche où l’on délègue à l’agent sans bien voir l’ensemble des changements ni avoir l’occasion de réorienter ne me convient pas
      https://www.agentkanban.io relie via une extension le tableau de tâches à GitHub Copilot Chat dans VS Code, afin d’avoir à la fois la gestion des tâches et la capture de contexte du passage du chat au travail. On bénéficie ainsi des atouts de VS Code comme environnement d’exécution supérieur tout en gardant des fonctions de gestion des tâches et de projet
    • Je ne vois pas le problème ici. Y en a-t-il un ?
      Linear travaille aussi directement dans cette direction
    • Windsurf est open source ?

  • Ce que je ne comprends pas avec ce genre d’outils, c’est comment ils gèrent le démarrage de l’infrastructure entre différentes worktrees
    Par exemple, si on a une webapp, chaque worktree doit pouvoir lancer sa propre infra et être accessible via sa propre URL locale unique. Comme ça, on peut visualiser localement les changements de chaque worktree, ou permettre à un agent, via quelque chose comme agent-browser, d’automatiser la vérification visuelle
    Aujourd’hui, j’utilise Docker pour l’infra et chaque service tourne dans son propre conteneur. J’ai un script ./app worktree create worktreename qui crée la worktree « worktreename », puis démarre toute l’infrastructure Docker avec des préfixes du type « WORKTREENAME ». Ainsi, toutes les URL sont accessibles via worktreename.myapp.test, tandis que la worktree principale utilise simplement myapp.test
    Ça fonctionne bien pour l’instant, mais si l’une de ces apps pouvait s’intégrer à ce concept, je serais content de migrer dessus

    • On avait le même problème au travail, donc j’ai demandé à CC de me faire un outil CLI en bun très simple pour créer, supprimer et lister les worktrees
      Ce CLI renseigne dans le fichier .env l’URL et la base de données correspondantes à la worktree, puis lance un serveur de développement sur un port unique avec le paquet open source portless de Vercel. On obtient ainsi une URL par worktree
    • Vous devriez regarder emdash.sh. Chaque tâche lance sa propre worktree et des variables d’environnement prédéfinies sont injectées
      Parmi elles, il y a EMDASH_PORT, un port unique dans une plage de 10 ports. C’est très utile quand on exécute plusieurs services dans un seul monorepo
    • J’utilise des scripts shell pour créer et supprimer les worktrees
      Le script shell trouve un port libre unique parmi toutes les worktrees existantes et l’assigne au .env local lors de la création de la worktree. Quand la worktree est fusionnée puis supprimée, le port est libéré
      Les secrets qui ne sont pas propres à une worktree ne sont pas stockés dans le .env local, ils sont injectés via le shell
      Honnêtement, écrire ce genre de scripts locaux pour automatiser le travail de développement a été très simple, et ça s’intègre bien avec tous mes autres outils CLI. Du coup, je n’ai toujours pas essayé d’app GUI. Je ne sais pas si elles pourraient rivaliser avec une configuration locale sur mesure qui fonctionne exactement comme je le veux
    • Pourquoi ne pas simplement utiliser direnv ? Il faudrait ajuster le port qui héberge la page locale, mais il suffirait de prendre N=mod(...) à partir d’un hash du nom de la worktree, puis port=default_port+N
      Il suffit de demander à Claude de configurer ça. Il le fera en un seul prompt

  • « ‘kanbots’ est endommagé et ne peut pas être ouvert. Vous devriez le déplacer vers la corbeille »
    C’est une erreur trop appropriée pour une première rencontre avec un logiciel de vibe coding

  • Ce n’est pas tout simplement vibe-kanban ?
    https://github.com/BloopAI/vibe-kanban

    • Des concurrents peuvent exister
    • C’est littéralement sur le GitHub de Bloop. C’est l’original de Bloop