Mehrere Agenten parallel

Ein Coding-Agent braucht für eine ordentliche Aufgabe zehn bis dreißig Minuten. In dieser Zeit sitzt du daneben. Der naheliegende Gedanke: einen zweiten starten. Das funktioniert – unter Bedingungen.

Das Problem: ein Ordner, zwei Autoren

Zwei Agenten im selben Projektordner arbeiten auf denselben Dateien. Der eine ändert eine Funktion, der andere liest die alte Fassung und überschreibt sie. Keiner von beiden merkt es. Dazu kommt der Branch: Ein Ordner hat immer nur einen aktiven Branch, und wechselt ein Agent ihn, steht der andere plötzlich in fremdem Code.

Die Lösung: Worktrees

Ein Worktree ist ein zweiter Arbeitsordner desselben Repositories, auf einem eigenen Branch. Beide Ordner teilen sich die Geschichte, aber nicht die Dateien.

git worktree add ../shop-suche -b suche-tippfehler
git worktree add ../shop-export -b export-csv
git worktree list
git worktree remove ../shop-suche

Die erste Zeile legt neben deinem Projekt den Ordner shop-suche an, auf dem neuen Branch suche-tippfehler. Dort startest du den ersten Agenten, im zweiten Ordner den zweiten. Jeder Branch wird zu einem eigenen Pull Request. Viele Agenten-Werkzeuge legen Worktrees inzwischen auf Wunsch selbst an – das Prinzip dahinter ist dieses.

Was sich parallelisieren lässt

Zwei Bedingungen, beide müssen stimmen:

Keine gemeinsamen Dateien. Ändern zwei Aufgaben dieselbe Datei, bekommst du beim Zusammenführen einen Konflikt – und der kostet mehr Zeit, als die Parallelität gespart hat.

Keine Abhängigkeit. Braucht Aufgabe B das Ergebnis von Aufgabe A, laufen sie nacheinander.

Gute Kandidaten: zwei unabhängige Fehler in verschiedenen Bereichen, Tests für ein Modul und Dokumentation für ein anderes, eine Recherche neben einer Umsetzung.

Die Regel dahinter: Je Satz von Dateien ein Schreiber. Agenten, die nur lesen – suchen, analysieren, prüfen –, können sich einen Ordner teilen.

Subagenten: Arbeit abgeben, Kontext sparen

Eine zweite Form der Parallelität steckt in den Agenten selbst. Ein Hauptagent kann Teilaufgaben an Subagenten abgeben: „Such alle Stellen, an denen diese Funktion aufgerufen wird.“ Der Subagent liest vierzig Dateien, der Hauptagent bekommt nur die Zusammenfassung.

Der Gewinn ist nicht nur Zeit, sondern Kontext: Die vierzig Dateien belegen das Arbeitsgedächtnis des Subagenten, nicht das des Hauptagenten. Der Preis sind zwei Übergaben, bei denen Details verloren gehen – der Subagent weiß nur, was im Auftrag stand, und der Hauptagent nur, was in der Zusammenfassung steht. Dazu kommen die Kosten: Jeder Subagent verbraucht eigenes Kontingent.

Sinnvoll sind Subagenten für breite Suchen und unabhängige Teilprüfungen. Nicht sinnvoll für alles, was der Hauptagent in drei Schritten selbst erledigt.

Der zweite Agent als Prüfer

Die nützlichste Parallelität ist oft keine gleichzeitige: Ein Agent schreibt, ein anderer mit frischem Kontext prüft. Der Prüfer hat die Entstehung nicht miterlebt und ist deshalb nicht auf die Lösung des ersten festgelegt.

Entscheidend ist, was du ihm gibst: den Auftrag und den Diff – nicht die Erklärung des ersten Agenten. Ein Prüfer, dem man die Schlussfolgerung mitliefert, bestätigt sie meistens.

Der eigentliche Engpass

Agenten erzeugen schneller, als du prüfen kannst. Drei parallele Agenten bedeuten drei Pull Requests, die gelesen werden wollen. Wer mehr startet, als er prüfen kann, sammelt ungelesene Änderungen – und gibt irgendwann eine davon frei, weil der Stapel drückt.

Deshalb die Obergrenze: so viele Agenten, wie du Ergebnisse gründlich prüfen kannst. Für die meisten sind das zwei, an guten Tagen drei. Was darüber hinaus Tempo bringt, sind keine weiteren Agenten, sondern kleinere Aufgaben und Abnahmetests, die dir einen Teil der Prüfung abnehmen.

Wie du misst, ob ein Agent überhaupt gute Arbeit liefert, ist der Einstieg in den letzten Pfad: Agenten im Betrieb.