Am Anfang stehen ein Terminal und Claude Code. Dann kommt eine zweite Aufgabe dazu, also öffnest du ein zweites Terminal und startest Codex darin. Ein Frontend-Fix landet im dritten. Jetzt springst du mit Alt+Tab zwischen drei Fenstern hin und her und versuchst dich zu erinnern, welches auf dich wartet, welches vor zehn Minuten eine Frage gestellt hat und welches still und leise fertig geworden ist und jetzt untätig dasitzt, während du deine Aufmerksamkeit auf die anderen beiden verbrennst. Es brennt nirgendwo. Aber du bist zu der Instanz geworden, die Arbeit zwischen den Agents verteilt – und diese Rolle skaliert schlechter als jeder einzelne von ihnen.
Die Terminals sind nicht der Kostenfaktor. Du bist es. Wenn Agents per Hand laufen, lebt jede Entscheidung darüber, was als Nächstes passiert, an einem einzigen Ort: in deinem Kopf. Welcher Agent die nächste Aufgabe bekommt, ob der letzte Diff sicher ist, was fehlgeschlagen ist, während du in einem anderen Fenster gelesen hast. Diese Koordination ist echte Arbeit, sie ist unbezahlt, und sie wächst schneller als die Zahl der Agents, die du hinzufügst.
In diesem Artikel geht es darum, was das manuelle Betreiben von Coding-Agents tatsächlich kostet, wo sich die Rechnung versteckt, bis sie sich summiert, und um den Workflow, der das meiste davon beseitigt. Sharkly ist die Management-Ebene über deinen Agents: Du behältst Claude Code, Codex oder welche Runtime du auch immer nutzt, und Sharkly hält die Tasks, die Isolation und das Review an einem gemeinsamen Ort – statt sie über eine Wand voller Terminals zu verteilen.
TL;DR
Coding-Agents per Hand zu betreiben sieht kostenlos aus, weil kein Tool etwas dafür berechnet. Der eigentliche Preis ist deine Aufmerksamkeit: Du wirst zum Router zwischen den Agents, zum Gedächtnis dessen, was jeder gerade tut, und zum einzigen Reviewer, der bei jedem Fenster hinterherkommen muss. Bei zwei oder drei Agents bleibt dieser Aufwand klein und summiert sich ab fünf. Du kannst das weiter manuell machen oder deine bestehenden Agents über eine Aufgabenebene wie Sharkly leiten, die Arbeit zuweist, jeden Lauf isoliert und jedes Ergebnis zur Überprüfung an eine Task zurückgibt.
Die Terminals sind nicht das Problem – du bist es
Hier ist die Definition, die es sich zu behalten lohnt: Ein Terminal ist der Ort, an dem ein Agent läuft; eine Task ist die Arbeit, die er dort erledigt. Wenn du Agents per Hand verwaltest, verbindet die beiden nichts außer dir. Das Terminal zeigt Ausgaben. Es weiß nicht, was die Aufgabe war, ob sie erledigt ist oder wer entscheidet, was als Nächstes passiert. All das lieferst du aus dem Gedächtnis, ein Fenster nach dem anderen.
Deshalb ist „zu viele Terminals“ ein Symptom und nicht die Krankheit. Einen Agent mit tmux auf fünf Panes aufzuteilen reduziert die Koordination nicht; es ordnet sie nur. Du hältst trotzdem die Karte im Kopf: welcher Pane welche Aufgabe besitzt, welcher gerade läuft und welcher fertig ist und einen Menschen braucht, der nachsieht. Diese Karte liegt nirgends gemeinsam vor, also veraltet sie in dem Moment, in dem du weggehst, und in dem Moment, in dem ein Teammitglied sie braucht, existiert sie nicht.
Was das Betreiben von Agents per Hand wirklich kostet
Die Rechnung wird mit Aufmerksamkeit bezahlt, und Aufmerksamkeit hat einen messbaren Preis. Wenn du zwischen nicht zusammenhängenden Aufgaben wechselst, machst du nicht sofort dort weiter, wo du aufgehört hast. Die Forschung zu unterbrochener Wissensarbeit von Gloria Mark und Kollegen, veröffentlicht auf der CHI 2008, ergab, dass Menschen im Durchschnitt über zwanzig Minuten brauchen, um nach einer Unterbrechung zu ihrer Aufgabe zurückzukehren. Die Zusammenfassung der Forschung zum Aufgabenwechsel der American Psychological Association beziffert den Produktivitätsverlust durch das Wechseln zwischen Aufgaben auf bis zu 40 Prozent. Jedes Mal, wenn ein Agent fertig wird und du dich zu einem anderen Fenster drehst, zahlst du eine Variante dieser Steuer.
Agents per Hand zu betreiben macht diesen Wechsel zu deiner Hauptschleife. Hier sammeln sich die Kosten an:
| Versteckte Kosten | Wie es sich per Hand zeigt | Warum es sich summiert |
|---|---|---|
| Routing | Du entscheidest aus dem Gedächtnis, welcher Agent die nächste Aufgabe bekommt | Mehr Agents bedeuten mehr Paarungen, die du im Kopf behalten musst |
| Kontext neu laden | Du liest jedes Terminal neu, um dich zu erinnern, was es gerade tat | Jeder Wechsel startet die Uhr zum Wiedereinstieg in diese Aufgabe neu |
| State-Drift | Jedes Terminal bringt seinen eigenen Branch, seine Env und halbfertige Änderungen mit | Zwei Aufgaben im selben Verzeichnis beschädigen sich still und leise gegenseitig |
| Review-Rückstand | Du bist der Einzige, der jeden Lauf gesehen hat | Fertige Arbeit wartet auf die eine Person, die sie überprüfen kann |
| Kein gemeinsames Protokoll | Der Status lebt in deiner Session, nicht an einem Ort, den ein Teammitglied sehen kann | Gehst du weg, ist der Fortschritt unsichtbar; niemand kann ihn übernehmen |
Nichts davon zeigt sich als Absturz. Es zeigt sich als ein Tag, der sich beschäftigt angefühlt hat und drei gemergte PRs hervorgebracht hat statt acht – ohne einen einzigen Moment, den du als Problem benennen könntest.
Die Fehlerbilder bleiben verborgen, bis sie sich summieren
Bei zwei Agents kannst du die ganze Karte im Arbeitsgedächtnis halten, und die Kosten liegen nahe null. Das ist es wert, klar ausgesprochen zu werden, denn genau hier überverkaufen die meisten Ratschläge das Problem: Wenn du ein oder zwei Agents auf einer Maschine betreibst und jeden überprüfst, bevor du den nächsten startest, brauchst du noch keine Management-Ebene. Halte die beweglichen Teile bei null.
Die Gleichung ändert sich, wenn sich Arbeit zeitlich oder im State überschneidet. Betreibst du drei Agents im selben Checkout, triffst du auf das Isolationsproblem, das unter mehrere Coding-Agents im selben Repository behandelt wird: Zwei Agents berühren dieselben Dateien, und einer überschreibt den anderen still und leise. Behebe das mit einem Worktree pro Aufgabe – die Disziplin aus Coding-Agent-Worktrees – und du tauschst ein Merge-Problem gegen ein Buchhaltungsproblem: Welches Verzeichnis gehört zu welcher Aufgabe, welches kann man sicher löschen, bei welchem ist gerade ein Mensch mitten im Review. Löst du das mit mehr Terminals, bist du wieder am Anfang – nur mit mehr Fenstern.
Der letzte Kostenpunkt ist der leise. Wenn jeder Lauf in einem privaten Terminal stattfindet, hat fertige Arbeit keinen anderen Ort als deine Aufmerksamkeit. Review wird zum Engpass, weil du die einzige Person bist, die dem Agent bei der Arbeit zugesehen hat, und die einzige, die sagen kann, ob der Diff gut ist. Parallele Agents helfen nicht, wenn das Review ihrer Ergebnisse auf einen einzigen Menschen serialisiert wird. Das ist die Falle, die in warum der beste Coding-Agent weniger zählt als die Frage, wie du sie managst beschrieben wird: Das Modell wurde schneller, deine Review-Queue nicht.
Was die Management-Ebene beseitigt
Ein Task-Board beseitigt den Teil, den du bisher per Hand erledigt hast: das verbindende Gewebe zwischen Agents und Arbeit zu sein. In Sharkly ist die Task die Einheit, der ein Lauf gehört. Du weist einem Agent eine Task zu, und Sharkly bereitet dafür einen isolierten Worktree auf einem verbundenen Computer vor, führt dort die Agent-Session aus und gibt den Diff, die Logs und alle Blocker an diese Task zurück. Das Routing, die Isolation und das Protokoll, die du bisher im Kopf gehalten hast, werden stattdessen Eigenschaften der Task.
So bleibt die Arbeitsteilung sauber. Agents recherchieren, führen aus, testen und berichten; Menschen geben die Richtung vor, erteilen Befugnisse und nehmen das Ergebnis ab. Sharkly ist kein Ersatz für Claude Code, Codex oder die Runtime, die du bereits nutzt; diese übernehmen die Ausführung. Es ergänzt die gemeinsame Task, den verbundenen Computer und die Review-Ebene darum herum, sodass Kontext, Fortschritt, Blocker, Ergebnisse und menschliches Review von der Anfrage bis zum Release sichtbar bleiben, statt über fünf Sessions verstreut zu sein, die nur du sehen kannst. Wenn du mehrere Läufe gleichzeitig beobachten musst, dafür ist ein Agent-Dashboard tatsächlich gedacht, und deshalb wollen Teams irgendwann die Ebene über Claude Code und Codex statt noch ein Terminal.
Wenn du bereits mehrere Agents betreibst, ist das der Workflow, um den Sharkly herum gebaut ist. Du kannst weiterhin per Hand zwischen Terminals routen, oder du führst deine bestehenden Coding-Agents über Sharkly aus und lässt das Board die Karte halten.
Wann manuell in Ordnung ist – und wann nicht
Die ehrliche Entscheidungsregel ist kurz:
- Betreibe Agents per Hand, wenn du ein oder zwei hast, auf einer Maschine, und jeden überprüfst, bevor der nächste startet. Der Overhead eines Tools lohnt sich hier noch nicht.
- Wechsle zu einer Aufgabenebene, wenn ein dritter Agent dazukommt, sich die Arbeit über mehr als ein Repository erstreckt oder jemand anderes als du sehen muss, was gerade läuft. Das ist der Punkt, an dem der Koordinationsaufwand nicht mehr in einen einzigen Kopf passt.
Das Signal ist nicht die Anzahl der Terminals. Es ist der Moment, in dem du dich dabei ertappst, wie du fragst: „Moment, in welchem Fenster war das noch mal?“ Diese Frage ist die Koordinationssteuer, die sich als Satz zeigt – und es ist dasselbe Agent-Chaos, das ein Task-Board beenden soll.
FAQ
Reicht tmux oder ein Terminal-Multiplexer nicht aus? Er ordnet die Fenster; er beseitigt die Koordination nicht. Du hältst trotzdem fest, welcher Pane welche Aufgabe besitzt, was fertig ist und wer es überprüft. Ein Multiplexer löst das Problem des Bildschirmplatzes. Die Kosten des manuellen Betreibens von Agents sind Aufmerksamkeit, nicht Pixel.
Wie viele Agents kann ich per Hand betreiben, bevor es wehtut? Die meisten kommen mit einem oder zwei gut zurecht und spüren es ab etwa drei bis fünf, besonders über mehr als ein Repository hinweg. Die genaue Zahl hängt davon ab, wie lange jede Aufgabe läuft und wie viel Review sie braucht. Der Hinweis ist, wenn Routing und das erneute Lesen von Fenstern mehr von deinem Tag fressen als das eigentliche Review.
Macht ein Task-Board meine Agents schneller? Nein, und Sharkly behauptet das auch nicht. Die Agents laufen gleich schnell. Was sich ändert, ist dein Overhead: Routing, Isolation und Review leben nicht mehr in deinem Kopf, sondern kehren zu einer Task zurück, wo die Arbeit sichtbar und überprüfbar ist.
Was ist mit dem Erhalt des Kontexts über Sessions hinweg? Private Terminals verlieren ihn in dem Moment, in dem du sie schließt. Einen Lauf an eine Task zu binden hält das Ziel, den Diff und die Diskussion zusammen – das ist das Kontext über Sessions hinweg bewahren-Problem, gelöst auf der Ebene des Protokolls statt durch Erinnerung.
Kann ich Claude Code und Codex trotzdem zusammen nutzen? Ja. Sharkly verwaltet die Arbeit rund um die Tools; es ersetzt sie nicht. Siehe wie man Claude Code und Codex zusammen ausführt für das Muster.
