Du lässt mehrere KI-Coding-Agenten auf derselben Codebasis arbeiten. Vielleicht drei, vielleicht dreizehn. Sie müssen ihre eigene Arbeit verwalten: Issues erstellen, Status aktualisieren, Abhängigkeiten prüfen, Fortschritte melden. Dutzende Schreibvorgänge pro Minute über 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 dein Team für Projektmanagement nutzt.
Es funktioniert nicht. Und die Inkompatibilität ist nicht oberflächlich. 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 Abhängigkeiten lesen, seinen Status aktualisieren: Das sind drei Roundtrips durch HTTPS, DNS-Auflösung, TLS-Handshake und JSON-Serialisierung. Nenn 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 du es mit der Anzahl der Operationen multiplizierst. Ein Agent, der eine Aufgabe bearbeitet, erstellt vielleicht 2-3 Unter-Issues, aktualisiert den Status des Eltern-Issues, prüft Blockaden und kommentiert seinen Fortschritt. Sechs Operationen. Bei 500ms pro Stück sind das 3 Sekunden reines Warten. Bei 10ms pro Stück sind es 60 Millisekunden. Der Agent, der einen Aufgabenzyklus in 30 Sekunden abschließen könnte, verbringt jetzt 10% seiner Zeit mit Warten auf HTTP statt Code zu schreiben.
Skalier das auf 13 Agenten und der Overhead wird in Minuten pro Stunde gemessen.
Auth-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 hängt er in einer Retry-Schleife mit exponentiellem Backoff, statt seine Arbeit zu machen.
Du hast gerade einen kompletten Fehlermodus hinzugefügt, der nichts mit der eigentlichen Arbeit zu tun hat. Token-Rotation, Secret-Management, Verteilung von Rate Limits über Agenten. Das ist operativer Overhead für eine Fähigkeit, 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
Öffne Jira. Du siehst Sprints. Story Points. Zugewiesene Personen mit Profilfotos und E-Mail-Adressen. Workflows mit Zuständen wie "In Review" und "Ready for Grooming". Das gesamte Datenmodell wurde für ein Team von Menschen entworfen, die Standups, Sprint-Planung und Retrospektiven durchführen.
Agenten machen keine Standups. Sie schätzen nicht in Story Points. Sie brauchen keinen Workflow mit sieben Zuständen und vier Freigabe-Gates.
Was Agenten brauchen, ist ein Abhängigkeitsgraph. 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 zurückgemeldet. Die grundlegende Datenstruktur ist ein Baum von Aufgaben mit Blockierungsbeziehungen, kein Board mit Karten, die durch Spalten wandern.
SaaS-Tools fügen "Automatisierungs"-Features hinzu, aber das Kernmodell darunter ist immer noch ein Kanban-Board für Menschen. Du kannst ein Jira-Plugin schreiben, das Agenten Issues erstellen lässt. Du kannst nicht ändern, dass Jira deinen Agenten für eine Person in einem Sprint-Team hält.
Cloud-Abhängigkeit ist ein Single Point of Failure
Deine Agenten laufen lokal. Sie lesen lokale Dateien, schreiben lokalen Code und committen in lokale Git-Repos. Sie können offline arbeiten, im Flugzeug oder in einem Netzwerk mit 2000ms Latenz. Es ist ihnen egal.
Aber wenn dein Issue-Tracker ein SaaS-Produkt ist, braucht jede Agenten-Operation Internetzugang. Linear fällt 10 Minuten aus? Deine gesamte Flotte steht still. Deine 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 zuverlässig wie das Dateisystem. Immer verfügbar, immer schnell, immer unter deiner Kontrolle.
Das Schreibvolumen liegt um Größenordnungen daneben
SaaS-Projektmanagement-Tools sind für ein Team von 5-10 Menschen ausgelegt, die eine Handvoll Updates pro Tag machen. Vielleicht 50-100 Schreibvorgänge 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 völlig anderes Nutzungsmuster. Rate Limits, die für menschliche Teams großzügig erscheinen, werden zu harten Mauern für Agent-Flotten.
Und es geht nicht nur um Volumen. Es geht um Concurrency. 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 lösen mussten, weil Menschen nicht dasselbe Issue von drei Terminals im selben Moment aktualisieren.
Zusammenarbeit bedeutet, deine Daten abzugeben
Um ein Jira-Projekt mit einem Kollegen zu teilen, brauchen beide ein Jira-Konto. Die Daten liegen auf Atlassians Servern. Du zahlst pro Platz, pro Monat, für das Privileg, über deren API auf deine eigenen Projektdaten zuzugreifen.
Willst du zu einem anderen Tool wechseln? Exportier, was geht, als CSV und lass den Rest zurück. Kommentare, Anhänge, benutzerdefinierte Felder, Audit-Historie: Viel Glück, das alles in einem brauchbaren Format herauszubekommen. Das SaaS-Modell tauscht Datenhoheit gegen Bequemlichkeit.
Aber Zusammenarbeit braucht keinen Mittelsmann. Wenn deine Issue-Datenbank von etwas wie Dolt (Git für Datenbanken) gestützt wird, pushst du sie zu einem Remote und dein Kollege pullt sie. Branch deine Issue-Datenbank genauso wie du Code branchst. Merge genauso. Löse Konflikte mit denselben Tools und demselben mentalen Modell. Deine Daten bleiben deine. Zusammenarbeit funktioniert wie Git, nicht wie ein Abonnement.
Was tatsächlich funktioniert
Lass die Markennamen weg und überleg, was Agenten wirklich von einem Issue-Tracker brauchen:
- Local-first. Keine Netzwerkabhängigkeit. Die Datenbank ist eine Datei auf der Festplatte.
- CLI-nativ. Agenten leben im Terminal. Die Schnittstelle sollte es auch.
- Git-basiert. Versioniert, zusammenführbar, auditierbar. Kein Vendor Lock-in.
- Kein Auth-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 über API-Webhooks.
Das nutze ich täglich. beads ist ein Git-nativer Issue-Tracker, der genau für diesen Workflow gebaut wurde. Er speichert alles in einer lokalen SQLite-Datenbank, gestützt durch Dolt für Versionierung und Sync. Die CLI ist die primäre Schnittstelle. Agenten erstellen, aktualisieren und fragen Issues ab, genau wie sie jeden anderen Befehl ausführen.
Beadbox ist die visuelle Schicht, die ich darüber gebaut habe. Sie beobachtet die lokale Datenbank auf Änderungen und rendert Abhängigkeitsbäume, Epic-Fortschritt und Agenten-Aktivität in Echtzeit. Die Agenten nutzen die 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 großartig für kleine Teams, die Geschwindigkeit und Feinschliff wollen. GitHub Issues ist reibungslos für Open-Source-Zusammenarbeit.
Keines davon ist schlecht. Sie lösen ein anderes Problem. Wenn dein Workflow ein Team von fünf Menschen ist, das Zwei-Wochen-Sprints macht, nutz sie weiter.
Aber wenn du 5, 10 oder 13 KI-Agenten betreibst, die sich in Echtzeit auf derselben Codebasis koordinieren, bist du über das SaaS-Modell hinausgewachsen. Agentic Engineering braucht Werkzeuge, die für Agentic Engineering gebaut sind, nicht menschliche Workflows mit einer angeschraubten API.