Human-in-the-loop-Coding-Agents werden meist als eine Einstellung beschrieben: der Modus, in dem das Tool nachfragt, bevor es etwas bearbeitet. Das ist ein Loop, und es ist der kleinste. Er läuft im Terminal eines einzelnen Entwicklers, für eine einzelne Session, und er löst sich auf, sobald die Session endet. Ein Team, das glaubt, menschliche Aufsicht zu haben, weil alle Claude Code im Manual-Modus gelassen haben, hat Aufsicht über Tastendrücke, nicht über Ergebnisse.
Dieser Leitfaden beschreibt den Review-Workflow als fünf Gates – vom Berechtigungs-Prompt innerhalb der Runtime bis zur Abnahme-Entscheidung im gemeinsam genutzten Datensatz – und sagt, wer bei jedem Gate entscheidet und wo diese Entscheidung festgehalten wird. Die Runtime-Gates stammen aus der Dokumentation der Tools selbst. Die Team-Gates nutzen Sharkly, weil sie dort am Task festgehalten werden statt im Scrollback von irgendjemandem. Wenn du zuerst die Definition der Praxis willst: unser Leitfaden zum AI-Agent-Projektmanagement behandelt den Loop, in dem dieser Workflow lebt.
TL;DR
Ein Human-in-the-loop-Review-Workflow für Coding-Agents hat fünf Gates: den Berechtigungsmodus der Runtime, die Plan-Bestätigung, bevor aus Arbeit Tasks werden, die Ausführungsgrenze, die entscheidet, wann ein Run starten darf, das Aufmerksamkeitssignal, das den Review an eine namentlich benannte Person leitet, und die Abnahme, die von dieser Person als Statusänderung festgehalten wird. Nur das erste Gate ist eine Tool-Einstellung. Die anderen vier sind Team-Entscheidungen und brauchen einen gemeinsamen Datensatz, um real zu sein. Agents recherchieren, führen aus, testen und berichten. Menschen geben die Richtung vor, erteilen die Befugnis und nehmen das Ergebnis ab.
Gate 1: Der Berechtigungsmodus in der Runtime
Jeder ernstzunehmende Coding-Agent liefert ein Genehmigungs-Rad mit. Claude Codes Berechtigungsmodi reichen von default, beschriftet als Manual, was vor Bearbeitungen, Shell-Befehlen und Netzwerkzugriffen nachfragt, über acceptEdits, plan und auto, wo ein zweites Modell – der Classifier – Aktionen statt deiner prüft, bis hin zu bypassPermissions nur für isolierte Container. Umschalten mit Shift+Tab oder --permission-mode. Codex bietet dieselbe Idee über den Befehl /permissions, der festlegt, wann es Dateien bearbeiten oder Befehle ausführen darf, ohne nachzufragen.
Dieses Gate ist notwendig und nicht ausreichend. Es ist pro Session und pro Entwickler, es schützt die Maschine statt der Anforderung, und es hinterlässt keinen Datensatz, den ein Teammitglied lesen könnte. Bei Pro-, Max- und Team-Plänen startet Claude Code inzwischen standardmäßig im Auto-Modus, eine vernünftige Wahl – genau deshalb, weil der Classifier schneller und konsistenter ist als ein müder Mensch, der auf Ja klickt. Die Lehre ist nicht, gegen das Rad zu kämpfen, sondern aufzuhören, das Rad als den Review zu behandeln.
Gate 2: Plan-Bestätigung
Das erste Gate auf Teamebene liegt vor jeder Codezeile. Im Agent-Chat von Sharkly kann der Agent im Plan-Modus Aktionen zur Überprüfung vorschlagen, und der geplante Task samt Sub-Tasks wird erst angelegt, nachdem eine Person den Vorschlag bestätigt hat. Du kannst bestätigen, ohne zu starten, oder bestätigen und starten.
Hier wird der Umfang festgelegt, und das ist günstig: einen vorgeschlagenen Sub-Task zu bearbeiten kostet eine Minute, einen nicht angefragten Refactor zu überprüfen kostet einen Nachmittag. Lass Explore ausgewählt, wenn du nur eine Analyse willst. Nutze eine Crew, wenn ein Leader das Ziel interpretieren und weitere Agent-Mitglieder einbeziehen muss; nutze einen einzelnen Agent und spare dir das Zeremoniell, wenn eine Rolle die Arbeit abdeckt. Unser Leitfaden zum Chat mit einem AI-Agent oder zum Zuweisen eines Tasks behandelt die drei Modi.
Gate 3: Die Ausführungsgrenze
Ein Task, der einem Agent zugewiesen ist, startet nicht, solange er im Backlog liegt. Ihn in einen Status zu verschieben, dessen Kategorie „bereit für Arbeit“ ist, startet den Run, und die Kategorien „abgeschlossen“, „abgebrochen“ und „Duplikat“ starten niemals einen initialen Run. Die Statuskategorie ist also ein Gate, das eine Person bewusst bedient, und es ist auf dem Board sichtbar.
Zwei Dinge machen dieses Gate zu mehr als einer Formalität. Jeder Run bekommt ein isoliertes Verzeichnis, und repository-basierte Runs bereiten einen frischen Worktree vor, sodass ein genehmigter Run einem Run, den niemand genehmigt hat, keinen Schaden zufügen kann. Und der Run trägt die Task-Beschreibung, aktuelle Kommentare und den Task-Typ Workflow, der die Status einschränkt, die der Agent auswählen darf. Ein Agent kann seine eigene Arbeit nicht als abgenommen markieren, wenn der Workflow ihm diesen Status nicht gibt. Unser Beitrag zu Git-Worktrees mit AI-Coding-Agents erklärt die Isolation.
Gate 4: Das Aufmerksamkeitssignal
Ein Agent beendet einen Run an einer von zwei nützlichen Stellen: mit einem Ergebnis oder mit einer Frage. Sharkly benennt beides. Ein Agent kann einen Task als „wartet auf menschliche Antwort“ oder „wartet auf menschlichen Review“ hinterlassen, und fehlgeschlagene oder blockierte Arbeit taucht als Aufmerksamkeits-Eintrag auf. Diese Signale landen im Inbox, im Bereich Primary, bei der verantwortlichen Person, und Run-Fehler gehen an die zugewiesene Person statt an alle Abonnenten.
Das Gate hier ist das Routing, und es ist das, was die meisten Teams versehentlich falsch machen. Ein Review, der in einen Kanal geht, geht an niemanden. Ein Review, der an den menschlichen Assignee geht, am Task, mit dem Ausführungsprotokoll einen Klick entfernt, geht an jemanden, den man später darauf ansprechen kann. Unser Leitfaden zur AI-Agent-Inbox behandelt die Mechanismen der Warteschlange.
Antworten ist auch der Weg, wie Arbeit weitergeht. Ein Mitgliedskommentar an einem Task mit einem bereiten Agent-Assignee kann einen weiteren Run einreihen, sodass Review-Feedback dieselbe Arbeit fortsetzt, statt einen zweiten Prozess zu starten. Eine Person zu erwähnen – oder ein All-Mention zu verwenden – startet für sich genommen keinen Agent, was verhindert, dass ein Mensch-zu-Mensch-Austausch den Agent aufweckt.
Gate 5: Abnahme im Datensatz
Abnahme bedeutet, dass eine Person den Task-Status ändert, nachdem sie die Belege gelesen hat. Lies in dieser Reihenfolge: die Abnahmekriterien in der Beschreibung, den Kommentar des Agent, der die durchgeführten Prüfungen und die verbleibenden Unsicherheiten nennt, das Ausführungsprotokoll und dann den Diff. Das Protokoll hält fest, warum der Run eingereiht wurde, wann er gestartet und beendet wurde, Tool-Aufrufe und Runtime-Ereignisse, die Auslöse-Quelle und Fehlerdetails; es ist der Unterschied zwischen dem Review einer Änderung und dem Review einer Geschichte über eine Änderung.
Zwei Regeln schützen dieses Gate. Das Mergen eines verknüpften Pull Requests ändert den Task-Status nicht, sodass ein Merge nie mit einer Abnahme verwechselt wird. Und ein abgeschlossener Automation-Run beschreibt den Run, nicht das Versprechen, dass jedes nachgelagerte Ergebnis korrekt war. Beides stammt direkt aus der Produktdokumentation, und beides existiert, weil Teams „fertig“ immer wieder mit „korrekt“ verwechselt haben.
Der Workflow in einer Tabelle
| Gate | Beantwortete Frage | Wer entscheidet | Wo es festgehalten wird |
|---|---|---|---|
| Berechtigungsmodus | Darf diese Session das anfassen? | Der Entwickler | Nirgends gemeinsam |
| Plan-Bestätigung | Ist das die richtige Aufteilung? | Eine Person, zum Vorschlag | Die bestätigten Sub-Tasks |
| Ausführungsgrenze | Darf dieser Task jetzt laufen? | Wer ihn aus dem Backlog verschiebt | Statusänderung in Activity |
| Aufmerksamkeitssignal | Wer muss hinschauen, und worauf? | Sharkly leitet es an den Assignee | Inbox Primary und der Task |
| Abnahme | Ist das Ergebnis korrekt? | Der menschliche Assignee | Statusänderung durch eine namentlich benannte Person |
Wann man die Gates weiter öffnet
Nicht jeder Task verdient fünf Stopps, und das Gegenteil zu behaupten ist der Weg, wie Review zum Theater wird. Nur lesende Arbeit wie ein Repository-Audit braucht Gate 1 und Gate 5. Umkehrbare Arbeit in einem isolierten Worktree, etwa ein Dependency-Bump mit Tests, kann die Plan-Bestätigung überspringen. Automations, die nach Zeitplan laufen, sollten in ihren Anweisungen festhalten, wann eine Person prüfen oder entscheiden muss, und sollten manuell ausgeführt und inspiziert werden, bevor jemand vom Zeitplan abhängt; unser Leitfaden zu Automations in Sharkly behandelt das.
Behalte alle fünf für alles, was eine öffentliche Schnittstelle ändert, Daten anfasst oder nicht mit einem einzigen Befehl rückgängig gemacht werden kann. Und halte überall eine Regel ein: ein namentlich benannter menschlicher Assignee bei jedem Agent-Task. Sharkly trennt menschliche Verantwortung bewusst von der Ausführung durch Agents, sodass ein Task gleichzeitig Personen und einen Agent zugewiesen haben kann. Verantwortlichkeit lässt sich nicht delegieren, und der Datensatz sollte zeigen, wer sie trägt.
Was Human-in-the-loop nicht ist
Es ist keine Person, die ein Terminal beobachtet. Es ist kein Berechtigungs-Prompt mit einem erschöpften Reviewer dahinter. Und es ist kein Status, der „Abgeschlossen“ sagt. Automatisierung endet dort, wo Team-Urteilsvermögen gefragt ist, und liefert eine Auslieferung mit vollständigem Kontext und prüfbaren Belegen zurück. Dieser Satz ist der ganze Workflow; die Gates sind nur der Ort, an dem er durchgesetzt wird. Sharkly ersetzt weder Claude Code noch Codex oder andere Ausführungstools; es ist die Ebene, die diese Entscheidungen aufschreibt.
FAQ
Entfernt der Auto-Modus in Claude Code den Menschen aus dem Loop? Er entfernt den Menschen aus dem Berechtigungs-Prompt. Der Classifier prüft Aktionen gegen deine Anfrage; er prüft nicht, ob das Ergebnis die Anforderung erfüllt hat. Gates 2 bis 5 bleiben weiterhin Sache der Menschen.
Wie stoppe ich einen Agent mitten im Run? Eine eingereihte oder laufende Ausführung kann abgebrochen werden. Einen Task in den Status „Abgebrochen“ oder „Duplikat“ zu verschieben stoppt ebenfalls aktive Runs; der Status „Abgeschlossen“ tut das nicht – also erst abbrechen, wenn der Agent noch arbeitet.
Wer sollte der Reviewer sein? Der menschliche Assignee am Task. Sharkly sendet Waiting-for-review- und Fehlersignale an diese Person, weshalb jeder Agent-Task eine nennen sollte. Unser Leitfaden zu Agents in Sharkly erklärt die zwei Zuweisungs-Slots.
Kann Review-Feedback ohne neuen Task an den Agent zurückgehen? Ja. Ein Kommentar am Task kann einen Folge-Run für den zugewiesenen Agent einreihen, und schnelle Kommentare werden zusammengefasst, damit sie keine doppelten Runs erzeugen.
