KI-Assistenten, die eigenständig Code schreiben, testen und Änderungen vorschlagen, arbeiten selten in Sekunden. Ein Agent, der ein Refactoring über mehrere Dateien vorbereitet, läuft Minuten. Die naheliegende Reaktion in Entwicklungsteams: nicht warten, sondern einen zweiten, dritten, vierten Agenten auf andere Aufgaben setzen. Genau dort entsteht ein neues Problem, das mit der Qualität der Modelle nichts zu tun hat.

Der Engpass ist nicht das Modell, sondern die Aufmerksamkeit

Coding-Agenten sind keine Batch-Jobs, die man abschickt und später abholt. Sie stellen Rückfragen, bitten um Freigaben für Schreibzugriffe, melden fehlgeschlagene Tests oder bleiben an einer unklaren Anforderung hängen. Jede dieser Situationen bedeutet: Der Prozess steht, bis ein Mensch eingreift.

Wer fünf Agenten in fünf Terminalfenstern betreibt, verbringt einen erheblichen Teil der Zeit damit, zwischen diesen Fenstern zu wechseln und zu prüfen, wo etwas hängt. Der Produktivitätsgewinn durch Parallelität frisst sich selbst auf, weil die Koordination beim Menschen liegt. Hinzu kommt: Wird eine Sitzung versehentlich geschlossen oder die Verbindung getrennt, ist der Kontext des Agenten samt Gesprächsverlauf im Zweifel verloren.

Was Herdr macht

Das Open-Source-Projekt Herdr greift diese Situation mit einem bewusst unspektakulären Ansatz auf: Es ist ein Terminal-Multiplexer. Ein Multiplexer verwaltet mehrere Kommandozeilensitzungen innerhalb eines Fensters und hält sie am Leben, auch wenn man sich abmeldet oder die Verbindung abbricht. Aus der Serveradministration ist dieses Prinzip lange bekannt.

Herdr verlegt den Fokus auf den Anwendungsfall KI-Entwicklung. Es bündelt langlebige Terminal-Sitzungen und macht sichtbar, welcher der laufenden Coding-Agenten gerade auf eine Eingabe wartet. Statt selbst herumzuklicken und nachzusehen, bekommen Entwicklerinnen und Entwickler einen Status: Hier ist etwas zu entscheiden, dort läuft es weiter. Das Werkzeug ist jung; die Linux-Distribution Omarchy hat es bereits integriert.

Der konzeptionelle Kern ist damit weniger technisch als organisatorisch. Herdr übernimmt keine Entscheidungen und bewertet keine Ergebnisse. Es sortiert lediglich die Warteschlange menschlicher Eingriffe — und macht damit aus einer unübersichtlichen Menge paralleler Prozesse eine abarbeitbare Liste.

Warum das mehr ist als Komfort

Ein Werkzeug, das anzeigt, wo ein Agent hängt, wirkt zunächst wie eine Bequemlichkeit. In der Praxis berührt es drei Punkte, die in Kundenprojekten regelmäßig relevant werden.

  • Nachvollziehbarkeit: Langlebige Sitzungen bedeuten, dass der Verlauf einer Agentenaufgabe erhalten bleibt. Was hat der Agent vorgeschlagen, welche Freigabe wurde erteilt, an welcher Stelle hat ein Mensch korrigiert? Ohne diesen Kontext lässt sich im Nachhinein schwer rekonstruieren, wie ein Stück Code entstanden ist.
  • Freigabepunkte: Wenn sichtbar ist, wo ein Agent auf eine Bestätigung wartet, wird der Freigabeschritt zu einem definierten Vorgang statt zu einem Nebenbei-Klick. Das ist die Voraussetzung dafür, Regeln zu setzen: Welche Änderungen darf ein Agent selbst schreiben, welche brauchen ein Review?
  • Kapazitätsplanung: Die Zahl der Agenten, die ein Team sinnvoll betreiben kann, richtet sich nach der menschlichen Prüfkapazität, nicht nach der verfügbaren Rechenleistung. Ein Statusüberblick macht diese Grenze überhaupt erst messbar.

Was die Meldung nicht hergibt

Bei einem so frühen Projekt ist Zurückhaltung angebracht. Zum Funktionsumfang im Detail, zur Stabilität, zur Frage, mit welchen Agenten-Werkzeugen Herdr zusammenarbeitet, und zur langfristigen Pflege des Projekts liegen keine belastbaren Angaben vor. Die Integration in eine einzelne Distribution ist ein Signal für Interesse aus der Community, aber noch keine Aussage über Produktionsreife.

Für die Bewertung im Unternehmenskontext ist das wichtiger als der Funktionsumfang selbst: Werkzeuge in diesem Umfeld entstehen derzeit schnell und verschwinden ebenso schnell. Wer sie in Entwicklungsprozesse einbindet, sollte das so tun, dass ein Austausch ohne Projektstillstand möglich bleibt.

Die Lehre liegt im Muster, nicht im Werkzeug

Unabhängig davon, ob sich genau dieses Projekt durchsetzt, zeigt es eine Entwicklungsrichtung. Die erste Welle von KI-Werkzeugen in der Softwareentwicklung war auf die Qualität der Ausgabe fokussiert: bessere Vorschläge, größerer Kontext, weniger Fehler. Die zweite Welle betrifft die Steuerung: Wie behält ein Team die Kontrolle, wenn mehrere halbautonome Prozesse gleichzeitig an einer Codebasis arbeiten?

Diese Fragen sind nicht neu. Sie ähneln denen, die bei Build-Pipelines, verteilten Systemen und Ticket-Workflows bereits beantwortet wurden: Status sichtbar machen, Zuständigkeiten festlegen, Zustände persistent halten, Eingriffe protokollieren. Der Unterschied ist, dass die beteiligten Prozesse jetzt Rückfragen stellen und damit aktiv menschliche Aufmerksamkeit einfordern.

Praktisch bedeutet das für Teams, die KI-gestützte Entwicklung einführen: Vor der Frage, wie viele Agenten parallel laufen können, steht die Frage, wer ihre Ergebnisse prüft und an welcher Stelle im Prozess das passiert. Ein Werkzeug, das Wartezustände sortiert, ersetzt diese Festlegung nicht — es macht aber sichtbar, ob sie realistisch ist.

Was das für Projekte bedeutet

Für Web- und Softwareprojekte verschiebt sich damit der Ort, an dem über Qualität entschieden wird: weg vom einzelnen Vorschlag eines Assistenten, hin zum Prozess, der diese Vorschläge einsammelt, prüft und freigibt. Wer KI-gestützte Entwicklung in Kundenprojekten einsetzt, sollte deshalb Freigabepunkte, Protokollierung und Prüfkapazität von Anfang an mitplanen und Werkzeuge dieser Art zunächst in klar abgegrenzten Bereichen erproben. Die Parallelität bringt nur dann Tempo, wenn die Nachvollziehbarkeit mitwächst.

Quellen