Ratgeber
Wenn Agenten den Code schreiben, kann das Board nicht lügen
Boards lügen nicht aus böser Absicht, sondern weil ihr Stand von Hand gepflegt wird. Ein Blick auf die Agenten-Ära: mehr gemergte PRs, längere Reviews, und ein Board, das aus Git ableitet, was wirklich passiert ist.
Zuletzt aktualisiert:
Projektboards lügen selten aus böser Absicht. Sie lügen, weil ihr Stand von Hand gepflegt wird: Jemand war mit der eigentlichen Arbeit beschäftigt und hat die Karte nicht gezogen. Der Board-Stand ist eine Erinnerung daran, was jemand hätte eintragen sollen, und je schneller die Arbeit läuft, desto größer die Lücke zwischen Repo und Board.
Genau diese Lücke öffnet sich gerade weit. Faros AI hat die Telemetrie von 1.255 Teams mit mehr als 10.000 Entwicklern ausgewertet: Bei Teams mit hoher KI-Adoption steigt die Zahl der gemergten Pull Requests um 98 Prozent, die Review-Zeit um 91 Prozent, und die Organisationen liefern trotzdem nicht schneller ab. Der Durchsatz verschwindet nicht, er verschiebt sich: mehr Code, mehr PRs, mehr Review- und Koordinationsarbeit. Ausgerechnet die Arbeit, die ein von Hand gepflegtes Board am schlechtesten abbildet (Faros AI, Lab vs. Reality).
Die Kategorie reagiert: Linear stellt Agenten als Teammitglieder ab. Cursor, Codex oder Devin bekommen Issues zugewiesen und arbeiten im Repo. Atlassian geht mit Rovo in dieselbe Richtung. Bei beiden Wegen passiert die Arbeit im Repository und das Ergebnis fließt in den Tracker zurück. Das ist die richtige Richtung, und sie führt an einem Punkt vorbei, den Zuuna von Anfang an fährt: Das Board leitet seinen Stand aus Git ab.
Warum ein Board aus Git nicht lügen kann
Ein Board, das aus dem Repo abgeleitet wird, hat keinen Zustand, den jemand pflegen müsste. Es hat Belege: Ein Commit hängt an der Karte, weil er in Git passiert ist. Ein Release ist fertig, weil der Git-Tag existiert. Das Deploy-Gate ist grün, weil die Pipeline es gemeldet hat. Mit jedem einzelnen dieser Punkte kann man unzufrieden sein, aber keiner von ihnen braucht eine Karte, die jemand „noch schnell“ aktualisiert, und keiner widerspricht dem Repository.
In der Agenten-Ära wird das vom netten Feature zum Kern. Wenn ein Coding-Agent die Karte über den Zuuna-MCP-Server liest, im Repo baut (Claude Code, Cursor, Codex) und der Pull Request merged, verschiebt eine Git-Regel auf dem Board die Karte. Commits, PRs, Releases und Deploy-Gates aktualisieren das Board ohne eine einzige manuelle Aktion. Niemand zieht Karten für Agenten. Das Board wiederholt nur noch, was das Repository belegt.
Was Zuuna dabei nicht tut
Zuuna schreibt keinen Code: Die Agenten bauen, mit ihren eigenen Werkzeugen. Zuuna entscheidet nichts: Es gibt keine Projektverwaltungs-KI, die plant oder priorisiert; das Board spiegelt das Repo, Agenten und Menschen machen den Rest. Und Zuuna deployt nicht ohne deine Pipeline: Deploy-Gates hängen an deinem Prozess, nicht an unserem Server. Der MCP-Server ist bewusst Board-Ein-und-Ausgabe: acht Werkzeuge, vom Board-Lesen bis zum Karten-Kommentar, sonst nichts.
Der ehrliche Stand heute: Der MCP-Server ist als mcp-server-zuuna auf npm veröffentlicht (Version 0.1.2, MIT-lizenziert, mit CI getestet), eingerichtet mit einer Zeile über npx. Wie du ihn anbindest, steht auf Zuuna für KI-Agenten.
Der Merger ist der Wahrheitsmoment
Projektwerkzeuge haben lange den Stand verwaltet: die Erzählung über Arbeit. Git verwaltet die Arbeit selbst. Ein Board, das aus Git ableitet, kann die beiden nicht mehr auseinanderfallen lassen: Es kann lückenhaft sein, wo nichts gemergt wird, aber es kann nichts sagen, was nicht stimmt. Wenn Agenten den Code schreiben, ist genau das die Eigenschaft, auf die es ankommt: Der Agent erzählt viel; das Repository hat keinen Anlass zu schweigen, und das Board übersetzt es nur.