Das Ende von lokal

5 Min. Lesezeit

Auch verfügbar auf English, Español, Português, 简体中文, 日本語, 한국어, Français, ไทย, Tiếng Việt und Te Reo Māori.

Der Standardort, an dem heute ein Coding-Agent läuft, ist innerhalb Ihres Editors. Cursor, Claude Code, der Assistent in Ihrer IDE – sie sitzen neben Ihnen, Sie beobachten ihre Arbeit, Sie genehmigen jeden Schritt. Das fühlt sich natürlich an, weil es Pair Programming nachbildet: ein sehr schneller Junior-Entwickler an Ihrer Schulter, während Sie die Hand am Steuer behalten.

Dieses Modell passt hervorragend zu einem Agenten, der ständige Aufsicht braucht. Das Problem ist, dass Agenten von Monat zu Monat weniger Aufsicht benötigen – und je autonomer sie werden, desto seltsamer wirkt es, sie an einen einzelnen Laptop zu binden, der nur wach ist, wenn Sie es sind.

Die Grenzen von lokal

Ein lokaler Agent erbt all Ihre Einschränkungen. Er läuft, solange Ihr Rechner eingeschaltet ist, und stoppt, sobald Sie ihn zuklappen. Er konkurriert mit Ihrem Editor, Ihrem Browser und Ihrem Build um dieselbe CPU und denselben Arbeitsspeicher. Er arbeitet an einer Sache zur Zeit, weil auch Sie immer nur eine Sache im Blick haben können. Und alles, was er tut, geschieht an einem Ort, den nur Sie sehen können.

Nichts davon ist ein Mangel der Werkzeuge – es ist schlicht die Logik von „lokal". Der Agent lebt dort, wo Sie leben, und ist daher durch alles begrenzt, was auch Sie begrenzt: Ihre Arbeitszeiten, Ihre Hardware, Ihre Aufmerksamkeit, Ihr einziges Augenpaar. Solange der Agent bei jedem Schritt einen wachsamen Menschen brauchte, waren diese Grenzen kostenlos. Sobald er das nicht mehr tut, sind sie reine Kosten.

Die asynchrone, entfernte Alternative

Das andere Modell ist jenes, um das herum wir TaskGoblin gebaut haben: Der Agent lebt überhaupt nicht in Ihrem Editor. Er lebt auf dedizierter Infrastruktur und erreicht Sie über die Werkzeuge, die Ihr Team bereits nutzt – ein Linear-Issue, ein GitLab- oder GitHub-Merge-Request, ein Slack-Thread. Sie übergeben ihm Arbeit, so wie Sie sie einem entfernten Kollegen in einer anderen Zeitzone übergeben würden, und er erledigt sie in einer Cloud-Sandbox, während Sie sich anderen Dingen widmen.

Die Verschiebung klingt nach einer Frage, wo die Rechenleistung läuft. Tatsächlich geht es darum, was dem Agenten überhaupt erlaubt ist zu sein. Nehmen Sie ihn vom Laptop, und die Einschränkungen von „lokal" fallen eine nach der anderen weg:

  • Er läuft parallel. Zehn Issues können gleichzeitig bearbeitet werden, weil kein Mensch jedes einzelne beaufsichtigen muss.
  • Er ist immer aktiv. Ein entfernter Agent stoppt nicht, wenn Sie Ihren Laptop zuklappen; um 18 Uhr zugewiesene Arbeit ist am Morgen erledigt. Die verfügbaren Agenten-Stunden pro Tag sind nicht länger an Ihre Arbeitszeiten gebunden.
  • Er läuft auf Infrastruktur, die für ihn gebaut wurde, statt auf einem Entwickler-Laptop mit Ihrem Editor um Ressourcen zu konkurrieren.
  • Er arbeitet dort, wo das Team ihn sehen kann. Das Ergebnis ist ein Merge-Request mit Kommentarverlauf, keine private Sitzung – Aufsicht wird zu etwas, das das gesamte Team gemeinsam in geteilten Räumen ausübt.
  • Er ist nativ in die Plattform integriert. Er wird durch Ereignisse ausgelöst, die bereits durch Ihre Werkzeuge fließen – eine Zuweisung, eine Erwähnung, ein neuer Pull-Request – statt dadurch, dass Sie eine App öffnen.
  • Er ist von Grund auf isoliert. Jeder Lauf ist eine frische, sandboxed Umgebung mit begrenzten, vermittelten Zugangsdaten, die der Agent nie selbst besitzt – eine Sicherheitshaltung, die ein Prozess auf Ihrer eigenen Maschine nicht erreichen kann.

Keiner dieser Vorteile ist für sich genommen spektakulär. Zusammen summieren sie sich jedoch zu einem Vorsprung, der sich kaum bestreiten lässt: zehn Agenten, die rund um die Uhr arbeiten, gegen einen, der stoppt, wenn Sie stoppen.

„Aber ich brauche die enge Feedback-Schleife"

Der stärkste Einwand gegen Remote ist die enge Schleife: der schnelle Austausch beim Beobachten eines Agenten, das Korrigieren mitten im Prozess, das Steuern nach Gefühl. Das ist real, und für genuin explorative Arbeit – eine Idee ausprobieren, etwas debuggen, das Sie selbst noch nicht verstehen – ist lokal nach wie vor das richtige Werkzeug.

Aber zwei Dinge stimmen in Bezug auf diese Schleife. Sie macht einen kleineren Anteil der Arbeit aus, als es sich anfühlt; ein großer Teil echter Ingenieursarbeit besteht aus gut spezifizierten Aufgaben, die keinen darüber wachenden Menschen brauchen. Und sie schrumpft jedes Mal, wenn die Agenten besser werden, denn der Grund, warum Sie wachen, ist, dass Sie dem Agenten noch nicht zutrauen, unbeaufsichtigt fertig zu werden – und genau dieses Vertrauen wächst gerade. Die enge Schleife verschwindet nicht, aber sie wird einen immer kleineren Teil des Tages beschreiben.

„Aber die Sicherheit"

Der ernsthafteste Einwand betrifft nicht den Workflow, sondern das Vertrauen: Ihren Code und Ihre Zugangsdaten auf der Infrastruktur eines anderen abzulegen. Das verdient eine echte Antwort statt einer wegwischenden Handbewegung, und es ist ein großer Teil dessen, was wir bauen. Läufe sind pro Sandbox isoliert; Geheimnisse werden im Ruhezustand verschlüsselt und niemals in die Umgebung des Agenten gelegt; die Daten jeder Organisation sind strikt von denen jeder anderen getrennt. Remote bedeutet nicht sorglos – richtig gemacht, ist eine zweckgebaute Sandbox mit vermittelten Zugangsdaten defensibler als ein Agent, der frei auf dem Laptop eines Entwicklers läuft, mit den echten Tokens in seiner Umgebung.

Wohin das führt

Wir behaupten nicht, dass lokal verschwindet. Explorative Arbeit und manche Compliance-beschränkten Umgebungen werden noch lange einen Platz für einen Agenten im Editor bewahren. Unsere Behauptung ist enger gefasst und, wie wir meinen, schwerer zu umgehen: Sobald Agenten in der Lage sind, echte Arbeit ohne einen beobachtenden Menschen zu erledigen, verschiebt sich der Schwerpunkt vom Laptop hin zu geteilter, stets aktiver Infrastruktur – nicht weil Entwickler das bevorzugen, sondern weil ein Team, das zehn Agenten rund um die Uhr laufen lässt, ein Team, das nur einen laufen lässt, bis es den Deckel schließt, schlicht überflügeln wird.

Das ist die Wette, auf der TaskGoblin aufbaut. Kein besseres Fenster zu einem Agenten auf Ihrer Maschine, sondern ein Agent, der nie auf Ihrer Maschine war – wartend in den Werkzeugen, die Ihr Team bereits nutzt, bereit, bevor Sie Ihren Kaffee ausgetrunken haben.