Du hast dir eine Arbeitsweise rund um ein Board angewöhnt. Eine Spalte pro Aufgabe, ein Coding-Agent pro Karte, jeder in seinem eigenen Git-Worktree, damit sich nichts in die Quere kam. So ließen sich sauber drei oder vier Agenten gleichzeitig laufen lassen und ihre Diffs trotzdem einzeln prüfen. Dann hat das Unternehmen, das das Tool gepflegt hat, seine Cloud abgeschaltet, und die ehrliche Frage stand im Raum: Wo lässt du deine Coding-Agenten jetzt laufen – und trägt die Antwort mehr als einen Laptop und eine Person?
Wenn du nach einer Vibe-Kanban-Alternative suchst, suchst du keinen Ersatz für Claude Code oder Codex. Du suchst die Ebene rund um diese Runtimes: die Stelle, die jedem Agenten eine Aufgabe übergibt, seine Arbeit isoliert hält und dir zeigt, was sich geändert hat, bevor irgendetwas gemergt wird. Dieser Leitfaden behandelt genau diese Ebene. Er würdigt Vibe Kanban für das Muster, das es bewiesen hat, markiert die exakte Grenze, an der ein lokales Board endet, und zeigt, wie Sharkly über diese Grenze hinaus zu gemeinsamen Tasks, Crews und Sprints für ein ganzes Team weitergeht.
TL;DR
Vibe Kanban hat das Modell „ein Board pro Agent“ geprägt: mehrere Coding-Agenten parallel laufen lassen, jeder in seinem eigenen Worktree, und ihre Ergebnisse auf einem Kanban-Board auf deinem Rechner prüfen. Sharkly behält dieses Modell bei und ergänzt die Team-Ebene darum: einen gemeinsamen Task-Datensatz, verbundene Computer, Crews, Sprints und menschliche Review von der Anforderung bis zum Release. Wenn du allein an einem Rechner arbeitest, reicht ein lokales Board. Wenn ein Team gemeinsamen Kontext und ein Review-Gate braucht, setzt Sharkly genau dort an.
Das Problem, das eine Vibe-Kanban-Alternative wirklich löst
Vibe Kanban hat etwas richtig gemacht, was die meisten Tools übersehen haben. Wenn du mehrere KI-Coding-Agenten gleichzeitig laufen lässt, sind nicht die Modelle das Schwierige, sondern die Kollisionen. Zwei Agenten bearbeiten dieselben Dateien, die Ausgaben verteilen sich über Terminal-Tabs, und niemand hat einen Überblick darüber, welche Aufgabe erledigt ist, welche blockiert ist und welche still und leise schiefgelaufen ist.
Die Antwort „ein Board pro Agent“ war elegant. Jede Aufgabe bekommt ihre eigene Karte. Jede Karte bekommt ihren eigenen Git-Worktree, damit der Agent auf einem isolierten Branch in einem isolierten Verzeichnis arbeitet. Claude Code, Gemini CLI, Codex oder eine andere Runtime erledigen die Arbeit in dieser Sandbox, und anschließend kommt der Diff zur Review zurück. Aus „Ich habe fünf Agenten und keine Ahnung, was sie gemacht haben“ wurde ein Board, das man tatsächlich lesen konnte. Wenn dich die Mechanik dieses parallelen Musters an sich interessiert, beschreibt unser Leitfaden wie du mehrere Claude Code Agenten parallel laufen lässt das Worktree-Setup im Detail.
Die Lücke war nie das Muster. Die Lücke ist das, was ein lokales Board nicht erreichen kann. Ein Board auf deinem Rechner ist ein Board für dich. Dein Teammitglied kann die Aufgabe nicht sehen, keine blockierte Karte übernehmen, den Diff nicht vor dem Merge prüfen und von der anderen Seite des Raums nicht erkennen, ob der Sprint im Plan liegt. Solange die Arbeit allein läuft, ist das in Ordnung. Gehört die Arbeit aber einem Team, fehlt ein gemeinsamer Datensatz – und das ist eine andere Art von Tool.
Was Vibe Kanban bewiesen hat – ganz nüchtern
Man muss dem Tool zugestehen, was es geleistet hat, denn es hat es sich verdient. Vibe Kanban behandelte Agenten-Läufe als eigenständige Arbeitseinheiten statt als Wegwerf-Terminalsitzungen. Es machte die Worktree-Isolation zum Standard, sodass parallele Agenten sich nicht mehr gegenseitig in die Quere kamen. Der Wechsel zwischen Runtimes war günstig, man war also nicht an ein Modell gebunden. Und die Review wurde zu einem echten Schritt statt zu einem Nachgedanken, weil der Diff vor dir lag, bevor du eine Karte auf „Erledigt“ gezogen hast.
Diese vier Ideen sind richtig, und jede ernstzunehmende Alternative muss sie alle beibehalten. Eine Vibe-Kanban-Alternative, die die Worktree-Isolation aufgibt, den Diff versteckt oder dich an eine einzige Runtime bindet, ist ein Rückschritt, egal was sie sonst noch bietet. Die Messlatte, die das Board gesetzt hat, ist die Untergrenze, nicht die Obergrenze.
Was sich geändert hat, ist die Wartungsgeschichte. Das Projekt ist Open Source und lässt sich weiterhin lokal betreiben, aber die vom Unternehmen betriebenen Cloud-Funktionen wurden entfernt und laufende Fixes hängen jetzt von Community-Mitwirkenden ab. Für einen Solo-Entwickler ist das vielleicht völlig in Ordnung. Für ein Team, das ein Quartal seiner Auslieferung auf dieses Tool setzt, ist „hängt davon ab, wer gerade auftaucht“ ein echtes Risiko, das es abzuwägen gilt – und das ist der ehrliche Grund, warum gerade jetzt so viele über einen Wechsel nachdenken.
Wo das lokale Board endet und Sharkly übernimmt
Hier ist das Entscheidungspaar, so formuliert, wie die Wahl tatsächlich ausfällt.
Nutze ein lokales Board, wenn du eine Person an einem Rechner bist, die Aufgaben allein dir gehören und niemand sonst die Arbeit sehen muss, bevor du einen Pull Request öffnest. Das Setup mit einem Board pro Agent ist schlank, läuft dort, wo du läufst, und verursacht null Koordinationsaufwand, weil es niemanden gibt, mit dem man sich koordinieren müsste. In diesem Fall wäre eine Team-Plattform überdimensioniert.
Nutze Sharkly, wenn die Agenten-Läufe nicht mehr privat sind. In dem Moment, in dem eine zweite Person eine Aufgabe zuweisen, einen Blocker übernehmen oder einen Diff vor dem Merge prüfen muss, wird ein Board auf deinem Laptop zum Engpass. Das ist die Grenze. Sharkly ist die Ebene, die um dieselben Runtimes herum liegt, die du ohnehin nutzt, und jeden Lauf zuweisbar, sichtbar und für das Team – nicht nur für dich – prüfbar macht.
Eine kurze Definition, lexikonreif, weil alles Weitere darauf aufbaut. Ein Task ist die zentrale Arbeitseinheit in Sharkly. Er enthält das Ziel, den zugewiesenen Agenten, die Runtime, den Fortschritt, die Blocker, den entstandenen Diff und die menschliche Review – alles in einem gemeinsamen Datensatz. Während eine Karte auf einem lokalen Board dir gehört, gehört ein Task dem Team.
Und noch eine Abgrenzung, denn wer von einem Board wechselt, würde sonst falsche Annahmen treffen. Sharkly ist kein Ersatz für Claude Code, Codex oder Gemini. Es führt das Modell nicht aus und schreibt keinen Code. Es ergänzt den gemeinsamen Task sowie eine Ebene für verbundene Computer, Kontext, Kontrolle und Review um die Ausführungstools, die dein Team bereits nutzt. Wenn du es an Vibe Kanban geschätzt hast, dass du Runtimes frei wechseln konntest: Sharkly behält diese Freiheit und stellt ein Team drumherum.
Der Migrationspfad: Runtimes behalten, Repos behalten, Review-Ebene ergänzen
Das Beste am Wechsel weg von einem auslaufenden Board ist, wie wenig du aufgeben musst. Du baust deinen Stack nicht neu auf. Du behältst die Teile, die funktioniert haben, und ergänzt den Teil, der gefehlt hat.
Behalte deine Runtimes. Claude Code, Codex, Gemini CLI, OpenCode, Cline und der Rest führen die Ausführung genau wie bisher durch. Die Modellnutzung läuft weiter über die Abos oder API-Schlüssel, die in diesen Tools bereits konfiguriert sind. Du bringst dein eigenes Abo mit; Sharkly steht nicht zwischen Agent und Modell. Wenn du die konzeptionelle Grundlage dafür willst, was diese Runtimes tun, erklärt unser Beitrag was agentisches Coding für Dev-Teams bedeutet die Begriffe.
Behalte deine Repos und deine Worktree-Gewohnheit. Sharkly führt Agenten in isolierten Worktrees auf verbundenen Computern aus – dieselbe Isolation, auf die du dich verlassen hast, jetzt an einen gemeinsamen Task statt an eine lokale Karte gebunden. Frontend, Backend, Bugfixing und Testabdeckung können gleichzeitig voranschreiten, ohne zu kollidieren. Genau dafür gab es das Modell mit einem Board pro Agent.
Ergänze die Review-Ebene, die dir gefehlt hat. Das ist der neue Teil. Ausführung, Blocker, Ergebnisse und die anschließende Diskussion landen in der Timeline des Tasks, wo das Team sie sehen kann. Ein Agent recherchiert, führt aus, testet und berichtet. Menschen geben die Richtung vor, erteilen Befugnisse und nehmen das Ergebnis ab. Die Automatisierung endet dort, wo Team-Urteilsvermögen gefragt ist, und liefert ein Ergebnis mit vollständigem Kontext und überprüfbaren Belegen zurück. Dieser letzte Satz ist der Vertrag, den ein lokales Board nicht durchsetzen konnte, weil auf der anderen Seite kein Team stand.
Die Migration ist also additiv. Verbinde einen Computer, richte Sharkly auf die Runtimes aus, die du bereits hast, und beginne, Arbeit zu verteilen, ohne den Prozess neu aufzubauen, den dein Team schon versteht. Das Board hat dir beigebracht, Agenten parallel laufen zu lassen. Sharkly lässt den Rest des Teams daran teilhaben.
Vom Solo-Board zum Team-System: Crews, Sprints und Projekte
Sobald die Läufe geteilt werden, eröffnen sich drei Fähigkeiten, die ein Single-User-Board nicht bieten konnte.
Crews, für Arbeit, die mehr als einen Agenten braucht. Eine Crew ist eine wiederverwendbare Gruppe aus Menschen und Agenten, die von einem leitenden Agenten koordiniert wird. Für kleine, klar umrissene Arbeit brauchst du keine: Weise den Task einem einzelnen Agenten zu und halte die beweglichen Teile bei null. Nutze eine Crew, wenn der leitende Agent ein umfassenderes Ziel interpretieren, weitere Agenten-Mitglieder hinzuziehen und ihre Ergebnisse in einem Task zusammenführen muss. Das ist die ehrliche Regel. Eine Crew ist ein Hebel, wenn die Arbeit wirklich aus mehreren Teilen besteht – und Ballast, wenn nicht.
Sprints und Projekte, für ein Tracking, das länger als eine Karte hält. Ein lokales Board zeigt die Aufgaben, die heute vor dir liegen. Ein Sprint verfolgt Fertigstellung, Zuständigkeit, Abhängigkeiten, Scope-Änderungen und Blocker über eine Gruppe von Arbeit hinweg über die Zeit. Für ein hybrides Team aus Menschen und Agenten ist das der Unterschied zwischen „die Agenten haben diese Woche ein paar Sachen gemacht“ und einem Plan, über den man tatsächlich Bericht erstatten kann. Unser Grundlagenbeitrag KI-Agenten-Orchestrierung für Dev-Teams geht darauf ein, warum der Durchsatz eines Teams in der Koordinationsebene gewonnen oder verloren wird – nicht bei den Modellen.
Team-Transparenz als Standard statt als Screen-Sharing. Halte Kontext, Fortschritt, Blocker, Ergebnisse und menschliche Review von der Anforderung bis zum Release sichtbar. Auf einem lokalen Board endete die Sichtbarkeit an deinem Monitor. In einem geteilten System entsteht der Hebel nicht dadurch, dass man mehr KI-Chats öffnet, sondern dadurch, dass man Rollen, Regeln, Kontext und Workflows teilt, sodass aus einem guten Setup eine Fähigkeit wird, die das ganze Team wiederverwendet.
Vibe Kanban vs. Sharkly: ein fairer Vergleich
| Dimension | Vibe Kanban (lokales Board) | Sharkly (Team-Ebene) |
|---|---|---|
| Zentrale Einheit | Karte auf deinem Rechner | Gemeinsamer Task für das Team |
| Parallele Agenten | Ja, worktree-isoliert | Ja, worktree-isoliert auf verbundenen Computern |
| Runtimes | Claude Code, Gemini, Codex und mehr | Dieselben Runtimes, unverändert eingebunden |
| Review | Diff-Review, solo | Menschliche Review von der Anforderung bis zum Release, teamweit |
| Gruppierung mehrerer Agenten | Nicht Teil des Modells | Crews mit einem leitenden Agenten |
| Planung über die Zeit | Board-Ansicht | Projekte und Sprints |
| Modell-Abrechnung | Eigene Schlüssel, läuft lokal | Eigenes Abo mitbringen; Schlüssel bleiben in den Tools |
| Wartung | Open Source, nach der Abschaltung von der Community gepflegt | Aktiv weiterentwickelte Plattform |
| Am besten geeignet für | Solo-Entwickler an einem Rechner | Teams, die Agenten-Arbeit gemeinsam verteilen und prüfen |
Lies die Tabelle als Arbeitsteilung, nicht als Punktestand. Für einen Solo-Entwickler, der ein kostenloses lokales Board und nichts weiter will, mag das von der Community gepflegte Projekt nach wie vor die richtige Wahl sein – und dabei zu bleiben ist völlig in Ordnung. Für ein Team, das die Läufe geteilt, zuweisbar und prüfbar braucht, war das Board von Anfang an zu klein, und Sharkly ist der Ort, an dem dieselben Runtimes weiterlaufen – mit dem Team drumherum. Du kannst Sharkly herunterladen und einen Computer verbinden, um den Unterschied an echter Arbeit zu sehen.
Häufige Fehler beim Wechsel weg vom lokalen Board
- Es als Eins-zu-eins-Tausch behandeln. Du suchst kein weiteres Board. Du suchst die Team-Ebene, die das Board nie hatte. Wenn die Alternative nur Spalten und Karten nachbaut, hat sie nichts gelöst.
- Die Worktree-Isolation aufgeben, um schneller zu sein. Die Isolation ist der Grund, warum parallele Agenten nicht kollidieren. Behalte sie. Jedes Tool, das Agenten ein gemeinsames Arbeitsverzeichnis aufzwingt, holt ein echtes Problem zurück ins Haus.
- Eine Crew für Single-Agent-Arbeit anlegen. Greife nur dann zu einer Crew, wenn das Ziel wirklich einen leitenden Agenten braucht, der Mitglieder koordiniert. Bei einer gut abgegrenzten Aufgabe ist ein Agent und null bewegliche Teile die richtige Antwort.
- Das Review-Gate überspringen, um sich produktiv zu fühlen. Der Sinn dieser Ebene ist, dass Menschen das Ergebnis abnehmen. Agenten-Diffs ungeprüft zu mergen, weil es schneller geht, gibt genau die Sicherheit zurück, für die das ganze System da ist.
- Am ersten Tag alles migrieren. Fang mit einer echten Anforderung und einem risikoarmen Task an. Beweise den Kreislauf und weite ihn dann aus.
Fazit
Vibe Kanban hat ein Muster bewiesen, das es zu bewahren gilt: Agenten laufen am besten parallel, isoliert in ihren eigenen Worktrees, mit der Review als echtem Schritt. Dieses Muster ist heute die Untergrenze, und jede Vibe-Kanban-Alternative, die es aufgibt, ist ein Rückschritt.
- Das Modell mit einem Board pro Agent war richtig; parallele, worktree-isolierte Agenten mit Diff-Review sind die richtige Form.
- Ein lokales Board endet bei einer Person an einem Rechner. Geteilte Arbeit braucht einen gemeinsamen Datensatz.
- Sharkly behält deine Runtimes, deine Repos und deine Worktree-Gewohnheit und ergänzt die Team-Ebene darum.
- Ein Task trägt Ziel, Runtime, Fortschritt, Blocker, Diff und Review an einem Ort.
- Crews, Sprints und Projekte machen aus parallelen Läufen einen Plan, über den ein Team Bericht erstatten kann.
- Agenten recherchieren, führen aus, testen und berichten; Menschen geben die Richtung vor, erteilen Befugnisse und nehmen das Ergebnis ab.
Wenn du entscheidest, wo deine Coding-Agenten künftig laufen sollen, behalte die Tools, die dein Team bereits nutzt, und ergänze die Ebene, die Läufe zuweisbar und nachvollziehbar macht. Verbinde einen Computer, erstelle einen Agenten und weise ihm etwas Langweiliges zu. Und lass dann den Rest des Teams zusehen, wie die Arbeit im Task zurückkommt. Starte unter Sharkly; die Docs behandeln jedes Konzept ausführlicher unter docs.sharkly.ai.
FAQ
Ist Vibe Kanban nach der Abschaltung von Bloop noch nutzbar? Ja. Das Projekt ist Open Source und lässt sich weiterhin lokal betreiben. Die vom Unternehmen betriebenen Cloud-Funktionen wurden entfernt, und Fixes und Updates hängen jetzt von Community-Mitwirkenden ab. Für die Solo-Nutzung mag das in Ordnung sein; für ein Team, das sich bei der Auslieferung darauf verlässt, ist das Wartungsrisiko eine Abwägung wert.
Ist Sharkly ein Ersatz für Claude Code oder Codex? Nein. Sharkly ist kein Ersatz für Claude Code, Codex oder andere Ausführungstools. Die Ausführung übernehmen diese Runtimes. Sharkly ergänzt den gemeinsamen Task sowie eine Ebene für Computer, Kontext, Kontrolle und Review darum. Du nutzt weiterhin dieselben Agenten.
Muss ich darauf verzichten, Agenten in parallelen Worktrees laufen zu lassen? Nein. Sharkly führt Agenten in isolierten Worktrees auf verbundenen Computern aus – dieselbe Isolation, auf die das Modell mit einem Board pro Agent gesetzt hat. Frontend, Backend und Tests können gleichzeitig laufen, ohne zu kollidieren. Wie das zugrunde liegende Muster funktioniert, steht in wie du mehrere Claude Code Agenten parallel laufen lässt.
Was bedeutet die Migration von einem lokalen Board konkret? Behalte deine Runtimes und deine Repos. Verbinde einen Computer, richte Sharkly auf die Ausführungstools aus, die du bereits nutzt, und beginne, Arbeit als gemeinsame Tasks zu verteilen. Die Modellnutzung läuft weiter über die Abos oder API-Schlüssel, die in diesen Tools bereits konfiguriert sind, an der Abrechnung ändert sich also nichts.
Wann sollte ich Sharkly nicht nutzen? Wenn du eine Person an einem Rechner bist und niemand sonst die Arbeit sehen oder prüfen muss, reicht ein lokales Board. Sharkly verdient seinen Platz in dem Moment, in dem eine zweite Person einen Agenten-Lauf zuweisen, übernehmen oder prüfen muss.
Was ist der Unterschied zwischen einer Karte und einem Task? Eine Karte auf einem lokalen Board gehört dir und liegt auf deinem Rechner. Ein Task ist der gemeinsame Datensatz des Teams: Er enthält das Ziel, den zugewiesenen Agenten, die Runtime, den Fortschritt, die Blocker, den Diff und die menschliche Review, und die Ausführungsergebnisse laufen dort zurück.
