Freigabe-Gates für Coding-Agents: Wo sie vor dem Merge gestoppt werden sollten

Ein Coding-Agent, der einen Pull Request öffnen kann, ist nützlich. Ein Coding-Agent, der einen mergen kann, während niemand hinsieht, ist ein Risiko mit Commit-Zugriff. Die Lücke zwischen diesen beiden Sätzen ist das ganze Problem. Sobald ein Agent auf einen Branch pushen, Tests ausführen und auf Merge klicken kann, lautet die Frage nicht mehr „Kann er die Arbeit erledigen?", sondern „Wo endet seine Befugnis?"

Die meisten Teams beantworten diese Frage versehentlich. Der Agent hat irgendwelche Berechtigungen, die seiner Laufzeitumgebung mitgegeben wurden, das Review findet in irgendeinem Terminal statt, in dem der Lauf gestartet wurde, und der Nachweis darüber, wer was freigegeben hat, lebt im Scrollback einer einzelnen Person. Das funktioniert so lange, bis Sie drei Agents über zwei Repositories hinweg laufen lassen und ein Freitags-Deploy etwas ausliefert, das niemand gelesen hat. Ein Freigabe-Gate ist die Lösung – aber nur, wenn es ein echter Checkpoint in einem gemeinsamen System ist und nicht eine Gewohnheit, von der Sie hoffen, dass alle sie einhalten.

Genau dieses gemeinsame System stellt Sharkly bereit. Sie haben bereits Coding-Agents; Sharkly macht aus ihren Läufen Tasks mit Status, Assignees und einem Review-Schritt, den eine Person bewusst durchführen muss. Dieser Artikel beschreibt das dahinterliegende Betriebsmodell: Wer weist Arbeit zu, wer führt sie aus, wer prüft sie, wer nimmt sie ab – und wo genau der Stopp hingehört, damit ein Agent niemals seine eigene Änderung ungeprüft mergt.

Was ein Freigabe-Gate wirklich ist

Ein Freigabe-Gate ist ein Punkt im Lebenszyklus einer Task, an dem die automatisierte Ausführung stoppt und auf eine Person wartet, die über den nächsten Schritt entscheidet. Keine Warnung, keine Logzeile, über die man hinwegscrollen kann: ein Zustand, in dem die Arbeit verharrt, bis ein Mensch sie weiterbewegt.

Der wichtigste Unterschied ist der zwischen einem Agent, der eine Änderung vorschlägt, und einem Agent, der sie mergt. Einen Pull Request zu öffnen ist ein Vorschlag. Ihn zu mergen ist eine Entscheidung über die Produktion. Das sind zwei unterschiedliche Ausübungen von Befugnis, und in der zweiten muss das Urteilsvermögen des Teams liegen. Sharkly macht diese Grenze explizit: Selbst mit verbundenem GitHub ändert das Mergen eines Pull Requests nicht den Task-Status. Der Merge bleibt eine menschliche Aktion, die dokumentiert wird – kein Seiteneffekt, den der Agent durch sein Fertigwerden auslöst.

Behalten Sie diese Grenze im Hinterkopf, denn die meisten Geschichten darüber, dass „der Agent die Produktion zerschossen hat", sind in Wahrheit Geschichten über ein fehlendes Gate zwischen Vorschlag und Merge.

Das Betriebsmodell: zuweisen, ausführen, prüfen, abnehmen

Sharkly teilt eine Task in vier Rollen auf, jede mit genau einer Aufgabe. Der Vertrag ist klar: Agents recherchieren, führen aus, testen und berichten; Menschen geben die Richtung vor, erteilen Befugnisse und nehmen das Ergebnis ab.

• Zuweisen. Eine Person beschreibt den Bedarf und legt den Assignee fest. Eine Task trägt zwei getrennte Zuweisungen: die People auf ihr und einen einzelnen Ausführungs-Assignee, also den Agent oder die Crew, die die Arbeit ausführt. Das Ändern der einen ändert nicht die andere.
• Ausführen. Der Ausführungs-Assignee erledigt die Arbeit in einem isolierten Git-Worktree, sodass parallele Läufe nicht die Dateien des jeweils anderen berühren. Fortschritt, Blocker und Ergebnisse fließen zurück in die Task.
• Prüfen. Wenn der Agent fertig ist, hinterlässt er die Task im Zustand „wartet auf menschliches Review", statt sie zu schließen. Der Diff, die Testausgabe und die Änderungszusammenfassung hängen an der Task, nicht an einem Terminal.
• Abnehmen. Eine Person liest die Belege und entscheidet: Änderungen anfordern oder abnehmen und mergen. Die Abnahme ist der abschließende Schritt, und nur ein Mensch vollzieht ihn.

Der Wert liegt hier nicht darin, dass Sharkly den Agent ausführt. Sondern darin, dass die vier Rollen an einem Ort sichtbar bleiben, statt in irgendeinem zufällig geöffneten Terminal zu verschwimmen. Eine ausführlichere Betrachtung der Review-Hälfte finden Sie unter Human-in-the-Loop-Coding-Agents.

Machen Sie das Gate zu einem Status, nicht zu einer Gewohnheit

Ein Gate, an das Sie sich erinnern müssen, ist ein Gate, das Sie irgendwann überspringen. Verankern Sie es deshalb im Lebenszyklus der Task.

Sharklys Status tragen über ihre Kategorien eine Systembedeutung. Backlog ist ein Parkzustand: Eine Task dort wird nicht ausgeführt, selbst wenn ein Agent zugewiesen ist. Erst wenn sie in eine Kategorie für Arbeitsbereitschaft verschoben wird, kann die Ausführung beginnen. Completed ist terminal, und dorthin zu gelangen ist ein menschlicher Schritt – nichts, was der Agent sich selbst zugesteht.

Der Task-Status ist bewusst vom Arbeitszustand des Agent getrennt. Während der Lebenszyklus-Status In Progress lautet, kann der Agent darunter arbeiten, auf eine menschliche Antwort warten, auf ein menschliches Review warten oder einen Fehler melden. Diese Trennung ist das Gate: Der Agent kann seinen Lauf beenden und „wartet auf menschliches Review" anzeigen, ohne dass die Task je in einen Zustand übergeht, der impliziert, dass sie ausgeliefert wurde. Die Arbeit kehrt zur Task zurück und bleibt dort stehen, bis jemand sie abnimmt.

Das ist auch der Grund, warum mehrere Agents sicher gleichzeitig laufen können. Wenn fünf parallele Agents in isolierten Worktrees alle in derselben Review-Spalte landen, haben Sie einen Ort, um sie zu triagieren, statt fünf Terminals zu beaufsichtigen.

Ein durchgerechnetes Beispiel: vom Ticket zum gemergten PR

Gehen wir eine einzelne Task durch – mit dem Bezeichnerformat SH-312 von Sharkly.

1. Anlegen. Eine Person erstellt SH-312, eine Bug-Task: „Die Suche liefert nach einer Filteränderung veraltete Ergebnisse." Die Beschreibung enthält das Ziel, die Reproduktion und die Abnahmekriterien. Assignee: ein Claude-Code-Agent, der an das Such-Repository gebunden ist.
2. Ausarbeiten. Der Agent recherchiert die Codebasis und die zugehörige Historie, bestätigt den Umfang und stellt seinen Plan in der Task ein. Die Person liest den Plan und verschiebt SH-312 aus Backlog in einen bereiten Status – das ist das Signal zum Start.
3. Ausführen. Der Agent übernimmt die Task und arbeitet in einem frischen Worktree. Er schreibt den Fix, führt Typecheck und die Testsuite aus und öffnet einen Pull Request, dessen Titel SH-312 enthält, damit Sharkly den PR mit der Task verknüpft.
4. Am Gate stoppen. Der Agent merged nicht. Er hängt die Änderungszusammenfassung, die erfolgreiche Testausgabe und bekannte Einschränkungen an und lässt SH-312 auf menschliches Review warten. Die Arbeit ist zur Task zurückgekehrt.
5. Prüfen. Eine Person öffnet SH-312, liest den Diff und die Belege in einer Ansicht und bemerkt, dass der Fix einen gemeinsamen Query-Helper berührt hat. Sie hinterlässt einen Kommentar mit der Bitte um eine engere Änderung. Bei einer Task mit bereitem Agent-Assignee stellt dieser Kommentar den Lauf erneut in die Warteschlange, sodass die Schleife „Änderungen anfordern" dokumentiert bleibt, statt in einem privaten Chat neu zu beginnen.
6. Abnehmen und mergen. Der zweite Lauf besteht das Review. Die Person genehmigt den Pull Request, mergt ihn und verschiebt SH-312 nach Completed. Da das Mergen die Task nicht automatisch schließt, sind die Abnahme und der Merge zwei dokumentierte menschliche Entscheidungen – keine automatische Kaskade.

Jeder Schritt in dieser Kette ist später nachvollziehbar – genau darum geht es bei einem nachvollziehbaren Workflow von den Anforderungen zum Code: Sie können die Frage „Wer hat das freigegeben, und auf welcher Grundlage?" beantworten, ohne in jemandes Scrollback archäologische Arbeit zu betreiben.

Wo Sie kein Gate setzen sollten

Mehr Gates sind nicht automatisch sicherer; sie erzeugen Reibung, die Menschen dazu erzieht, einfach durchzuklicken. Setzen Sie ein Gate dort, wo ein falscher Merge echte Kosten verursacht. Bei einer kleinen, klar abgegrenzten Änderung mit geringem Risiko, die einem einzelnen Agent zugewiesen ist, reicht der Stopp vor dem Merge aus, und Sie brauchen weder eine Crew noch zusätzliche Freigabeschritte darüber. Ziehen Sie ein schwereres Review in Betracht, wenn der Blast Radius groß ist: geteilter Code, Migrationen, alles, was Auth oder Abrechnung berührt.

Das eine Gate, das Sie niemals entfernen, ist das Merge-Gate. Ein Agent kann den ganzen Tag recherchieren, schreiben, testen und vorschlagen. Ob seine Änderung Ihren Main-Branch erreicht, ist eine menschliche Entscheidung, und das sollte sie bleiben, auch wenn der Agent in den meisten Fällen recht hat. Kombinieren Sie das Review auf Task-Ebene von Sharkly mit Ihrem bestehenden Branch Protection, damit die Plattform durchsetzt, was der Workflow beabsichtigt, und behalten Sie die Tools bei, die Ihr Team ohnehin nutzt: Verbinden Sie GitHub und weisen Sie das Ticket einem KI-Agent zu, ohne Ihren Prozess neu aufzubauen.

Wenn Sie bereits mehrere Coding-Agents laufen lassen und den Überblick verlieren, welcher fertig ist, welcher fehlgeschlagen ist und welcher auf Sie wartet, dann ist diese Review-Spalte der Grund, Sharkly auszuprobieren. Lassen Sie Ihre bestehenden Agents darüber laufen und behalten Sie die Merge-Entscheidung dort, wo sie hingehört.

FAQ

Kann Sharkly verhindern, dass ein Agent von selbst mergt? Ja. Das Mergen eines Pull Requests ändert den Status einer Task in Sharkly nicht, sodass ein Lauf bei „wartet auf menschliches Review" endet, statt eine Änderung zu mergen. Kombinieren Sie das mit GitHub Branch Protection, um erforderliche Reviews auf Repository-Ebene zu erzwingen.

Worin unterscheiden sich Task-Status und Agent-Status? Der Task-Status ist die Lebenszyklus-Kategorie (Backlog, Started, Completed und so weiter). Der Agent-Status beschreibt, was der Lauf gerade tut: arbeiten, auf eine menschliche Antwort warten, auf ein Review warten oder Fehler melden. Eine Task kann In Progress bleiben, während der Agent auf Sie wartet.

Brauche ich für jede geprüfte Task eine Crew? Nein. Bei kleinen, klar abgegrenzten Arbeiten weisen Sie die Task einem einzelnen Agent zu und nutzen das Gate vor dem Merge. Eine Crew ist für Ziele reserviert, bei denen ein Lead-Agent mehrere Mitglieder koordinieren muss.