Sie lassen mehrere KI-Coding-Agenten auf derselben Codebasis arbeiten. Vielleicht drei, vielleicht dreizehn. Sie mussen ihre eigene Arbeit verwalten: Issues erstellen, Status aktualisieren, Abhangigkeiten prufen, Fortschritte melden. Dutzende Schreibvorgange pro Minute uber die gesamte Flotte.
Das ist agentic engineering: Menschen, die Flotten von KI-Agenten koordinieren, um Software auszuliefern. Der Workflow ist neu, aber das Erste, was alle tun, ist zum bekannten Tool zu greifen. Jira. Linear. GitHub Issues. Notion. Was auch immer Ihr Team fur Projektmanagement nutzt.
Es funktioniert nicht. Und die Inkompatibilitat ist nicht oberflachlich. Sie ist architektonisch.
Latenz vernichtet Durchsatz
Ein Jira-API-Aufruf dauert 200-800ms. Ein Linear-API-Aufruf ist schneller, liegt aber immer noch bei 100-300ms. Ein einzelnes Issue erstellen, seine Abhangigkeiten lesen, seinen Status aktualisieren: Das sind drei Roundtrips durch HTTPS, DNS-Auflosung, TLS-Handshake und JSON-Serialisierung. Nennen wir es 500ms an einem guten Tag.
Ein lokaler CLI-Schreibvorgang in eine SQLite-Datenbank dauert unter 50ms. Oft unter 10ms.
Das klingt nach einem Rundungsfehler, bis man es mit der Anzahl der Operationen multipliziert. Ein Agent, der eine Aufgabe bearbeitet, erstellt vielleicht 2-3 Unter-Issues, aktualisiert den Status des Eltern-Issues, pruft Blockaden und kommentiert seinen Fortschritt. Sechs Operationen. Bei 500ms pro Stuck sind das 3 Sekunden reines Warten. Bei 10ms pro Stuck sind es 60 Millisekunden. Der Agent, der einen Aufgabenzyklus in 30 Sekunden abschliessen konnte, verbringt jetzt 10% seiner Zeit mit Warten auf HTTP statt Code zu schreiben.
Skalieren Sie das auf 13 Agenten und der Overhead wird in Minuten pro Stunde gemessen.
Authentifizierungs-Infrastruktur ist fragiler Klebstoff
Jeder Agent braucht einen API-Token. Tokens laufen ab. Rate-Limits existieren. Ein Agent feuert 20 schnelle Updates ab und bekommt einen 429 Too Many Requests. Jetzt hangt er in einer Retry-Schleife mit exponentiellem Backoff, statt seine Arbeit zu machen.
Sie haben gerade einen kompletten Fehlermodus hinzugefugt, der nichts mit der eigentlichen Arbeit zu tun hat. Token-Rotation, Secret-Management, Verteilung von Rate-Limits uber Agenten. Das ist operativer Overhead fur eine Fahigkeit, die trivial sein sollte: einen Datensatz in eine lokale Datenbank schreiben.
Wenn der Issue-Tracker eine Datei auf der Festplatte ist, gibt es nichts, wogegen man sich authentifizieren muss. Wenn der Agent das Dateisystem lesen kann, kann er Issues lesen und schreiben. Eine Sache weniger, die kaputtgehen kann.
Das Datenmodell geht von Menschen aus
Offnen Sie Jira. Sie sehen Sprints. Story Points. Zugewiesene Personen mit Profilfotos und E-Mail-Adressen. Workflows mit Zustanden wie "In Review" und "Ready for Grooming". Das gesamte Datenmodell wurde fur ein Team von Menschen entworfen, die Standups, Sprint-Planung und Retrospektiven durchfuhren.
Agenten machen keine Standups. Sie schatzen nicht in Story Points. Sie brauchen keinen Workflow mit sieben Zustanden und vier Freigabe-Gates.
Was Agenten brauchen, ist ein Abhangigkeitsgraph. Diese Aufgabe ist von jener blockiert. Dieses Epic hat 12 Kinder und 7 sind fertig. Dieser Agent hat dieses Issue vor 45 Sekunden beansprucht und nichts zuruckgemeldet. Die grundlegende Datenstruktur ist ein Baum von Aufgaben mit Blockierungsbeziehungen, kein Board mit Karten, die durch Spalten wandern.
SaaS-Tools fugen "Automatisierungs"-Funktionen hinzu, aber das Kernmodell darunter ist immer noch ein Kanban-Board fur Menschen. Man kann ein Jira-Plugin schreiben, das Agenten Issues erstellen lasst. Man kann nicht andern, dass Jira den Agenten fur eine Person in einem Sprint-Team halt.
Cloud-Abhangigkeit ist ein Single Point of Failure
Ihre Agenten laufen lokal. Sie lesen lokale Dateien, schreiben lokalen Code und committen in lokale Git-Repos. Sie konnen offline arbeiten, im Flugzeug oder in einem Netzwerk mit 2000ms Latenz. Es ist ihnen egal.
Aber wenn Ihr Issue-Tracker ein SaaS-Produkt ist, braucht jede Agenten-Operation Internetzugang. Linear fallt 10 Minuten aus? Ihre gesamte Flotte steht still. Ihre Internetverbindung zu Hause setzt 30 Sekunden aus? Jeder Agent wiederholt in einer Schleife. Der Issue-Tracker, das Ding, das die Arbeit koordinieren soll, wird zum Single Point of Failure des gesamten Systems.
Local-first bedeutet, der Issue-Tracker ist so zuverlassig wie das Dateisystem. Immer verfugbar, immer schnell, immer unter Ihrer Kontrolle.
Das Schreibvolumen liegt um Grossenordnungen daneben
SaaS-Projektmanagement-Tools sind fur ein Team von 5-10 Menschen ausgelegt, die eine Handvoll Updates pro Tag machen. Vielleicht 50-100 Schreibvorgange im gesamten Team.
13 Agenten, die alle paar Minuten Issues aktualisieren, erzeugen Hunderte von API-Aufrufen pro Stunde aus einem einzigen Projekt. Das ist keine marginale Nutzungssteigerung. Es ist ein vollig anderes Nutzungsmuster. Rate-Limits, die fur menschliche Teams grosszugig erscheinen, werden zu harten Mauern fur Agenten-Flotten.
Und es geht nicht nur um Volumen. Es geht um Parallelitat. Drei Agenten aktualisieren gleichzeitig die Kinder desselben Epics. Race Conditions bei Statusfeldern. Optimistic-Locking-Fehler bei Kommentar-Threads. Das sind Probleme, die SaaS-Tools nie losen mussten, weil Menschen nicht dasselbe Issue von drei Terminals im selben Moment aktualisieren.
Zusammenarbeit bedeutet, Ihre Daten abzugeben
Um ein Jira-Projekt mit einem Kollegen zu teilen, brauchen beide ein Jira-Konto. Die Daten liegen auf Atlassians Servern. Sie zahlen pro Platz, pro Monat, fur das Privileg, uber deren API auf Ihre eigenen Projektdaten zuzugreifen.
Wollen Sie zu einem anderen Tool wechseln? Exportieren Sie, was geht, als CSV und lassen Sie den Rest zuruck. Kommentare, Anhange, benutzerdefinierte Felder, Audit-Historie: Viel Gluck, das alles in einem brauchbaren Format herauszubekommen. Das SaaS-Modell tauscht Datenhoheit gegen Bequemlichkeit.
Aber Zusammenarbeit braucht keinen Mittelsmann. Wenn Ihre Issue-Datenbank von etwas wie Dolt (Git fur Datenbanken) unterstutzt wird, pushen Sie sie zu einem Remote und Ihr Kollege pullt sie. Branchen Sie Ihre Issue-Datenbank genauso wie Sie Code branchen. Mergen Sie genauso. Losen Sie Konflikte mit denselben Tools und demselben mentalen Modell. Ihre Daten bleiben Ihre. Zusammenarbeit funktioniert wie Git, nicht wie ein Abonnement.
Was tatsachlich funktioniert
Lassen Sie die Markennamen weg und uberlegen Sie, was Agenten wirklich von einem Issue-Tracker brauchen:
- Local-first. Keine Netzwerkabhangigkeit. Die Datenbank ist eine Datei auf der Festplatte.
- CLI-nativ. Agenten leben im Terminal. Die Schnittstelle sollte es auch.
- Git-basiert. Versioniert, zusammenfuhrbar, auditierbar. Kein Vendor Lock-in.
- Kein Authentifizierungs-Overhead. Wenn der Agent das Dateisystem lesen kann, kann er Issues verwalten.
- Niedrige Latenz. Unter 50ms pro Operation, nicht 500ms.
- Synchronisierbar ohne Mittelsmann. Push und Pull wie ein Git-Repo, nicht uber API-Webhooks.
Das ist es, was ich taglich nutze. beads ist ein Git-nativer Issue-Tracker, der genau fur diesen Workflow gebaut wurde. Er speichert alles in einer lokalen SQLite-Datenbank, unterstutzt durch Dolt fur Versionierung und Synchronisation. Das CLI ist die primare Schnittstelle. Agenten erstellen, aktualisieren und fragen Issues ab, genau wie sie jeden anderen Befehl ausfuhren.
Beadbox ist die visuelle Schicht, die ich daruber gebaut habe. Sie beobachtet die lokale Datenbank auf Anderungen und rendert Abhangigkeitsbaume, Epic-Fortschritt und Agenten-Aktivitat in Echtzeit. Die Agenten nutzen das CLI. Ich nutze das Dashboard. Beide lesen aus derselben lokalen Datenbank.
Die alten Tools sind nicht das Problem
Jira ist hervorragend in dem, was es tut: menschliche Teams durch strukturierte Workflows koordinieren. Linear ist schon fur kleine Teams, die Geschwindigkeit und Feinschliff wollen. GitHub Issues ist reibungslos fur Open-Source-Zusammenarbeit.
Keines davon ist schlecht. Sie losen ein anderes Problem. Wenn Ihr Workflow ein Team von funf Menschen ist, das Zwei-Wochen-Sprints macht, nutzen Sie sie weiter.
Aber wenn Sie 5, 10 oder 13 KI-Agenten betreiben, die sich in Echtzeit auf derselben Codebasis koordinieren, sind Sie uber das SaaS-Modell hinausgewachsen. Agentic engineering braucht Werkzeuge, die fur agentic engineering gebaut sind, nicht menschliche Workflows mit einer angeschraubten API.