Parallele KI-Agenten mit Git

Parallele KI-Agenten mit Git

0:00 Ein Agent, der für Sie arbeitet, ist praktisch. Zwei Agenten, die gleichzeitig für Sie arbeiten, klingen doppelt so praktisch — sind es aber nur, wenn sie sich nicht in die Quere kommen. Und genau das tun sie, sobald sie im selben Ordner sitzen. Sie ändern dieselben Dateien, sie wissen nichts voneinander, und am Ende steht ein Zustand, den niemand mehr auseinandersortieren kann.

0:21 In diesem Modul lernen Sie eine Git-Funktion kennen, die dieses Problem elegant löst und die die meisten Entwicklerinnen und Entwickler noch nie benutzt haben, obwohl es sie seit Jahren gibt: Worktrees.

Mehrere Agenten, ein Repository

0:33 Wir gehen in vier Schritten vor. Zuerst klären wir, wofür sich Parallelbetrieb überhaupt lohnt — denn nicht jede Aufgabe eignet sich dafür. Dann lernen wir Worktrees kennen, mit ihren drei Befehlen. Anschließend bereiten wir zwei Features vor und sagen die Konflikte voraus, die entstehen werden. Und zum Schluss führen wir beides zusammen. Dieser letzte Teil ist der ehrlichste: Paralleles Arbeiten endet nicht mit dem generierten Code, sondern erst beim Merge.

1:00 Vier Dinge nehmen Sie mit. Sie beurteilen, wann sich mehrere Agenten gleichzeitig wirklich lohnen — es gibt Aufgaben, bei denen der Koordinationsaufwand den Gewinn auffrisst. Sie legen Worktrees an, listen sie auf und räumen sie wieder ab. Sie lassen zwei Features isoliert bauen, ohne dass sie sich überschreiben. Und Sie führen die entstandenen Zweige kontrolliert zusammen. Das Wort "kontrolliert" ist dabei entscheidend: Wir werden die Konflikte nicht vermeiden, sondern vorhersagen.

1:29 Das ist realistischer und am Ende deutlich beruhigender.

Warum mehrere Agenten gleichzeitig

1:33 Bevor wir uns das Werkzeug ansehen, die Frage nach dem Nutzen: Wann lohnt es sich überhaupt, zwei Agenten gleichzeitig laufen zu lassen? Und was passiert, wenn man es ohne Vorbereitung tut? Mehrere Agenten parallel zu betreiben, heißt: mehrere unabhängige Änderungslinien gleichzeitig verfolgen. Für uns Menschen ist das anstrengend — wer schon einmal mitten in einem Feature zu einem Fehler gewechselt ist, kennt die Kosten dieses Kontextwechsels.

2:00 Ein Agent hat dieses Problem nicht. Er hält beliebig viele Fäden, ohne den Überblick zu verlieren. Der Engpass liegt deshalb woanders, und das ist die zentrale Einsicht dieses Moduls: Nicht das Denken ist begrenzt, sondern das Dateisystem. Zwei Agenten im selben Verzeichnis teilen sich einen Arbeitsplatz, und darüber stolpern sie.

2:20 Vier Szenarien, die sich in der Praxis bewährt haben. Zwei fachlich getrennte Features gleichzeitig — der naheliegende Fall. Denselben Prompt an zwei Modelle geben und vergleichen, was herauskommt; überraschend lehrreich, wenn man ein neues Modell bewertet. Ein Agent am Frontend, einer am Backend desselben Features — das funktioniert erstaunlich gut, weil die Schnittstelle vorher feststeht.

2:43 Und der Alltagsfall: zwischen Feature-Arbeit und einer Fehlersuche wechseln, ohne den Arbeitsstand umzuschalten. Gerade der letzte spart mehr Zeit, als man erwartet, weil das Umschalten selbst die eigentliche Bremse ist. Und jetzt die Kehrseite. Zwei Agenten, die dieselbe Datei ändern, überschreiben sich gegenseitig — ohne Warnung, denn beide arbeiten ja korrekt.

3:05 Schlimmer ist der zweite Punkt: Ein Agent kennt die Funktion nicht, die der andere gerade gebaut hat, und implementiert sie ein zweites Mal, nur leicht anders. Dazu kommen Abhängigkeiten, die parallel ergänzt oder hochgezogen werden. Das Ergebnis ist selten ein klarer Fehler. Es ist ein Zustand, in dem alles irgendwie funktioniert und niemand mehr sagen kann, welcher Teil von wem stammt. Genau deshalb ist Isolation keine Kür.

3:31 Die drei oberen Zeilen kennen Sie vermutlich, und ich gebe zu: Das Klonen war lange auch meine Lösung. Es funktioniert, aber es ist langsam und belegt für jede Kopie die vollständige Historie auf der Platte. Der Unterordner im Projekt ist noch unangenehmer, weil Sie dabei die Struktur Ihres Projekts verbiegen, nur um Agenten zu beruhigen — und vergleichen müssen Sie am Ende trotzdem von Hand.

3:54 Bleibt die dritte Zeile, die eigentlich keine Lösung ist, sondern Hoffnung. Die vierte Zeile ist das Thema dieses Moduls: ein Repository, mehrere Arbeitsverzeichnisse. Suchen Sie zwei Aufgaben aus Ihrem eigenen Backlog, die sich unabhängig umsetzen lassen — und notieren Sie dann, welche Dateien beide berühren würden. Dieser zweite Teil ist der eigentliche Wert der Übung.

4:15 Wenn Sie feststellen, dass beide Aufgaben zu achtzig Prozent dieselben Dateien anfassen, haben Sie gerade eine Menge Ärger vermieden: Diese beiden gehören nicht parallel bearbeitet, sondern nacheinander. Und wenn die Schnittmenge klein ist, haben Sie schon die Liste der Konfliktstellen, die wir später brauchen.

Git-Worktrees verstehen

4:33 Kommen wir zu der Funktion, um die es geht. Sie ist seit über zehn Jahren in Git enthalten, sie taucht in kaum einem Tutorial auf, und sie löst unser Problem fast beiläufig. Ein Worktree ist ein zusätzliches Arbeitsverzeichnis desselben Repositories mit einem eigenen ausgecheckten Branch. Stellen Sie sich eine Bibliothek vor: Es gibt einen Katalog und einen Bestand — das ist Ihr Repository.

4:57 Und es gibt mehrere Lesetische, an denen unterschiedliche Leute mit unterschiedlichen Büchern sitzen. Niemand käme auf die Idee, für jeden Tisch eine eigene Bibliothek zu bauen. Genau das aber tut ein zweiter Klon. Der Worktree ist der zusätzliche Lesetisch: eigene Dateien, gemeinsamer Bestand. Im neuen Ordner liegt deshalb auch kein eigener Git-Speicher — die Verwaltung bleibt zentral.

5:21 Der offensichtliche Gewinn ist der Platz: keine zweite Kopie der Historie, kein erneutes Herunterladen. Bei großen Repositories ist das der Unterschied zwischen Sekunden und Minuten. Der zweite Vorteil ist konzeptioneller — jeder Agent bekommt ein eigenes Verzeichnis, statt dass Sie Ihr Projekt in Agenten-Unterordner zerlegen.

5:40 Ihre Projektstruktur bleibt, wie sie ist. Dazu kommt ein Nebeneffekt, den man erst im Alltag schätzt: Sie können in einem Worktree einen anderen Branch auschecken, ohne Ihren Hauptarbeitsstand anzufassen. Kein Stashen mehr, kein "Moment, ich muss erst aufräumen". Der Lebenszyklus ist kurz. Sie legen einen Ordner neben dem Projekt an — nicht darin, das ist wichtig, sonst versionieren Sie ihn versehentlich mit.

6:05 Dann erzeugen Sie den Worktree, wahlweise mit einem neuen Branch. Dann wechseln Sie hinein und installieren die Abhängigkeiten; das vergessen fast alle beim ersten Mal, denn im neuen Verzeichnis liegt nur, was unter Versionskontrolle steht. Zwischendurch verschaffen Sie sich mit einer Liste Überblick. Und nach dem Merge räumen Sie den Worktree wieder ab. Merken Sie sich dabei: Entfernt wird der Pfad, nicht der Branch.

6:29 Das sind zwei verschiedene Dinge. Drei Befehle, mehr braucht es nicht. Worauf es ankommt, ist der Unterschied zwischen den ersten beiden Aufrufen. Mit dem Flag b legen Sie gleichzeitig einen neuen Branch an — das ist der Fall, wenn ein Agent an etwas Neuem arbeiten soll. Ohne das Flag checken Sie einen bestehenden Branch aus, etwa um ein fremdes Feature zu prüfen.

6:51 Und eine Eigenheit, über die jeder einmal stolpert: Denselben Branch können Sie nicht in zwei Worktrees gleichzeitig auschecken. Git verweigert das — zu Recht, denn was sollte auch dabei herauskommen. Legen Sie einen Worktree an und weisen Sie nach, dass es kein zweiter Klon ist. Der Beweis ist simpel: Im neuen Ordner liegt kein eigener Git-Speicher, und die Liste zeigt trotzdem beide Verzeichnisse mit ihren jeweiligen Branches.

7:17 Der Hinweis ist der praktisch wichtigste Teil der Übung — im frischen Worktree fehlen alle Dateien, die nicht versioniert sind. Abhängigkeiten, lokale Konfiguration, Umgebungsvariablen. Wer das überspringt, wundert sich, warum der Agent im neuen Verzeichnis plötzlich nichts mehr bauen kann. Vier typische Stolperfallen. Denselben Branch zweimal auschecken wollen — Git sagt Nein, und das ist keine Schikane.

7:41 Den Worktree-Ordner von Hand löschen: Dann bleibt der Eintrag in der Verwaltung zurück und zeigt ins Leere; dafür gibt es den remove-Befehl. Die Abhängigkeiten vergessen, wie eben besprochen. Und der vierte, der schnell peinlich wird: Worktrees innerhalb des Projektordners anlegen. Beim nächsten Commit landet dann eine komplette Kopie Ihres Projekts im Repository. Legen Sie den Ordner daneben, dann kann das nicht passieren.

Zwei Features vorbereiten

8:07 Jetzt wird es praktisch. Zwei Features sollen parallel entstehen, und bevor der erste Agent startet, tun wir etwas, das sich später auszahlt: Wir sagen voraus, wo es krachen wird. Vorbereitung heißt hier zweierlei. Das Technische ist schnell erledigt: für jedes Feature ein eigener Worktree mit eigenem Branch. Das Interessantere ist das andere — vorab zu benennen, welche Dateien beide Features anfassen werden.

8:32 Das ist wie beim Umbau einer Wohnung: Wenn zwei Gewerke gleichzeitig arbeiten, klärt man vorher, wer wann an die Elektrik muss. Man verhindert damit nicht jede Überschneidung, aber man wird von keiner überrascht. Und Überraschung ist beim Zusammenführen die teuerste Zutat. Zwei Features für unsere Produkt-API: Bewertungen mit Sternewertung und Text, und Kategorien mit neuen Endpunkten.

8:56 Fachlich haben die nichts miteinander zu tun — die eine Funktion interessiert sich für Meinungen, die andere für Ordnung. Und genau deshalb sind sie ein gutes Beispiel. Fachliche Unabhängigkeit bedeutet nämlich nicht technische Unabhängigkeit. Beide hängen am selben Artikel, beide erweitern dasselbe Datenmodell, beide brauchen Beispieldaten.

9:16 Diese Diskrepanz ist der Normalfall in jedem gewachsenen Projekt — und der Grund, warum Konflikte auch bei sauberem Zuschnitt auftreten. Vier Vorhersagen, alle vor dem ersten Prompt getroffen. Beide Features erweitern das Datenmodell am Artikel. Beide füllen dieselbe Datei mit Beispieldaten. Beide ergänzen gemeinsame Typdefinitionen. Und in der Startroutine hängt die Reihenfolge der Aufrufe von beiden ab.

9:41 Vier Vorhersagen, die Sie später mit den tatsächlichen Konflikten vergleichen können — und meine Erfahrung ist, dass drei davon eintreffen und einer nicht. Das ist kein schlechtes Ergebnis. Es bedeutet, dass Sie beim Zusammenführen wissen, was auf Sie zukommt, statt sich durch Meldungen zu arbeiten. Die Vorbereitung in vier Zeilen. Worauf es ankommt, steht in der ersten: der Statusabgleich.

10:06 Starten Sie den Parallelbetrieb nie mit einem unsauberen Arbeitsverzeichnis — nicht committete Änderungen im Hauptordner sind später kaum noch zuzuordnen. Danach zwei Worktrees, jeder mit eigenem Branch, jeder in einem eigenen Verzeichnis neben dem Projekt. Und ein Tipp aus der Praxis: Vergeben Sie die Branchnamen selbst.

10:25 Wenn Sie den Agenten wählen lassen, suchen Sie hinterher in der Liste nach etwas, das Sie noch nie gesehen haben. Die Übung ist ungewöhnlich, weil sie vor der eigentlichen Arbeit stattfindet: Schreiben Sie auf, welche Dateien beide Features ändern werden — bevor ein Agent startet. Nach dem Merge vergleichen Sie Ihre Liste mit den tatsächlichen Konflikten. Erfolgreich ist die Übung, wenn die beiden Listen weitgehend übereinstimmen.

10:50 Falls nicht, ist auch das lehrreich: Sie wissen dann, welchen Teil Ihres Projekts Sie schlechter kennen, als Sie dachten. Die üblichen Verdächtigen nenne ich im Hinweis — Datenmodell, Beispieldaten, gemeinsame Typen. Vier Punkte für die Vorbereitung. Mit unsauberem Arbeitsverzeichnis starten — schon erwähnt, aber es ist wirklich der häufigste.

11:11 Beide Agenten auf denselben Branch zeigen lassen; dann können Sie sich die Worktrees auch sparen. Features zuschneiden, die sich fast vollständig überlappen — dann ist sequenzielles Arbeiten schneller, und das ist kein Rückschritt, sondern eine Entscheidung. Und den Branchnamen dem Agenten überlassen, was das spätere Zusammenführen zur Suchaufgabe macht.

Parallel bauen und zusammenführen

11:32 Beide Agenten haben geliefert. Jetzt kommt der Teil, der in Demos gern weggelassen wird: das Zusammenführen. Denn erst hier entscheidet sich, ob der Parallelbetrieb tatsächlich Zeit gespart hat. Der Parallelbetrieb endet nicht mit dem generierten Code. Jeder Agent hat in seinem Worktree auf seinem Branch gearbeitet, und diese beiden Linien müssen wieder zusammenfinden.

11:55 Das geschieht im Hauptverzeichnis: ein Integrationsbranch, dann werden die beiden Feature-Branches nacheinander hineingemergt. Das Wort "nacheinander" ist keine Nebensache. Der erste Merge läuft in aller Regel glatt, weil er auf einen unveränderten Stand trifft. Der zweite bringt genau die Überschneidungen ans Licht, die wir vorhergesagt haben.

12:15 Das ist der Moment, in dem sich die Vorbereitung auszahlt. Fünf Schritte, und der zweite ist der, den ich am meisten empfehle: einmal nachsehen, wo der Worktree tatsächlich gelandet ist. Manche Agenten legen ihn selbst an, wenn man die Isolation entsprechend einstellt, und nicht immer dort, wo Sie es vermuten. Danach starten Sie die zweite Sitzung für das zweite Feature — die beiden laufen ab jetzt wirklich gleichzeitig.

12:40 Im Hauptverzeichnis legen Sie dann den Integrationsbranch an und mergen. Der letzte Schritt klingt banal und wird trotzdem oft übersprungen: die Anwendung starten und nachsehen, ob beide Features funktionieren. Sechs Zeilen für das Finale. Worauf es ankommt, ist die Reihenfolge der beiden Merges und die Ruhe dazwischen. Sehen Sie sich nach dem ersten Merge den Status an, bevor Sie den zweiten starten — Sie wollen wissen, auf welchem Fundament der zweite Merge aufsetzt.

13:08 Die Konflikte danach sind Handarbeit, und sie brauchen Aufmerksamkeit statt Geschwindigkeit. Besonders bei Beispieldaten: Dort ist die Versuchung groß, einfach eine Seite zu nehmen. Damit verlieren Sie aber die Datensätze des anderen Features, und das fällt erst auf, wenn ein Endpunkt leer bleibt. Vier Fallen im Endspurt. Beide Branches gleichzeitig mergen wollen — Git kann das zwar, aber Sie verlieren die Möglichkeit, den ersten Merge als Ausgangspunkt zu prüfen.

13:35 Bei Beispieldaten eine Seite verwerfen, wie gerade beschrieben. Nach dem Merge nicht starten und den Fehler dem Review überlassen; das ist die teuerste Variante, weil dann jemand anderes ihn findet. Und der letzte Punkt ist reine Hygiene: Worktrees stehen lassen. Sie zeigen bald auf Branches, die es nicht mehr gibt, und irritieren beim nächsten Blick in die Liste.

13:57 Die Abschlussübung führt alles zusammen: zwei unabhängig generierte Änderungslinien zu einem lauffähigen Stand. Der Erfolgstest ist bewusst nicht "der Merge lief durch", sondern: Die Anwendung startet und beide neuen Endpunkte liefern die erwarteten Daten. Ein Merge ohne Konflikte ist nämlich kein Beweis für Funktionsfähigkeit — er beweist nur, dass Git keine widersprüchlichen Zeilen gefunden hat.

14:20 Und ganz zum Schluss: Worktrees abräumen und die Liste gegenprüfen. Ein Repository, in dem drei verwaiste Arbeitsverzeichnisse herumstehen, ist genau die Unordnung, die wir vermeiden wollten.

Modul 3 geschafft

14:32 Halten wir fest: Worktrees geben jedem Agenten ein eigenes Verzeichnis, ohne dass Sie das Repository ein zweites Mal klonen. Drei Befehle decken den gesamten Lebenszyklus ab — anlegen, auflisten, entfernen. Und Konflikte lassen sich vorhersagen, wenn man vor dem ersten Prompt zwei Minuten investiert; sie werden dadurch nicht weniger, aber sie überraschen niemanden mehr.

14:54 Damit haben wir viel Code erzeugt, und zwar schnell. Bleibt die Frage, ob er auch gut ist. Im nächsten Modul ziehen wir die Qualitätsprüfung dorthin, wo sie am billigsten ist: vor den Commit.