Ein Coding-Agent kann aus einem Ticket einen Pull Request machen, während du Kaffee holst. Diese Geschwindigkeit wirft eine leisere Frage auf, die dir kein Tooling beantwortet: Wer besitzt den Diff, sobald es ihn gibt? Nicht wer ihn getippt hat – das war der Agent. Sondern: Wer steht dafür gerade, ob er ausgeliefert wird, ob es die richtige Änderung war und was passiert, wenn um 2 Uhr nachts etwas kaputtgeht? Die Ausführung ist an den Agenten übergegangen. Die Verantwortung nicht – und sie kann es auch nicht.
Die Unschärfe wird größer, sobald du mehr als einen Agenten laufen lässt. Gib einen Bug an Claude Code und einen anderen an Codex, und du hast zwei Branches, zwei Zusammenfassungen und keine gemeinsame Antwort auf eine einfache Frage: Wessen Name steht auf jeder dieser Änderungen, wenn sie landen? Verantwortung, die nur im Scrollback eines Terminals lebt, ist keine Verantwortung. Sie ist eine Vermutung, die bis zum nächsten git log hält.
Genau um dieses Problem herum ist Sharkly gebaut. Sharkly sitzt über deinen Coding-Agenten als die Schicht, die festhält, wer die Arbeit zugewiesen hat, welcher Agent sie ausgeführt hat, wer das Ergebnis reviewt und wer es abnimmt. Dieser Artikel beschreibt dieses Betriebsmodell als vier Rollen und eine Reihe von Status und führt dann ein Ticket von der Zuweisung bis zum gemergten PR durch. Für die Review-Mechanik darunter deckt unser Leitfaden zu Human-in-the-Loop-Coding-Agenten die fünf Gates ab, die diese Entscheidungen durchsetzen.
TL;DR
Menschliche Verantwortung für Agenten-Arbeit bedeutet, dass die Verantwortung für eine Änderung nie auf den Agenten übergeht – auch dann nicht, wenn die Ausführung es tut. Das Betriebsmodell kennt vier Rollen: Eine Person weist zu, ein Agent führt aus, ein benannter Mensch reviewt, und derselbe Mensch nimmt ab. Agenten können eine Task bis Ready for review bringen; auf Done verschiebt sie nur ein Mensch. Agenten recherchieren, führen aus, testen und berichten. Menschen geben die Richtung vor, erteilen die Befugnis und nehmen das Ergebnis ab.
Wem gehört die Arbeit, die ein Agent produziert
Verantwortung und Ausführung sind zwei verschiedene Jobs, und sie zu verwechseln ist der Grundfehler. Ausführung heißt, die Änderung zu erzeugen: den Code lesen, Dateien bearbeiten, Tests laufen lassen, einen PR öffnen. Das macht ein Agent gut und schnell. Verantwortung heißt, für das Ergebnis geradestehen zu müssen: dass die Änderung es wert war, dass sie die Abnahmekriterien erfüllt und dass man auch in drei Monaten jemanden dazu befragen kann. Diese Rechenschaft bleibt bei einem Menschen, denn einen Agenten kann man nachträglich nicht bitten, einen Trade-off zu begründen oder die Konsequenzen zu tragen.
Am klarsten lässt sich die Aufteilung als Vertrag zwischen Mensch und Agent formulieren: Agenten recherchieren, führen aus, testen und berichten; Menschen geben die Richtung vor, erteilen die Befugnis und nehmen das Ergebnis ab. Automatisierung endet dort, wo Team-Urteilsvermögen gefragt ist. Alles bis zum „Ergebnis abnehmen“ lässt sich an einen Agenten übergeben. Die Abnahme selbst nicht, und die Entscheidung über das Release ebenso wenig. Unser Beitrag zu AI-Assistenten vs. AI-Teammitglieder zieht dieselbe Grenze aus der anderen Richtung.
Das Betriebsmodell: zuweisen, ausführen, reviewen, abnehmen
Sobald du Verantwortung von Ausführung trennst, zerfällt der Workflow in vier Rollen mit jeweils einer Aufgabe. Sie zu benennen ist das, was verhindert, dass aus fünf parallel laufenden Agenten fünf verwaiste Branches werden.
| Schritt | Wer handelt | Was diese Rolle verantwortet |
|---|---|---|
| Zuweisen | Eine Person | Entscheiden, dass die Arbeit sich lohnt, Abnahmekriterien schreiben und benennen, wer verantwortlich ist |
| Ausführen | Ein Agent, über eine Runtime auf einem Computer | Die Änderung erzeugen, Tests ausführen und berichten, was gemacht wurde und was unsicher ist |
| Reviewen | Der menschliche Assignee | Das Ergebnis anhand der Abnahmekriterien und der Belege beurteilen |
| Abnehmen | Derselbe menschliche Assignee | Die Entscheidung zu mergen und auszuliefern |
Das entscheidende Detail steckt in der ersten und der letzten Zeile: Dieselbe Person verantwortet Zuweisung und Abnahme. So schließt sich der Kreis. Wer entschieden hat, dass die Arbeit wichtig ist, bestätigt auch, dass sie erledigt wurde. Sharkly unterstützt das, indem eine Task gleichzeitig zwei Zuweisungs-Slots hat – einen menschlichen Assignee und einen Agent-Assignee –, sodass Verantwortung und Ausführung als getrennte Fakten erfasst werden statt als ein mehrdeutiges „zugewiesen an“. Wie Arbeit zum Agenten gelangt, beschreibt unser Leitfaden zum Zuweisen, Verfolgen und Reviewen von Agenten-Arbeit an einem Ort.
Status und Gates: Agenten kommen bis Ready for review, auf Done kommt nur ein Mensch
Das Betriebsmodell wird real, wenn es auf Task-Status abgebildet wird, denn eine Statusänderung ist eine Entscheidung, auf die man später zeigen kann. Hier gilt eine strikte Regel, die man ruhig klar aussprechen sollte: Agenten können Arbeit bis Ready for review voranbringen; auf Done verschiebt eine Task nur ein Mensch.
| Status-Kategorie | Wer verschiebt sie | Bedeutung |
|---|---|---|
| Backlog | Person | Nicht begonnen. Wird hier ein Agent zugewiesen, läuft nichts |
| Ready for work | Person | Eine Task in diese Kategorie zu verschieben, startet den Agenten-Lauf |
| In progress | Agent | Der Lauf wird gerade in einem isolierten Worktree ausgeführt |
| Ready for review | Agent | Der Lauf ist fertig und wartet auf den benannten Menschen |
| Done / Accepted | Person | Ein Mensch hat die Belege gelesen und das Ergebnis abgenommen |
Zwei Grenzen schützen das. Erstens kann ein Agent keinen Status auswählen, den sein Task-Workflow ihm nicht zugesteht, also kann er seine eigene Arbeit nicht als abgenommen markieren. Er lässt die Task auf menschliches Review warten, und dieses Signal landet im Posteingang der verantwortlichen Person statt in einem Kanal, den niemand liest. Zweitens ändert das Mergen eines verknüpften Pull Requests den Task-Status nicht. Ein Merge ist ein Git-Ereignis, keine Abnahmeentscheidung, und Sharkly hält beides getrennt, damit „der PR ist gemergt“ nie mit „ein Mensch hat das als korrekt beurteilt“ verwechselt wird. Wenn dir die Review-Kapazität Sorgen bereitet: Unsere Analyse dazu, warum menschliches Review der eigentliche Engpass ist, zeigt, wie man dafür plant.
Vom Ticket zum gemergten PR: ein durchgerechnetes Beispiel
Hier läuft das Modell einmal komplett durch, an einer einzigen Task: SH-312, „Rate Limiting für den öffentlichen Such-Endpunkt hinzufügen“.
- Zuweisen. Eine Entwicklerin schreibt die Task: den Endpunkt, das Ziel-Limit und die Abnahmekriterien (429 bei Überschreitung, bestehende Tests laufen weiterhin durch, ein neuer Test für das Limit). Sie setzt sich selbst als menschlichen Assignee und wählt den Agent-Assignee. Die Task liegt im Backlog. Es läuft noch nichts.
- Ausführen. Sie verschiebt
SH-312in einen Ready-for-work-Status. Diese Statusänderung startet den Lauf. Der Agent beansprucht die Task, bereitet einen frischen Worktree vor, damit diese Arbeit nicht mit anderer kollidiert, liest die Beschreibung und die letzten Kommentare, bearbeitet den Endpunkt, ergänzt den Test und lässt die Testsuite laufen. - Berichten. Der Agent öffnet einen Pull Request und postet einen Kommentar an der Task: die Zusammenfassung der Änderung, die ausgeführten Tests samt Ergebnissen und einen ehrlichen Hinweis, dass er das Limit nicht unter echtem Traffic per Lasttest geprüft hat. Er verschiebt
SH-312auf Ready for review. Dort hört er auf. Weiter kommt er nicht. - Reviewen. Das Signal „wartet auf Review“ erreicht den Posteingang der Entwicklerin. Sie liest in dieser Reihenfolge: die Abnahmekriterien, den Kommentar des Agenten, das Ausführungsprotokoll, dann den Diff. Das Log zeigt, warum der Lauf in der Warteschlange stand und welche Tool-Aufrufe er gemacht hat – so reviewt sie die Änderung und nicht eine Geschichte darüber. Die Lasttest-Lücke ist real, also kommentiert sie mit der Bitte um einen Test an der dokumentierten Obergrenze. Dieser Kommentar reiht einen Folge-Lauf für denselben Agenten ein; sie legt keine zweite Task an.
- Abnehmen. Der Agent ergänzt den Test, berichtet erneut und gibt die Task zurück auf Ready for review. Diesmal passen die Belege zu den Kriterien. Sie merged den PR und verschiebt
SH-312auf Done – zwei bewusste Handlungen der Person, die die Arbeit von Anfang an verantwortet hat.
Jeder Schritt fließt zurück in die Task: der Lauf, der PR-Link, die Review-Kommentare, die Abnahme. Nichts lebt nur in einem Terminal. Unser Leitfaden zum Reviewen KI-generierten Codes mit Belegen auf Task-Ebene geht tiefer darauf ein, was du lesen solltest, bevor du abnimmst.
Wo Verantwortung still verloren geht
Du brauchst diese ganze Zeremonie nicht bei jeder Task, und zu tun als ob, macht Review zum Theater. Nutze die leichte Variante, wenn die Arbeit nur lesend oder trivial rückgängig zu machen ist: ein Repository-Audit oder ein Dependency-Bump mit grünen Tests kann direkt vom Lauf in eine schnelle Abnahme übergehen. Nutze den vollen Vier-Rollen-Loop mit benannten Menschen an beiden Enden, sobald eine Änderung Daten berührt, eine öffentliche Schnittstelle verändert oder sich nicht mit einem einzigen Befehl rückgängig machen lässt.
Der Fehlermodus, auf den du achten musst, ist nicht, dass Agenten zu viel tun. Es ist, dass Verantwortung gar nicht erst zugewiesen wird. Eine Task mit Agent-Assignee und ohne menschlichen Assignee hat Ausführung ohne Rechenschaft: das Problem der verwaisten Branches, hübsch verpackt als Fortschritt. Die Lösung ist eine Regel, die überall gilt: Jede Agenten-Task benennt einen Menschen, der sie verantwortet. Wenn du Übergaben zwischen mehreren Agenten koordinierst, zeigt unser Leitfaden zu Übergabe-Mustern von Agent zu Agent und von Agent zu Mensch, wo der menschliche Owner in der Kette sitzt.
Fazit
Menschliche Verantwortung für Agenten-Arbeit ist keine Bremse für Automatisierung. Sie ist das, was Automatisierung überhaupt sicher skalierbar macht. Lass Agenten die Ausführung übernehmen – die ganze, in welcher Geschwindigkeit auch immer. Behalte vier Entscheidungen bei Menschen: was zugewiesen wird, ob die Befugnis zum Ausführen erteilt wird, ob das Ergebnis die Messlatte erfüllt und ob es ausgeliefert wird. Halte diese Entscheidungen als Statusänderungen an einer gemeinsamen Task fest, damit Verantwortlichkeit ein Fakt ist, den jeder nachlesen kann, statt einer Vermutung in irgendjemandes Scrollback.
Wenn du bereits mehrere Coding-Agenten laufen lässt, gibt dir Sharkly einen Ort, um ihre Arbeit zuzuweisen, sie beim Laufen zu beobachten und festzuhalten, wer jedes Ergebnis reviewt und abgenommen hat. Du kannst dieses Modell mit Worktrees und einer Tabellenkalkulation von Hand zusammenbauen – oder Sharkly herunterladen und die Task das tragen lassen. Wie diese Schicht im Ganzen aussieht, erfährst du in Coding-Agent-Management oberhalb von Claude Code und Codex.
FAQ
Bedeutet menschliche Verantwortung, dass eine Person jedem Agenten-Lauf zusieht? Nein. Verantwortung heißt Rechenschaft, nicht Überwachung. Eine Person weist die Arbeit zu und nimmt das Ergebnis ab; dazwischen läuft der Agent unbeaufsichtigt. Außerdem skaliert es nicht über einen Agenten hinaus, einem Terminal zuzusehen.
Kann ein Agent seine eigene Arbeit als erledigt markieren? Nein. Ein Agent kann eine Task bis Ready for review bringen, aber sein Task-Workflow gewährt ihm den Status „abgenommen“ nicht. Ein Mensch liest die Belege und verschiebt die Task auf Done.
Nimmt das Mergen des Pull Requests die Task ab? Nein. Das Mergen eines verknüpften PR ist ein Git-Ereignis und ändert den Task-Status in Sharkly nicht. Die Abnahme ist eine separate Statusänderung, die der menschliche Owner nach dem Review vornimmt.
Wer sollte die Task eines Agenten verantworten? Die Person, die entschieden hat, dass die Arbeit es wert ist. Sharkly hält neben dem Agent-Assignee einen Slot für einen menschlichen Assignee bereit, damit das Review-Signal bei dieser Person landet und sie abnimmt.
Was passiert, wenn kein Mensch zugewiesen ist? Dann hast du Ausführung ohne Rechenschaft. Die sichere Regel lautet: Jede Agenten-Task benennt einen menschlichen Owner, damit ein abgeschlossener Lauf immer jemanden hat, der dafür geradesteht.
