Wenn du das erste Mal mehr als einen Coding-Agenten auf ein echtes Repository loslässt, verfliegt die Begeisterung schnell.
Ein Agent arbeitet an einem Bugfix. Ein anderer erkundet ein Refactoring. Ein dritter versucht, Tests hinzuzufügen. Vielleicht wartet einer auf eine Eingabe, ein anderer hat Änderungen produziert, und wieder ein anderer hat einen Branch erstellt, der bereits mit etwas anderem in Konflikt steht.
An diesem Punkt ist das Problem nicht mehr die Code-Generierung.
Das Problem ist die Kontrolle.
Genau deshalb ist die GitKraken Desktop Agent Sessions View interessant. Sie ist nicht nur ein weiteres KI-Feature. Sie ist ein Eingeständnis, dass agentische Entwicklung ein neues Workflow-Problem schafft: Entwickler brauchen jetzt eine Möglichkeit, mehrere parallele Coding-Vorhaben zu überwachen, ohne den Überblick über Branches, Worktrees, lokale Änderungen und Review-Status zu verlieren.
Warum Worktrees plötzlich wichtiger werden
Git Worktrees gibt es schon lange, aber KI-Coding-Agenten machen sie deutlich relevanter.
Ein Worktree erlaubt es dir, mehr als einen Branch aus demselben Repository gleichzeitig auszuchecken. Statt ständig zu stashen, Branches zu wechseln und zu hoffen, dass du nichts überschrieben hast, kannst du separate Arbeitsverzeichnisse für separate Arbeitsstränge haben.
Für rein menschliche Entwicklung ist das bereits nützlich.
Für agentische Entwicklung wird es geradezu unverzichtbar.
Wenn ein Agent einen API-Endpoint ändert, ein anderer Tests schreibt und ein dritter mit einem Refactoring experimentiert, will ich nicht, dass sie alle dasselbe Arbeitsverzeichnis anfassen. Ich will Isolation.
Aber Isolation schafft Sichtbarkeitsprobleme.
Wo ist welcher Branch? Welcher Worktree hat uncommittete Änderungen? Welche Session wartet? Welcher Branch hat einen PR? Welchen kann ich gefahrlos löschen?
Genau diese Lücke versucht die Agent Sessions View zu schließen.
Das Feature, wie ich es einem Team erklären würde
Die Agent Sessions View verwandelt Worktrees und Coding-Agent-Sessions in ein Dashboard.
Statt in Ordnern auf der Festplatte zu denken, bekommst du eine Ansicht im linken Panel, in der jeder Worktree als Karte dargestellt wird. Diese Karten zeigen den Branch, uncommittete Änderungen, den Ahead/Behind-Status und zugehörige Pull Requests. Bei Claude-Code-Sessions kann die Karte außerdem anzeigen, ob der Agent gerade arbeitet, auf eine Eingabe wartet oder sich in einem Fehlerzustand befindet.
Das ist die richtige Abstraktion.
Wenn ich Agenten überwache, will ich nicht damit anfangen, durch Ordner zu browsen. Ich will operative Fragen beantworten:
- Was läuft gerade?
- Was braucht meine Aufmerksamkeit?
- Welcher Branch hat nützliche Änderungen?
- Welcher Worktree ist dirty?
- Welche Arbeit ist bereits mit einem Pull Request verbunden?
- Welche Session kann aufgeräumt werden?
Das ist keine „KI-Magie". Das ist Workflow-Management.
Ein praktisches .NET-Beispiel
Stell dir eine SaaS-Lösung mit einer Backend-API, einem Worker-Service und einem Blazor-Administrationsportal vor.
Ich möchte vielleicht drei Aufgaben parallel erkunden:
- Retry-Handling zu einem Background-Worker hinzufügen.
- Die Validierung an einem Kunden-API-Endpoint verbessern.
- Fehlende Tests für einen Billing-Service schreiben.
Ohne Worktrees wird das schnell nervig. Entweder wechsle ich ständig Branches oder ich klone das Repository mehrfach.
Mit der Agent Sessions View wird der Workflow strukturierter:
main repository
│
├── worktree: agent/retry-worker
├── worktree: agent/customer-validation
└── worktree: agent/billing-tests
Jede Aufgabe bekommt ihr eigenes isoliertes Arbeitsverzeichnis und ihren eigenen Branch.
Das bedeutet, der Agent kann arbeiten, ohne meinen aktuellen Branch zu stören. Ich kann eine Session reviewen, während eine andere weiterläuft. Ich kann ein Experiment verwerfen, ohne den Rest des Repositorys anzufassen.
Genau diese Art von Struktur braucht agentische Entwicklung.
Setup-Kommandos sind wichtiger, als sie klingen
Eines der Details, die mir am besten gefallen, ist die Möglichkeit, beim Erstellen einer neuen Agent-Session konfigurierte Setup-Kommandos auszuführen.
Für viele .NET-Repositories ist ein neues Arbeitsverzeichnis nicht sofort nutzbar. Möglicherweise musst du Pakete wiederherstellen, die Solution bauen, lokale Einstellungen vorbereiten oder ein Skript ausführen.
Zum Beispiel:
dotnet restore
dotnet build
dotnet test --no-build
Oder in einem komplexeren Repo:
dotnet workload restore
dotnet tool restore
dotnet build ./src/MySolution.sln
Wenn jede Agent-Session von einem sauberen, aber unvorbereiteten Worktree aus startet, verlierst du Zeit und Konsistenz. Wenn Setup-Kommandos als Teil der Session-Erstellung ausgeführt werden, startet der Agent von einer bekannten Baseline aus.
Das ist die Art praktisches Detail, das dem Feature das Gefühl gibt, für echte Repositories entworfen worden zu sein und nicht nur für Demos.
Warum das ein DevOps-Thema ist
Ich würde die Agent Sessions View nicht nur als Feature für die Entwicklerproduktivität positionieren.
Es ist auch ein DevOps-Feature.
Branch-Hygiene, reproduzierbares Setup, lokale Isolation, PR-Reife und Aufräumen sind Delivery-Belange. Wenn KI-Agenten mehr Branches und mehr Änderungen erzeugen, brauchen Teams eine stärkere Flusskontrolle rund um diese Branches.
Andernfalls bekommt das Team am Anfang Velocity und am Ende Chaos.
Das ist ein schlechter Deal.
Die Agent Sessions View hilft, weil sie den Zustand paralleler Arbeit sichtbar macht. Sichtbarkeit ist die erste Voraussetzung für Kontrolle.
Der Stichtag 23. April
Für einen Artikel, der am 23. April veröffentlicht wird, würde ich die Aussagen präzise halten.
Zu diesem Zeitpunkt hatte GitKraken Desktop 12.0.0 die Agent Sessions View am 14. April eingeführt, und 12.0.1 war am 18. April mit Verbesserungen rund um Claude-Code-Hooks gefolgt. Ich würde keine späteren Verfeinerungen aus Mai oder Juni erwähnen, als würden sie bereits existieren.
Diese historische Genauigkeit ist wichtig. Ambassador-Content sollte sich vertrauenswürdig anfühlen.
Mein empfohlener Workflow
So würde ich es in der Praxis einsetzen:
- Von einem sauberen main-Branch starten.
- Die neuesten Änderungen pullen.
- Eine neue Agent-Session für eine klar abgegrenzte Aufgabe erstellen.
- GitKraken den Worktree erstellen und den ausgewählten Agenten starten lassen.
- Setup-Kommandos nutzen, um die Umgebung wiederherzustellen/zu bauen.
- Die Agent-Session vom linken Panel aus überwachen.
- Das resultierende Diff manuell reviewen.
- Tests lokal ausführen.
- Den Pull Request erstellen oder aktualisieren.
- Den Worktree entfernen, wenn der Branch gemergt oder verworfen wurde.
Der Schlüssel ist der Scope.
Ich würde nicht eine riesige „alles reparieren"-Agent-Session starten. Ich würde kleine, reviewbare Sessions mit klaren Branch-Namen und klaren Akzeptanzkriterien erstellen.
So hältst du agentische Arbeit mit professioneller Delivery vereinbar.
Was ich anderen Engineers sagen würde
Denk nicht daran als „KI in GitKraken Code schreiben lassen".
Denk daran als eine Steuerzentrale für isolierte parallele Arbeit.
Der Agent schreibt vielleicht den Code, aber der Entwickler entscheidet weiterhin:
- was die Aufgabe ist,
- zu welchem Branch sie gehört,
- ob die Änderungen korrekt sind,
- ob die Tests ausreichend sind,
- ob der PR bereit ist,
- und ob die Arbeit gemergt werden soll.
Das ist die richtige Rollenverteilung.
Fazit
Die GitKraken Desktop Agent Sessions View ist wertvoll, weil sie den Teil des KI-Codings adressiert, den viele Demos ignorieren: die Überwachung.
Code zu generieren ist leicht vorzuführen. Parallel generierte Arbeit in einem echten Repository zu verwalten ist schwerer.
Für .NET- und DevOps-Teams, die mit agentischer Entwicklung experimentieren, ist diese Unterscheidung wichtig. Die Zukunft besteht nicht nur aus „mehr Agenten". Die Zukunft besteht aus besserer Kontrolle über die Arbeit, die diese Agenten erzeugen.
Kommentare
Noch keine Kommentare. Teilen Sie als Erste(r) Ihre Gedanken!
Kommentar hinterlassen
Ihr Kommentar wird vor der Veröffentlichung geprüft.