Vibe Kanban: ein Kanban-Board zum parallelen Steuern von Code-Agenten

Ein Kanban-Board, mit dem Aufgaben über Code-Agenten (Claude Code, Codex, Gemini CLI, Copilot und andere) geplant, ausgeführt und überprüft werden — und das nach der Schließung des Unternehmens bloop in offene, von der Community gepflegte Wartung übergeht. Am 1. September 2026 stand es bei 27.979 Sternen.

Was Vibe Kanban ist

Vibe Kanban ist eine Desktop-Anwendung (mit Web-Komponente und selbst hostbarer Option), deren im README erklärtes Ziel es ist, „das 10-Fache aus Claude Code, Codex oder jedem Code-Agenten herauszuholen”. Es ist kein Agent selbst, sondern ein Orchestrator. Der Ingenieur erstellt Aufgaben (Issues) auf einem Kanban-Board, und wenn er eine ausführen möchte, erstellt er einen Arbeitsbereich (Workspace), in dem ein Agent einen Git-Branch (ein Worktree), ein Terminal und einen Entwicklungsserver erhält. Der Nutzer kann den Diff live verfolgen, Inline-Kommentare hinterlassen, die an den Agenten zurückgehen, die App in einem eingebetteten Browser vorschauen und den Pull Request (PR) direkt aus der Oberfläche öffnen.

Der Ausgangspunkt des Teams, den einer der Gründer in der Hacker-News-Ankündigung erläuterte, war das Gefühl, „nutzlos” zu sein, während man 2 bis 5 Minuten darauf wartet, dass ein Agent eine Aufgabe abschließt. Der Vorschlag bestand darin, Agenten im Hintergrund zu parallelisieren und diese Zeit für Planung und Überprüfung zu nutzen — laut ihrer These die Tätigkeiten, die zunehmend mehr Zeit von Ingenieuren beanspruchen.

Das Produkt wird mit einem Rust-Backend und einem Node.js-Frontend gebaut (Voraussetzung Node ≥ 20, pnpm ≥ 8), als Desktop-Anwendung über Tauri verpackt, mit einem eigenen MCP-Server und Self-Hosting-Fähigkeit über Docker.

Hinweis zur Abgrenzung: das Repository BloopAI/vibe-kanban sollte nicht mit BloopAI/bloop derselben Organisation verwechselt werden, einer schnellen Code-Suchmaschine in Rust und einem früheren, eigenständigen Produkt des Unternehmens. Dieser Bericht dokumentiert ausschließlich vibe-kanban.

Ursprung

Das Repository wurde am 14. Juni 2025 unter der Organisation BloopAI erstellt. Das dahinterstehende Unternehmen ist bloop (Bloop AI Limited), gegründet unter anderem von Louis Knight-Webb (louiskw) und Gabriel Gordon Hall (ggordonhall). Laut der am 10. April 2026 veröffentlichten Schließungsankündigung „startete das Team im Juni 2025”.

Die sichtbarste öffentliche Ankündigung war der Show HN vom 11. Juli 2025 (Thread 44533004, 195 Punkte, 132 Kommentare), in dem Louis Knight-Webb das Projekt vorstellte und die Motivation beschrieb: die Wartezeit von 2-5 Minuten pro Aufgabe führte zu Ablenkung, und er wollte einen Weg finden, Agenten zu parallelisieren und diese Zeit produktiv zu nutzen.

Geschichte und Zeitleiste: eine Neon-Chronologie von der Erstellung des Repositorys im Juni 2025 über den öffentlichen Launch, die massenhafte Adoption, die Schließungsankündigung im April 2026 bis zum Übergang in eine von der Community gepflegte Zukunft

Die für heutige Nutzer wichtigste narrative Tatsache ist das Ende: am 10. April 2026 kündigte bloop die Schließung des Unternehmens an. Die Mitteilung (unterzeichnet von Louis, Gabriel und dem bloop-Team) erklärt, dass zwar „Tausende Software-Ingenieure Vibe Kanban jeden Tag nutzen”, die überwiegende Mehrheit jedoch Nutzer der kostenlosen Version war, und „wir konnten kein Geschäftsmodell finden, das uns begeistert hätte”. Als Konsequenz läuft das Vibe-Kanban-Projekt als Open Source weiter und wird von der Community gepflegt, und das Unternehmen versprach, in den folgenden Wochen eine Roadmap für die Community-Edition zu veröffentlichen. Die Remote-Funktionen (Issues, Kommentare, Projekte und Cloud-Organisationen) blieben 30 Tage nach der Ankündigung verfügbar, bevor sie zu einer vollständig lokalen Architektur übergingen; Rechnungen der vorangegangenen 30 Tage wurden erstattet und Abonnements gekündigt. Die letzte Version enthält eine Datenexportfunktion.

Übergang von Unternehmen zu Community: links eine Unternehmensstruktur, die in einem Sonnenuntergangsverlauf verblasst; rechts ein lebendiges Community-Netzwerk mit GitHub-Repositories, Diskussions-Threads, Mitwirkenden und lokalen Docker-Containern, mit einem zentralen Kanban-Board, das intakt bleibt

Dieser Kontext prägt alles Weitere: das Projekt hat reale Zugkraft (fast 28.000 Sterne), aber seine institutionelle Wartung ist eingestellt, sodass seine Zukunft von der Community abhängt.

Philosophie und Prinzipien

Überprüfbare Ideen, die sich durch README, Dokumente und Ankündigung ziehen:

Der Engpass ist nicht mehr das Schreiben von Code, sondern Planung und Überprüfung. Das README eröffnet: „In einer Welt, in der Ingenieure den Großteil ihrer Zeit mit der Planung und Überprüfung von Code-Agenten verbringen, besteht der wirkungsvollste Weg, mehr zu liefern, darin, beim Planen und Überprüfen schneller zu werden”.
Agenten-Parallelismus als Arbeitseinheit. Der zentrale Wert besteht darin, mehrere Agenten gleichzeitig in isolierten Räumen zu starten (jeder mit eigenem Branch, Terminal und Server), damit der Mensch im Stapel überprüft, statt sequenziell zu warten.
Überprüfung ist die Oberfläche, nicht der Chat. Das Produkt stellt den Diff, Inline-Kommentare und die Vorschau in den Mittelpunkt, mit der Prämisse, dass der menschliche Ingenieur die Qualität sichert.
Agentenneutralität. Es erzwingt keinen einzigen Agenten: es unterstützt und wechselt zwischen mehr als zehn, was es zu einer Abstraktionsschicht über die bestehenden CLIs jedes Anbieters macht.

Planen und Überprüfen als Engpass: ein Ingenieur, umgeben von holografischen Panels mit Aufgabenkarten, Code-Diffs, Prüflisten und Inline-Kommentaren, mit einem Kanban-Board links und Agenten, die parallel in Glascontainern rechts arbeiten

In der Community-Rezeption gibt es eine ausdrückliche Spannung (siehe „Wie die Community reagierte”): mehrere Nutzer stellten infrage, ob die Prämisse, dass „Ingenieure den Großteil ihrer Zeit mit Planen und Überprüfen verbringen”, heute noch zutrifft, und andere kritisierten den Umfang der GitHub-Authentifizierungsberechtigungen, die die Erstversion anforderte.

Wie es funktioniert

Der in der Get-Started-Anleitung dokumentierte Ablauf hat diese Phasen:

Starten mit npx vibe-kanban, das die UI im Browser öffnet.
Erste Präferenzen: Code-Agent, IDE und Benachrichtigungen wählen.
Anmeldung mit GitHub oder Google (kann übersprungen werden, dann gibt es aber kein Board, keine Issues und keine Teamfunktionen; lokale Workspaces lassen sich trotzdem erstellen).
Kanban-Board: Issues erstellen und priorisieren (Titel, Beschreibung, Priorität, Labels und Eltern-Kind-Beziehungen).
Einen Workspace erstellen: bei der Auswahl erstellt Vibe Kanban Git-Worktrees für die gewählten Repositories (auf den angegebenen Branches), startet den Agenten mit dem Prompt und der Konfiguration (Modell, Aufwandsstufe, Planmodus). Mehrere Workspaces können mit demselben Issue verbunden werden, um Agenten parallel laufen zu lassen, oder Workspaces ohne Issue für schnelle Abfragen.
Überprüfen: Änderungen ansehen, die App im integrierten Browser vorschauen (mit Devtools, Inspektionsmodus und Geräteemulation), inline kommentieren.
Zusammenführen: einen GitHub-PR mit KI-generierter Beschreibung öffnen oder den Branch lokal mergen.

Isolierte Arbeitsbereiche als Git-Worktrees: ein zentrales Repository, das sich in mehrere Neon-Kammern verzweigt, jede mit Terminal, Dateibaum, lokalem Entwicklungsserver und Vorschaubereich, beschriftet mit unterschiedlichen Branch-Namen

Wichtige technische Funktionen laut README und Dokumentation:

Über 10 austauschbare Agenten: Claude Code, OpenAI Codex, Gemini CLI, GitHub Copilot, Amp, Cursor Agent CLI, OpenCode, Factory Droid, CCR (Claude Code Router) und Qwen Code.
Eigener MCP-Server: über den Tab „MCP Servers” kann der MCP von Vibe Kanban hinzugefügt werden, damit ein Agent Tickets auf dem Board erstellt (zum Beispiel „plane eine Migration von AWS zu Azure und erstelle ein Ticket pro Schritt”).
Versionskontroll-Integrationen: GitHub und Azure Repos.
VSCode-Erweiterung (auch Cursor und Windsurf) und Remote-SSH-Konfiguration, um entfernte Projekte im lokalen Editor zu öffnen.
Self-Hosting der „Vibe Kanban Cloud”-Instanz über Docker Compose.

Agentenneutralität: ein zentrales Orchestrierungsmodul mit austauschbaren, eingesteckten Neon-Steckern, von denen jeder einen anderen Code-Agenten repräsentiert, vereint durch dieselbe Steueroberfläche

Überprüfungsansicht: ein Diff-Betrachter mit neonfarbig hervorgehobenen Zeilen, Inline-Kommentare, die an den Agenten zurückgesendet werden, ein integrierter Browser mit Geräteemulation und Devtools sowie ein Merge-Panel mit Schaltflächen zum Öffnen eines PR oder lokalen Mergen.

Die Überprüfungserfahrung: ein Code-Diff-Betrachter mit hervorgehobenen geänderten, hinzugefügten und gelöschten Zeilen, Inline-Kommentarblasen, ein integrierter Browser mit Inspektionsmodus und ein Merge-Panel mit Optionen zum Öffnen eines PR oder lokalen Mergen

Das Ökosystem

Repositories der Organisation BloopAI

Über vibe-kanban hinaus enthält die Organisation verwandte Repositories (Sternzahlen aus der zum Zeitpunkt dieser Recherche abgefragten GitHub-API):

BloopAI/dev-manager-mcp: ein MCP-Server, um „mehrere Entwicklungsserver parallel zu starten”; 140 Sterne.
BloopAI/vibe-kanban-web-companion: „Websites in Vibe Kanban bearbeiten”; 44 Sterne.
BloopAI/debugger-mcp: ein MCP-Server für interaktives Debugging; 30 Sterne.
BloopAI/experiments: Vorhersagen, Ausführungsprotokolle, Trajektorien und Inferenz-/Evaluierungsergebnisse auf der SWE-Bench-Aufgabe; keine registrierten Sterne.
BloopAI/bloop: eine schnelle Code-Suchmaschine in Rust (ein früheres und eigenständiges Produkt gegenüber Vibe Kanban); 9.497 Sterne. Wird erwähnt, weil ein Nutzer im Launch-Thread (skeptrune) schrieb: „ich erinnere mich an die ursprüngliche Bloop-Suchmaschine”, was bestätigt, dass sie der Vorläufer des Unternehmens ist.

Alternativen, Forks und Community-Erweiterungen

Eine GitHub-Repository-Suche (Abfrage vibe-kanban, nach Sternen sortiert, insgesamt 314 Ergebnisse) lieferte mehrere abgeleitete Projekte oder Konkurrenten, die Vibe Kanban direkt zitieren. Unter den sichtbarsten:

knowsuchagency/fulcrum: „Was, wenn Openclaw, Vibe Kanban, Vibetunnel und Dokploy ein Baby bekämen?”; 90 Sterne.
automagik-dev/forge: „Die Vibe-Coding++™-Plattform — orchestriert mehrere KI-Agenten, experimentiert mit isolierten Versuchen, liefert Code, den man versteht. Multi-Agent-Kanban mit MCP-Integration”; 89 Sterne.
ariaghora/korlap: „ein Kanban-Board zum Vibes-Machen”; 75 Sterne.
halilbarim/vibe-stack: „Docker-Setup für KI-Coding mit Vibe-Kanban + Claude Code; sichere Secrets, browserbasiertes VS Code, deployment-fertig”; 47 Sterne.
GarrickZ2/grove: „Kanban-artiges TUI für paralleles KI-Coding. Verwaltet Git-Worktrees als Aufgaben und führt mehrere Agenten in isolierten tmux-Sitzungen aus”; 46 Sterne.
qwenode/vibe-kanban-promax: „verfeinerter Fork von vibe-kanban mit besserer UI, Usability-Korrekturen, reinem Lokalmodus und ohne Anmeldeerfordernis”; 13 Sterne.
p-wegner/agentic-kanban: „eine Cleanroom-Reimplementierung von vibe-kanban”; 4 Sterne.
yigitkonur/mcp-better-vibe-kanban: ein MCP-Server zur Verwaltung von Vibe-Kanban-Aufgaben und -Sitzungen aus dem KI-Editor; 5 Sterne.
oculairmedia/vibesync: bidirektionale Synchronisierung zwischen Huly und Vibe Kanban über MCP; 3 Sterne.
mac-tron/kando: „Denken. Planen. Handeln. In Obsidian denken und planen, in Vibe Kanban ausführen”; 3 Sterne.

MCP-Ökosystem, Werkzeuge und Community-Erweiterungen: ein zentraler Knoten „Vibe Kanban MCP", verbunden mit einem Kanban-Board, mehreren Entwicklungsservern, einem Debugger, VSCode-, Cursor- und Windsurf-Erweiterungen, Docker-, GitHub- und Azure-Repos-Integration, umkreist von Community-Projekten wie Forks, Reimplementierungen und TUIs

Mehrere dieser Projekte erschienen auch als Antworten im Hacker-News-Thread oder in eigenen Threads (siehe Rezeptionsabschnitt): ericblue/claude-vibekanban (PRD-orientierter Ablauf), flashlan/vibe-kanban-alternative (Kanban mit persistentem mem0-Gedächtnis), ferrislucas/Circus-Chief (Agenten vom Mobiltelefon aus), battysh/batty (ein tmux-Agententeam mit testgesteuerter Kontrolle) und silo-rs/silo (jeder Branch mit eigenem localhost).

Diese Zahlen stammen aus der während dieser Recherche durchgeführten GitHub-Suche und sind keine Qualitäts-, Support- oder Kompatibilitätsprüfung jedes einzelnen Ablegers.

Offizieller und halboffizieller Status

Vibe Kanban besitzt keinen „offiziellen Status” im Sinne eines Plugin-Marktplatzes: es ist eine eigenständige Anwendung, kein Paket, das andere verteilen. Der relevante Status hat zwei Teile:

Selbst beanspruchter Vorrang (laut der Schließungsankündigung des Teams): bloop erklärt, „das erste gewesen zu sein, das Multi-Agenten-Unterstützung, Diff-Kommentare, Live-Vorschau, Klick-Bearbeitung, Fernzugriff und viele andere Funktionen anbot, die heute selbstverständlich erscheinen”. Das sind Behauptungen des eigenen Teams, keine Zertifizierung einer externen Stelle.
De facto, und jetzt im Übergang: durch seine Adoption („Tausende Ingenieure nutzen es jeden Tag”, laut bloop) wurde es zu einer praktischen Referenz für die parallele Orchestrierung von Agenten. Mit der Schließung des Unternehmens (April 2026) wird es von der Community gepflegt: das aktuelle README trägt den Hinweis „Vibe Kanban is sunsetting” mit Link zur Ankündigung, die letzte offizielle Veröffentlichung (v0.1.44) stammt vom 24. April 2026, und die Remote-Dienste werden zugunsten einer lokalen Architektur eingestellt.

In der Praxis bedeutet das: die lokale App funktioniert weiter, aber Cloud-Funktionen (geteilte Issues, Teams, Organisationen) werden mittelfristig obsolet, und der Support-Kanal wechselt vom Unternehmen zu GitHub Discussions und einem Community-Discord.

Schnellstart-Anleitung

Installation und erster Start

Voraussetzung: den gewünschten Code-Agenten zuvor authentifiziert zu haben (die vollständige Liste und Anweisungen für jeden befinden sich in der Dokumentation). Danach:

npx vibe-kanban

Beim ersten Start fragt die Anwendung nach dem bevorzugten Code-Agenten, der IDE und den Benachrichtigungspräferenzen (später im Einstellungsdialog änderbar). Anschließend bietet sie die Anmeldung mit GitHub oder Google an; wird das übersprungen („More options” → „I understand, continue without signing in”), lassen sich lokale Workspaces erstellen, aber nicht das Board, die Issues oder die Teamfunktionen. Mit Sitzung werden automatisch eine persönliche Organisation und ein Startprojekt erstellt.

Kontextwarnung: angesichts der Schließung von bloop befinden sich Anmeldung und Cloud-Funktionen in einem Übergangszustand. Für dauerhafte Nutzung lohnt es sich, einen Datenexport zu planen (in der letzten Version verfügbar) und den lokalen Modus oder eine Community-Alternative in Betracht zu ziehen (siehe „Das Ökosystem”).

Typische Arbeitsabläufe

Eine Aufgabe planen und ausführen: ein Issue auf dem Board erstellen → auswählen → „Create workspace”, Repository, Basis-Branch, Agent und Konfiguration (Modell, Aufwand, Planmodus) wählen → der Agent startet mit dem Prompt → den Diff überprüfen und mit „open GitHub PR” oder lokalem Merge zusammenführen.
Parallel ausführen: mehrere Workspaces mit demselben Issue verbinden (einer pro Agent/Branch), um ein großes Feature gleichzeitig zu bearbeiten; nach Abschluss jeden Diff separat überprüfen.
Feedback geben, ohne die UI zu verlassen: in der Workspace-Ansicht das Änderungspanel öffnen, inline zum Diff kommentieren und den Kommentar an den Agenten senden, damit er vor dem Mergen iteriert.
Den Agenten planen lassen: den MCP-Server von Vibe Kanban hinzufügen (Tab „MCP Servers” → „Add Vibe Kanban MCP”) und den Agenten bitten, eine große Aufgabe in Tickets zu zerlegen (zum Beispiel „plane eine Migration von AWS zu Azure und erstelle ein Ticket pro Schritt”).

Wesentliche Konfiguration

Die Einstellungen, die ein neuer Nutzer zuerst anfasst, laut Dokumentation und README:

Standardagent / Agentenprofile (Settings → Agent Profiles & Configuration): wiederverwendbare Konfigurationen mit Planmodus, Modell und Berechtigungsstufe, die beim Erstellen von Aufgabenversuchen angewendet werden.
Editor-Integration (Settings → General / Editor Integration): eine IDE wählen (VSCode, Cursor, Windsurf) und, für Remote-Deployments, den Remote SSH Host und Nutzer, sodass die Schaltflächen „Open in VSCode” vscode://vscode-remote/ssh-remote+user@host/path erzeugen.
Umgebungsvariablen des Backends (README): PORT, HOST (standardmäßig 127.0.0.1), MCP_PORT und, hinter einem Reverse Proxy oder eigener Domain, VK_ALLOWED_ORIGINS (siehe Stolperfallen).
Setup-/Cleanup-Skripte pro Repository (Settings → Projects & Repositories): automatisieren Abhängigkeitsinstallation, Builds und Abbau, damit jeder Workspace sauber startet.
MCP-Server (Settings → Connecting MCP Servers): Server hinzufügen, um das Werkzeugset der Agenten innerhalb von Vibe Kanban zu erweitern.

Häufige Stolperfallen und Lösungen

403-„Forbidden”-Fehler beim Self-Hosting mit eigener Domain oder Reverse Proxy (nginx, Caddy, Traefik): der Origin des Browsers stimmt nicht mit dem vom Backend erwarteten Host überein. Dokumentierte Lösung: VK_ALLOWED_ORIGINS auf den Origin (oder kommagetrennte Origins) setzen, unter dem das Frontend erreichbar ist, z. B. VK_ALLOWED_ORIGINS=https://vk.example.com.
Zu weitreichende GitHub-Berechtigungen: im Launch-Thread beanstandeten mehrere Nutzer (csomar, doritosfan84), dass die App unbegrenzten Zugriff auf private Repos anforderte. Das Team antwortete, das sei nötig, um PRs zu öffnen und CI-Ergebnisse zu lesen; die von den Nutzern selbst abgeleitete praktische Empfehlung ist die Nutzung einer GitHub App (granulare Berechtigungen) statt einer OAuth App. Angesichts der Schließung lohnt es sich, den Umfang der gewährten Zugriffe zu minimieren.
Verlangsamung des Rechners bei mehreren Agenten: Louis Knight-Webb räumte im Thread ein, dass „das MacBook nach 4 gleichzeitigen Läufen langsam wird, vor allem wegen rustc”. Workspaces zu isolieren und die Anzahl gleichzeitiger Agenten zu begrenzen ist die naheliegende Abhilfe.
MCP unter Windows mit HOST=0.0.0.0: das README weist an, explizit MCP_HOST=127.0.0.1 zu verwenden, wenn HOST=0.0.0.0 gesetzt ist, damit sich der MCP-Server korrekt verbindet.
Prozessverluste/-zustand (in Releases dokumentiert): in aktuellen Versionen wurden Probleme wie ein „Konversationsverlauf-Leck” (eine Zustand-zu-React-Context-Regression) und das Einsammeln von Ausführungs-Prozessgruppen beim Beenden behoben; ein Update auf die neueste Version reduziert diese.

Integrationen und Migration

MCP: Vibe Kanban stellt MCP sowohl bereit als auch konsumiert es — sowohl um Drittanbieter-Server zu Agenten hinzuzufügen, als auch damit ein Agent über den eigenen MCP von Vibe Kanban Tickets erstellt.
Versionskontrolle: GitHub (PRs, CI) und Azure Repos; Integration mit der VSCode/Cursor/Windsurf-Erweiterung.
Self-Hosting: Docker Compose, um die „Cloud”-Instanz auf jedem Server bereitzustellen; Tunnel (Cloudflare Tunnel, ngrok) oder der Relay-Tunnel-Modus (VK_TUNNEL) für Fernzugriff.
Migration / Ausstieg: angesichts des Sunsets enthält die letzte Version einen Datenexport. Um eigenständig weiterzumachen, sind die verifizierbaren Wege der von bloop angekündigte vollständig lokale Modus oder Community-Alternativen mit ausdrücklicher lokaler, anmeldungsfreier Absicht (zum Beispiel der Fork qwenode/vibe-kanban-promax, „local-only mode, and no login required”, und Cleanroom-Reimplementierungen wie p-wegner/agentic-kanban).

Aktuelle Kennzahlen

Messung: 1. September 2026, öffentliche APIs/Register von GitHub und npm.

Kennzahl	Wert
Sterne	27.979
Forks	2.998
Abonnenten (echte Watcher)	119
Von der API angegebene offene Issues	533
Hauptsprache	Rust
Lizenz	Apache License 2.0
Erstellung	14. Juni 2025
Letzter Push	24. April 2026
Letzte Veröffentlichung	`v0.1.44`, 24. April 2026
npm-Downloads (letzte Woche)	2.091 (2026-08-23 → 2026-08-29)
npm-Downloads (letzter Monat)	7.386 (2026-07-31 → 2026-08-29)

Die wichtigsten Beitragenden laut API, nach Anzahl der Beiträge: stunningpixels (878), abcpro1 (257), LSRCT (235), actions-user (213) und anastasiya1155 (112).

Vorbehalte: die GitHub-API weist open_issues_count aus, was offene Pull Requests einschließt, sodass 533 nicht als reine Issue-Zahl gelesen werden sollte. Das Feld watchers_count der allgemeinen Antwort spiegelt die Sterne wider; deshalb wird subscribers_count (119) separat als reale Abonnenten angegeben. Der npm-Registereintrag vibe-kanban (erstellt am 20. Juni 2025, 198 Versionen, letzte 0.1.44) beschreibt das Paket als „NPX-Wrapper für vibe-kanban und vibe-kanban-mcp”; die Downloads sind gegenüber ihrem Höhepunkt spürbar gesunken, passend zur Schließung des Unternehmens.

Wie die Community reagierte

Die wichtigste verifizierbare Konversation ist der Show HN 44533004 (11. Juli 2025, 195 Punkte, 132 Kommentare, eingereicht von louiskw). Er zeigt echten Enthusiasmus und konkrete Einwände gleichermaßen:

Lob:

lharries: „Habe es letzte Woche genutzt und es ist ausgezeichnet — dasselbe Produktivitätsschub-Gefühl wie bei meiner ersten Nutzung von Cursor”, und bat um eine gehostete Version zur Zusammenarbeit mit seinem Team.
mrlesk (Autor von backlog.md, einem ähnlichen Projekt): „euer Team hat großartige Arbeit mit Vibe Kanban geleistet. Freut mich, mehr Werkzeuge zu sehen, die versuchen, die Mensch-Agent-Interaktion zu lösen”.
swyx merkte an, dass Louis „einen langen Vortrag hielt und live zusätzliche Funktionen bei unserem Discord-Meetup codete” (ein im Thread verlinktes YouTube-Video).
skeptrune stellte die Verbindung zur Vergangenheit des Teams her: „ich erinnere mich an die ursprüngliche Bloop-Suchmaschine”.

Kritik und Einwände:

codingdave: „Es ist nicht nur Chaos, es ist ein unerwünschtes Produkt… Produkte wie dieses bauen auf der Annahme auf, dass KI weit genug gereift ist… Vibe Coding ist noch [unreif]”.
csomar: „Warum braucht es GitHub-Auth? Es fordert unbegrenzten privaten Repo-Zugriff. Für mich ein klares NEIN”; und nach der Antwort des Teams: „dann hätten sie eine GitHub App statt einer OAuth App verwenden sollen, weil die App granulare Auswahl erlaubt”.
doritosfan84: „die angeforderten Berechtigungen erscheinen mir verrückt… warum braucht ein Kanban-Board Einblick in meinen Code oder meine Deploy-Schlüssel?”; TeMPOraL präzisierte, dass „es nicht ‘ein Kanban-Board’ ist, sondern ein Code-Agenten-Orchestrator in Kanban-Form”.
Zur Marktprämisse stellten barbazoo und bwfan123 infrage, ob „Ingenieure den Großteil ihrer Zeit mit Planen, Überprüfen und Orchestrieren verbringen”, und deepdarkforest berichtete, dass Agenten beim Parallelisieren „kollidieren, indem sie gleichzeitig Dateien bearbeiten, ich verliere den mentalen Kontext und sie schreiben Tests um”.

Neben dem Show HN fand eine Hacker-News-Suche kleinere Threads zu abgeleiteten Projekten, die Vibe Kanban zitieren (alle mit sehr geringer Zugkraft): 46939622 (claude-vibekanban, 2 Punkte), 49367532 (vibe-kanban-alternative mit mem0, 1 Punkt), 48370360 (Circus Chief, 4 Punkte), 47638715 (Batty, 2 Punkte) und 47019438 (Silo, 2 Punkte). Es wurde keine Launch-Ankündigung mit einer umfangreichen, vom Haupt-Show-HN abweichenden Diskussion gefunden, sodass keine über die Quellen hinausgehenden Kommentarzahlen unterstellt werden.

Vibe Kanban im Vergleich zu ähnlichen Projekten

Projekt	Verifizierbare Übereinstimmung	Verifizierbarer Unterschied
`mrlesk/backlog.md`	Ein Kanban-Board zur Verwaltung von Code-Agenten-Arbeit; der Autor von Vibe Kanban und der von backlog.md zitierten sich gegenseitig im Thread.	backlog.md konzentriert sich auf Planung mit Markdown/Tickets; Vibe Kanban fügt Agenten-Workspaces, einen Live-Diff, Vorschau und PRs in der UI hinzu.
`knowsuchagency/fulcrum` (90★)	Kombiniert Agenten-Orchestrierung mit Deployment; beschreibt sich selbst als Mischung aus Vibe Kanban mit anderen Werkzeugen.	Positioniert sich als Fusion mehrerer Projekte (Openclaw, Vibe Kanban, Vibetunnel, Dokploy), nicht als reines Agenten-Kanban.
`automagik-dev/forge` (89★)	Multi-Agenten-Kanban mit MCP-Integration zur Orchestrierung von Agenten und zum Experimentieren mit isolierten Versuchen.	Rahmt die Erfahrung als „Vibe Coding++” mit Schwerpunkt auf Versuchsexperimenten; anderer Stack und andere Marke.
`GarrickZ2/grove` (46★)	Verwaltet Git-Worktrees als Aufgaben und führt mehrere Agenten in isolierten Sitzungen aus.	Ein tmux-basiertes TUI (Terminal) mit hook-basierten Benachrichtigungen, gegenüber Vibe Kanbans Desktop- + Web-App.
`qwenode/vibe-kanban-promax` (13★)	Ein direkter Fork von vibe-kanban.	Fügt reinen Lokalmodus und keine Anmeldung hinzu, ausgerichtet auf leichtere Nutzung nach dem Sunset.

Der nützlichste Vergleich erfolgt nicht nach Popularität: Vibe Kanban sticht als die visuelle Agenten-Orchestrierungsschicht mit den meisten Sternen im Vergleichsfeld hervor, aber sein praktischer Vorteil (parallele Agenten + Überprüfung + PR in einer UI) wird bereits von mehreren kleineren Werkzeugen repliziert; sein aktueller Nachteil ist die Unsicherheit über die Wartung nach der Schließung von bloop.

Wie man beiträgt

Das README dokumentiert einen spezifischen Beitragsprozess:

Zuerst mit dem Team sprechen: „wir bevorzugen, dass Ideen und Änderungen zuerst mit dem Kernteam über GitHub Discussions oder Discord besprochen werden, wo wir Implementierungsdetails und die Abstimmung mit der bestehenden Roadmap diskutieren können. Bitte öffnet keine PRs, ohne euren Vorschlag zuvor mit dem Team besprochen zu haben”.
Feature-Anfragen → GitHub Discussions; Bugs → Repository-Issues.
Lokale Entwicklung: Voraussetzungen sind Rust (stable), Node.js (≥ 20) und pnpm (≥ 8), plus cargo install cargo-watch und cargo install sqlx-cli. Abhängigkeiten werden mit pnpm i installiert, der Entwicklungsserver mit pnpm run dev gestartet (startet Backend und Web-App und kopiert eine leere DB aus dev_assets_seed).
Web-Build: cd packages/local-web && pnpm run build. Build aus dem Quellcode unter macOS mit ./local-build.sh, getestet mit cd npx-cli && node bin/cli.js.

Angesichts der Schließung des Unternehmens ist dieser Ablauf nun auf die von bloop als nächsten Schritt angekündigte Community-Edition ausgerichtet; es lohnt sich, in Discussions/Discord den aktuellen Stand der Beitragsannahme zu prüfen.

Anwendungsfälle

Ingenieure, die mehrere Agenten sequenziell ausführen und Zeit mit Warten verlieren: der dokumentierte direkte Wert besteht darin, Workspaces zu parallelisieren (einer pro Agent/Branch) und vom „Warten 2-5 Minuten pro Aufgabe” zum stapelweisen Überprüfen mehrerer Diffs überzugehen. Jeder Workspace bietet isolierten Branch, Terminal und Server.
Teams, die einen einzigen Punkt für Überprüfung und Auslieferung wollen: der Ablauf Issue → Workspace → Diff mit Inline-Kommentaren → PR (mit KI-generierter Beschreibung) → Merge deckt die Versionskontroll-Bürokratie innerhalb derselben Oberfläche ab, mit GitHub- und Azure-Repos-Integrationen.
Entwickler von Webanwendungen, die Änderungen testen: der integrierte Browser mit Devtools, Inspektionsmodus und Geräteemulation erlaubt Vorschau und Debugging der App, ohne das Fenster zu wechseln, mit Click-to-Component, um zur Quelle zu springen.
Personen, die mit MCP orchestrieren: der eigene MCP-Server und die Fähigkeit, Drittanbieter-MCP hinzuzufügen, erlauben es einem Agenten, Tickets zu erstellen oder auf mehr Werkzeuge innerhalb von Vibe Kanban zuzugreifen — nützlich zur Automatisierung der Planung.
Nutzer, die nach dem Sunset einen lokalen, eigenständigen Weg suchen: mit Datenexport, dem angekündigten lokalen Modus und dem Ökosystem „local-only / ohne Anmeldung”-Forks (z. B. vibe-kanban-promax) können jene, die nicht von Cloud-Diensten abhängen wollen, das Kanban-plus-Agenten-Muster ohne Konto beibehalten und die Community-Wartung übernehmen.

Ressourcen

Repository: https://github.com/BloopAI/vibe-kanban
Dokumentation: https://vibekanban.com/docs (LLM-Index: https://vibekanban.com/docs/llms.txt)
Schließungsankündigung: https://www.vibekanban.com/blog/shutdown
Unterstützte Agenten: https://vibekanban.com/docs/supported-coding-agents
Self-Hosting (Docker): https://vibekanban.com/docs/self-hosting/deploy-docker
Vibe-Kanban-MCP-Server: https://vibekanban.com/docs/integrations/vibe-kanban-mcp-server
Community: GitHub Discussions (https://github.com/BloopAI/vibe-kanban/discussions) und Discord (https://discord.gg/AC4nwVtJM3)
Paketregister: npm vibe-kanban (https://www.npmjs.com/package/vibe-kanban)
Hacker-News-Threads: Show HN 44533004 (195 Pkt., 132 Kmt.); Ableger: 46939622, 49367532, 48370360, 47638715, 47019438
Video (im Thread referenziert): Louis Knight-Webbs Vortrag beim Meetup von swyx (YouTube im Thread 44533004 verlinkt, https://www.youtube.com/watch?v=NCksand7Iwo)

Hinweis: dieser Artikel stützt sich auf das README und die Dokumentation von Vibe Kanban, bloops Schließungsankündigung (10. April 2026), die GitHub-API, das npm-Register und die am 1. September 2026 konsultierten Hacker-News-Threads. Zahlen ändern sich mit der Zeit; das Projekt ist nach der Schließung des Unternehmens zur Community-Wartung übergegangen.