Sie haben heute Morgen vier Agents gestartet. Einer hat das Auth-Modul refaktoriert, einer hat Tests geschrieben, einer hat einen flaky CI-Job gejagt, und einer denkt noch nach. Am Nachmittag haben Sie eine vage Ahnung, dass etwas passiert ist, einen Stapel Terminal-Tabs, drei Worktrees, an deren Erstellung Sie sich nur halb erinnern, und zwei Pull Requests, die Sie nicht gelesen haben. Die Arbeit wurde erledigt. Sie können nicht sehen, was es war.
Die von KI-Coding-Agents erledigte Arbeit nachzuverfolgen, ist das Problem, aus diesem Durcheinander ein Verzeichnis zu machen: was jeder Agent geändert hat, ob es Bestand hat und wo es gelandet ist. Es ist ein echtes Problem, weil Agents schneller fertig werden, als Sie sie prüfen können, und die Belege für das, was sie getan haben, an Orten liegen, die für eine allein arbeitende Person gebaut wurden. Dieser Leitfaden führt zunächst durch das manuelle Setup, benennt, wo es bricht, und zeigt dann den Workflow, den Sharkly verwendet, um jedes Ergebnis mit der Aufgabe verbunden zu halten, die es angefordert hat.
Die Kurzfassung: Ein paar Agents können Sie mit Git und Ihrem Terminal von Hand nachverfolgen. Darüber hinaus brauchen Sie einen gemeinsamen Ort, an dem Ergebnisse von selbst zurückkommen, weil der Engpass nicht mehr das Coden ist, sondern Ihre Fähigkeit, es zu reviewen.
TL;DR
Die Nachverfolgung abgeschlossener Agent-Arbeit bedeutet, für jeden Lauf drei Fragen zu beantworten: was sich geändert hat, ob es korrekt ist und wo es gelandet ist. Die Git-Historie und Pull Requests beantworten die erste Frage für ein oder zwei Agents. Sobald mehrere Agents parallel arbeiten, zersplittert das Verzeichnis über Worktrees, Terminals und PR-Warteschlangen, und Sie verlieren die Verbindung zwischen der Aufgabe und ihrem Ergebnis. Ein Task-Board löst das, indem es Ausführung, Blocker, Ergebnisse und menschliches Review zu einer Aufgabe zurückführt, sodass die abgeschlossene Arbeit inspizierbar ist, statt rekonstruiert werden zu müssen.
Was die Nachverfolgung abgeschlossener Arbeit bedeutet
Nachverfolgung ist kein Aktivitätsprotokoll. Sie ist die Fähigkeit, drei Fragen zu einem abgeschlossenen Lauf zu beantworten, ohne ihn rückwärts zu rekonstruieren.
- Was sich geändert hat. Der Diff, die berührten Dateien, der Grund für jede.
- Ob es korrekt ist. Typecheck, Tests, der Build und eine Zusammenfassung dessen, was der Agent verifiziert hat.
- Wo es gelandet ist. Der Branch, der PR, die Aufgabe, zu der es gehört, und wer es abnimmt.
Ein Agent, der stillschweigend fertig wird, hat technisch gesehen Arbeit abgeschlossen, aber Sie können nicht darauf reagieren. Der abgeschlossene Zustand, der Sie interessiert, ist der, den eine Person inspizieren und abnehmen kann. Deshalb ist „die Tests sind durchgelaufen“ nicht dasselbe wie „die Arbeit ist nachverfolgt“.
Das Human-in-the-Loop-Modell für Coding-Agents zieht die Grenze: Agents recherchieren, führen aus, testen und berichten; Menschen geben die Richtung vor und nehmen das Ergebnis ab. Nachverfolgung ist die Maschinerie, die die zweite Hälfte möglich macht.
Das DIY-Setup, Schritt für Schritt, und wo jeder Schritt bricht
Für einen Agent auf einem Branch reichen die eingebauten Werkzeuge. Hier ist die ehrliche Version, mit dem benannten Fehlermodus bei jedem Schritt.
Schritt 1: Sehen, was sich geändert hat. Nach einem Lauf lesen Sie den Diff.
git log --oneline -10
git diff main...HEAD --stat
Bricht, wenn: zwei Agents sich einen Branch teilen, oder ein Agent nichts committet und Änderungen im Working Tree eines Worktrees hinterlässt, den Sie vergessen haben. Der Diff, den Sie lesen, ist nicht der Diff, der ausgeliefert wurde.
Schritt 2: Die Arbeit jedes Agents isolieren. Sie geben jedem Agent seinen eigenen Git-Worktree, damit sie sich nicht in die Quere kommen.
git worktree add ../auth-refactor -b auth-refactor
git worktree list
Bricht, wenn: die Liste über das hinauswächst, was Sie im Kopf behalten können. git worktree list zeigt Ihnen die Pfade, aber nicht, welcher Agent in welchem steckt, welcher Aufgabe er dient oder ob er fertig ist. Die Mechanik finden Sie in der offiziellen git-worktree-Dokumentation; sie endet bei der Buchhaltung.
Schritt 3: Prüfen, ob die Ergebnisse einen PR erreicht haben. Sie verlassen sich auf GitHub.
gh pr list --author "@me" --state open
gh pr view 214 --json title,statusCheckRollup
Bricht, wenn: der PR existiert, aber niemand aufgeschrieben hat, warum, oder die Checks grün sind, während die Änderung falsch ist, oder der PR keine Verbindung zurück zur Anforderung hat, die ihn ausgelöst hat. Die gh pr list-Referenz zeigt Ihnen offene PRs, nicht die Absicht.
Schritt 4: Sich merken, was Sie angefordert haben. Für diesen Schritt gibt es keinen Befehl. Die ursprüngliche Anforderung lebt in einer Slack-Nachricht, einer Notiz oder Ihrem Gedächtnis. Wenn Sie den PR drei Tage später reviewen, raten Sie bei den Abnahmekriterien.
Jeder Schritt funktioniert. Das Problem sind die Nahtstellen dazwischen. Der Diff, die Isolation, der PR und die Absicht leben in vier Systemen, die nichts voneinander wissen, und Sie sind das Einzige, was sie verbindet.
Wo das manuelle Setup nicht mehr skaliert
Der Bruch ist kein Moment. Er ist eine Steigung, und Sie können benennen, wo Sie darauf stehen.
| Agents parallel | Was die Nachverfolgung kostet | Was zuerst bricht |
|---|---|---|
| 1 | Einen Diff lesen, einen PR | Nichts |
| 2 bis 3 | Zwischen Worktrees hin- und herwechseln | Sie verlieren, welcher Agent was getan hat |
| 4 bis 6 | Die Absicht pro PR rekonstruieren | Ergebnisse überholen Ihre Review-Kapazität |
| 7+ | Koordination in Vollzeit | Abgeschlossene Arbeit liegt tagelang ungereviewt |
Die eigentlichen Kosten werden in Review-Kapazität gemessen, nicht in Agent-Geschwindigkeit. Agents produzieren abgeschlossene Arbeit schneller, als eine Person sie inspizieren kann, sodass ab einer Handvoll Läufe Ihr Durchsatz dadurch begrenzt wird, wie schnell Sie die drei Fragen beantworten können, nicht dadurch, wie schnell die Agents coden. Mehr Agents hinzuzufügen macht das Tracking-Problem schlimmer, nicht das Delivery-Problem besser.
Was ein Task-Board hinzufügt
Die Lösung ist, einen abgeschlossenen Lauf nicht mehr als Diff zu behandeln, sondern als etwas, das zu einer Aufgabe zurückkehrt.
In Sharkly ist die Aufgabe das gemeinsame Verzeichnis. Sie weisen eine Aufgabe einem Agent oder einer Crew zu, und der Lauf findet in einem isolierten Worktree statt, sodass parallele Agents nie dieselben Dateien berühren. Wenn er fertig ist, kehren Ausführung, Blocker, Ergebnisse und Follow-up zur Task-Timeline zurück. Die Änderungszusammenfassung, die Verifikationsergebnisse und die bekannten Grenzen hängen an der Aufgabe selbst, nicht an einem Terminal, das Sie noch offen haben müssen.
Das ist der Unterschied zwischen einem Log und einem Verzeichnis. Ein Log sagt Ihnen, dass etwas passiert ist. Ein Verzeichnis sagt Ihnen, was sich geändert hat, ob es korrekt ist und wo es gelandet ist, alles an einem Ort, verknüpft mit der Anforderung, die es ausgelöst hat. Sie reviewen abgeschlossene Arbeit von der Aufgabe aus, nehmen sie ab oder schicken sie zurück, und die Entscheidung trägt Ihren Namen.
Hier schließen sich die DIY-Nahtstellen. Die Absicht, der Diff, die Checks und die Abnahme leben auf einem Objekt. Sie behalten die Werkzeuge, die Ihre Agents ohnehin nutzen; Claude Code und Codex übernehmen weiterhin die Ausführung, und Sharkly fügt die Task-, Kontext- und Review-Ebene darum herum hinzu. Arbeit an einen KI-Agent zu vergeben liest sich dann wie die Vergabe an ein Teammitglied, und das Ergebnis kommt dort zurück, wo Sie es finden können.
Sie können Sharkly herunterladen und einen Computer verbinden, um das an einer einzelnen echten Aufgabe auszuprobieren, bevor Sie es hochskalieren.
Wann Sie nichts davon brauchen
Seien Sie ehrlich bei der Schwelle. Wenn Sie einen Coding-Agent in einem Repo betreiben und jeden Diff lesen, bevor er gemergt wird, verfolgen Git und Ihr Terminal Ihre abgeschlossene Arbeit bereits nach. Ein Task-Board würde Zeremonie hinzufügen, die Sie nicht brauchen. Die eingebaute Projektansicht in Claude Code deckt für einen Single-Agent-Workflow überraschend viel ab.
Die Gleichung ändert sich, wenn drei Dinge zusammenkommen: mehr als ein paar Agents gleichzeitig, Arbeit, die Sie nicht am selben Tag reviewen können, an dem sie fertig wird, und Ergebnisse, die jemand anderen als Sie erreichen müssen. Dann hört ein gemeinsames Task-Verzeichnis auf, Overhead zu sein, und wird zur einzigen Möglichkeit, wie die abgeschlossene Arbeit von der Anforderung bis zum Release sichtbar ist.
Eine Checkliste, die Sie heute durchgehen können
Bevor Sie einen weiteren Agent hinzufügen, prüfen Sie, ob Sie für die bereits laufenden bei jedem dieser Punkte Ja sagen können:
- [ ] Können Sie für jeden abgeschlossenen Lauf den Diff in unter einer Minute finden, ohne ein Terminal zu öffnen?
- [ ] Trägt jeder abgeschlossene Lauf eine Zusammenfassung dessen, was der Agent verifiziert hat, nicht nur grüne Checks?
- [ ] Können Sie einen PR bis zur Anforderung zurückverfolgen, die ihn ausgelöst hat?
- [ ] Gibt es einen Ort, der zeigt, welcher Agent an was arbeitet, was fertig ist und was Review braucht?
- [ ] Trägt die Abnahme abgeschlossener Arbeit den Namen einer Person?
- [ ] Wenn ein Agent fertig wird, kommt das Ergebnis zu Ihnen, oder müssen Sie es suchen gehen?
Jedes „Nein“ ist eine Nahtstelle, die sich weiter öffnet, je mehr Agents Sie hinzufügen. Sie früh zu schließen ist günstiger, als später eine Woche nicht nachverfolgter Läufe zu rekonstruieren.
FAQ
Wie verfolge ich nach, was ein KI-Coding-Agent geändert hat? Lesen Sie den Diff, nicht die Zusammenfassung des Agents davon. Für einen Agent reichen git diff und der PR. Für mehrere halten Sie jeden Lauf in seinem eigenen Worktree und leiten den Diff plus eine Verifikationszusammenfassung zurück an eine gemeinsame Aufgabe, damit Sie ihn nicht aus dem Scrollback rekonstruieren müssen.
Kann ich KI-Agent-Arbeit allein mit GitHub nachverfolgen? Für ein oder zwei Agents ja. GitHub zeigt Ihnen offene PRs und den Check-Status. Es sagt Ihnen nicht, welcher Agent einen PR erzeugt hat, welcher Aufgabe er dient oder ob die Änderung zur ursprünglichen Absicht passt, sodass es schnell dünn wird, sobald mehrere Agents parallel laufen.
Wie viele Agents kann ich betreiben, bevor ich ein Task-Board brauche? Die meisten spüren die Nahtstellen bei etwa drei bis vier parallelen Agents, wenn die Rekonstruktion der Absicht pro PR mehr Zeit frisst als das Review selbst. Der Auslöser ist die Review-Kapazität, keine feste Zahl. Siehe unseren Beitrag zur Verwaltung paralleler Coding-Agents.
Bremst ein Task-Board schnell arbeitende Agents aus? Nein. Agents führen weiterhin mit voller Geschwindigkeit in isolierten Worktrees aus. Das Board fügt einen Rückweg hinzu, damit ihre abgeschlossene Arbeit dort landet, wo Sie sie reviewen können, was den manuellen Rekonstruktionsschritt entfernt, statt einen hinzuzufügen.
