Kurzantwort: Wenn KI-Agenten Pull Requests prüfen sollen, übergeben Sie das Review einem zweiten Agenten mit eigenen Anweisungen, einem eigenen Checkout und nach Möglichkeit einem anderen Modell. Starten Sie ihn automatisch, sobald eine Aufgabe den Review-Status erreicht, lassen Sie ihn die Tests ausführen und ein Urteil (PASS oder CHANGES REQUIRED) abgeben und senden Sie Fehler direkt an den Builder-Agenten zurück. Gemergt wird weiterhin manuell durch einen Menschen.
Warum KI-Agenten Pull Requests vor Ihnen prüfen sollten
Jeder von einem Agenten erstellte Pull Request landet auf demselben Schreibtisch: Ihrem. Wenn ein einzelner Agent einen PR pro Stunde liefert, ist das kein Problem. Laufen jedoch fünf Agenten parallel, wächst die Warteschlange schneller, als Sie Diffs lesen können – und der erste Prüfdurchlauf wird zum Engpass.
Ein Reviewer-Agent übernimmt diese erste Prüfung. Er ersetzt nicht Ihr Urteilsvermögen, sondern filtert PRs heraus, die Tests nicht bestehen, den Rahmen der Aufgabe sprengen oder sensible Zugangsdaten preisgeben. So landen nur PRs bei Ihnen, die Ihre Zeit auch wert sind. In Sharkly richten Sie dies mit einem zusätzlichen Agenten und zwei Automatisierungen ein. Dieser Leitfaden führt Sie Schritt für Schritt durch alle Komponenten.
Wenn Sie zunächst mehr über die Grenzen automatisierter Reviews erfahren möchten, lesen Sie unseren Artikel darüber, was KI-Code-Review-Agenten überprüfen können und was nicht. In diesem Beitrag geht es um die praktische Einrichtung.
Warum ein Agent seinen eigenen Code nicht prüfen kann
Ein Agent, der den Code geschrieben hat, hat auch die Begründung dazu verfasst. Fordert man ihn auf, die eigene Arbeit zu überprüfen, liest er seine eigene Argumentationskette und stimmt sich selbst zu. Die toten Winkel, die den Fehler überhaupt erst verursacht haben, sind dieselben, die das Review durchführen.
Besonders deutlich zeigt sich das bei Tests. Ein Builder-Agent, der einen Test nicht fehlerfrei zum Laufen bringt, schwächt möglicherweise die Assertion ab und stuft die Aufgabe als erledigt ein. Diese Muster haben wir bereits in Wie Sie Coding-Agenten beim Schummeln bei Tests ertappen analysiert. Ein Reviewer ohne persönliches Interesse am Ergebnis betrachtet das Diff unvoreingenommen und stellt eine ganz andere Frage: Setzt diese Änderung genau das um, was die Aufgabe verlangt hat – und nicht mehr?
Das DeepSeek-Harness-Team kommt in seinem Design-Essay über Super-Agenten zu einer ähnlichen Aufteilung: Mehrere Worker, die demselben PR zugewiesen sind, sehen dessen Ereignisse und können Konflikte untereinander klären. Es beschreibt zwar den Entwurf eines Prototyps und kein fertiges Produkt, das Prinzip überzeugt jedoch: Reviews funktionieren deutlich besser, wenn der Prüfer eine unabhängige Instanz ist.
Schritt 1: Builder und Reviewer voneinander trennen
Erstellen Sie zwei separate Agenten statt eines einzelnen Agenten mit zwei Betriebsmodi. Jeder Agent erhält eigene Anweisungen, Repositories und Ausführungsumgebungen.
| Builder-Agent | Reviewer-Agent | |
|---|---|---|
| Aufgabe | Aufgabe implementieren, PR eröffnen | PR anhand der Anforderungen beurteilen |
| Schreibt Code | Ja | Nein |
| Pusht Code | Auf einen Feature-Branch | Niemals |
| Runtime | Beispielsweise Claude Code | Idealerweise eine andere, wie etwa Codex |
| Ergebnis | Branch, PR, zusammenfassender Kommentar | Prüfungsurteil als Kommentar |
Ein Sharkly-Agent verfügt über keine Modell-Auswahlbox. Sein Ausführungsziel ist ein Computer mit einer darauf erkannten Runtime. „Ein anderes Modell verwenden“ bedeutet daher, den Reviewer an eine andere Runtime zu binden. Eine zweite Runtime bringt einen frischen Blickwinkel auf das Diff mit. Jeder Durchlauf wird über den Tarif abgerechnet, der dieser Runtime bereits zugewiesen ist, da Sharkly selbst keine Token vertreibt.
Setzen Sie das Arbeitsverzeichnis des Reviewers auf den Temporary-Modus. Die Computers-Dokumentation erläutert, wie jeder Durchlauf dadurch ein isoliertes Verzeichnis erhält und Repository-Ausführungen einen frischen Git-Worktree vorbereiten können. Der Reviewer checkt den PR-Branch in seiner eigenen Arbeitskopie aus und kann so die Dateien des Builders nicht überschreiben. Warum dies unverzichtbar ist, sobald sich mehrere Agenten ein Repository teilen, beschreibt unser Beitrag über parallele Agenten in isolierten Worktrees.
Schritt 2: Die Anweisungen für den Reviewer verfassen
Die Anweisungen des Agenten definieren die Rolle, die durchzuführenden Prüfungen sowie das Berichtsformat. Details zur konkreten Aufgabe bleiben bei der Aufgabe selbst. Halten Sie die Instruktionen für den Reviewer kurz und klar überprüfbar:
You are the code reviewer for this Space. You never push, merge or edit files.
1. Read the triggering task. If it is not a code task in this Space, reply "not mine" and stop.
2. Find the linked pull request (the task ID appears in its title, description or branch).
3. Check out the PR branch in your worktree. Run the test command from the repo README.
4. Compare the diff to the task's acceptance criteria.
5. Post one verdict comment on the task in the format below. Nothing else.
Der erste Schritt ist entscheidender, als es den Anschein hat. Status- und Kommentar-Trigger reagieren aktuell organisationsweit, weshalb die Anweisungen die Aufgabe vorab verifizieren müssen, bevor Aktionen ausgeführt werden. Dies wird auch in der Dokumentation zu Automatisierungen ausdrücklich hervorgehoben.
Schritt 3: Den passenden Trigger wählen
Automatisierungen in Sharkly kombinieren Anweisungen, einen Agenten oder eine Crew und einen oder mehrere Trigger. Für das PR-Review bieten sich zwei Trigger an.
Änderung des Aufgabenstatus. Fügen Sie Ihrem Space-Workflow einen Status wie beispielsweise „In Review“ hinzu. Der Builder verschiebt seine Aufgabe nach dem Eröffnen des PRs dorthin, woraufhin der Reviewer automatisch startet. Ein durch eine Statusänderung ausgelöster Durchlauf erstellt eine Konversation direkt an dieser Aufgabe, sodass das Prüfungsurteil und der Token-Verbrauch unmittelbar mit der Arbeit verknüpft bleiben.
Dieser Screenshot zeigt den Prüfprozess, den dieser Blog für seine eigenen Entwürfe nutzt: Eine Aufgabe erreicht den Status „Ready for Release“ und wird von einem Reviewer-Agenten übernommen. Für Code funktioniert das Verfahren exakt genauso.
Webhook. Werden Pull Requests außerhalb Ihres Aufgaben-Boards geöffnet, leiten Sie einen pull_request-Webhook von GitHub an die Webhook-URL einer Automatisierung weiter. Bei aktivierter Signaturprüfung unterstützt Sharkly auch den Header X-Hub-Signature-256 von GitHub; das Signatur-Secret tragen Sie einfach in das entsprechende GitHub-Feld ein. Da Webhook-Durchläufe nicht an eine Aufgabe gekoppelt sind, postet der Reviewer sein Urteil stattdessen über das GitHub CLI direkt in den PR.
Testen Sie beide Varianten vorab mit „Run now“, bevor Sie sich im Produktivbetrieb darauf verlassen.
Schritt 4: Dem Reviewer eine Checkliste an die Hand geben
Ein Reviewer ohne Checkliste neigt zu langen Aufsätzen. Mit einer Checkliste liefert er konkrete Ergebnisse. Fünf Fragen decken die meisten von Agenten erstellten PRs zuverlässig ab:
- Werden die Tests ausgeführt und bestanden? Der Reviewer führt die Tests selbst aus und verlässt sich nie auf die Zusammenfassung des Builders.
- Wurde der Aufgabenrahmen eingehalten? Dateien, die außerhalb des Aufgabenbereichs geändert wurden, gelten als Befund – selbst wenn die Änderung harmlos erscheint.
- Werden Secrets offengelegt? Achten Sie auf Token, API-Schlüssel oder
.env-Werte im Diff oder in den Logs. - Entstehen Breaking Changes für Aufrufer? Geänderte Funktionssignaturen, entfernte Endpunkte oder Migrationen ohne Rollback-Strategie.
- Wurden Tests abgeschwächt? Gelöschte Assertions, neu hinzugefügte Skips oder aufgeweichte Erwartungswerte.
Hinterlegen Sie die Liste in einem Skill, falls mehrere Reviewer-Agenten darauf zugreifen, damit eine einzige Änderung automatisch für alle gilt.
Schritt 5: Ein festes Urteilsformat definieren
Ein Urteil, das ein Mensch in zehn Sekunden erfassen kann, ist wertvoller als eine ausführliche Analyse, die ungelesen bleibt. Verwenden Sie ein festes Format:
VERDICT: CHANGES REQUIRED
Tests: 41 passed, 2 failed (test_refund_rounding, test_refund_zero)
Scope: OK, 3 files, all under billing/
Secrets: none found
Breaking changes: refund() now raises on amount=0; two callers in api/ not updated
Weakened tests: none
Required:
1. Handle amount=0 in refund() or update both callers.
2. Fix the rounding in test_refund_rounding; do not change the expected value.
Ein PASS-Urteil enthält dieselben Felder, lässt die Liste unter „Required“ jedoch leer. Feste Felder machen die Ergebnisse zudem messbar: Sie können auswerten, wie oft einzelne Prüfungen fehlschlagen, und die Instruktionen des Builders gezielt nachschärfen.
Schritt 6: Den Regelkreis zum Builder schließen
Ein CHANGES REQUIRED-Urteil sollte den Builder automatisch wieder anstoßen, ohne dass Sie manuell eingreifen müssen. Erstellen Sie hierfür eine zweite Automatisierung, die dem Builder-Agenten zugewiesen ist und auf eine markante Textpassage in Kommentaren reagiert.
Der Kommentar-Trigger ignoriert Groß- und Kleinschreibung und löst aus, sobald der Text irgendwo im Kommentar vorkommt. Wählen Sie eine Formulierung, die niemand versehentlich eingibt, und weisen Sie den Reviewer an, diese ausschließlich in der CHANGES REQUIRED-Zeile zu verwenden. Zitiert der Builder diesen Satz in seiner Antwort, könnte er sich selbst triggern – untersagen Sie ihm daher ausdrücklich, die Phrase zu wiederholen.
Begrenzen Sie die Schleife: Nach zwei Runden aus Review und Korrektur übergibt der Reviewer die Aufgabe mitsamt seinem letzten Prüfergebnis an einen Menschen.
Was weiterhin in Menschenhand bleibt
Das Mergen bleibt Ihre Aufgabe. In der GitHub-Integration von Sharkly verknüpft eine Aufgaben-ID im PR-Titel den PR mit der Aufgabe; ein Merge ändert den Status der Aufgabe jedoch nicht automatisch. Nichts wird deployed, nur weil ein Agent PASS gemeldet hat.
Sichern Sie dies auch auf GitHub-Ebene ab: Durch Protected Branches mit erforderlicher menschlicher Freigabe verhindern Sie, dass ein übereifriger Reviewer-Agent zur letzten Instanz wird. Zudem obliegen Ihnen strategische Entscheidungen, die eine Checkliste nicht treffen kann: Ist der Architekturentwurf stimmig und sollte das Feature überhaupt existieren? Wie Sie eingehende Reviews optimal priorisieren, erfahren Sie in unseren Beiträgen zur Priorisierung der Agenten-PR-Warteschlange und darüber, warum menschliche Reviews zum Engpass werden.
Fazit
Agenten-PRs wachsen Ihnen nicht mehr über den Kopf, sobald ein zweiter Agent die Vorprüfung übernimmt. Trennen Sie Builder und Reviewer, weisen Sie dem Reviewer einen eigenen Worktree sowie eine eigene Runtime zu, starten Sie ihn per Statuswechsel oder Webhook und lassen Sie ihn fünf feste Prüfpunkte in einem standardisierten Format beantworten. Leiten Sie Korrekturen über eine eindeutige Kommentarphrase zurück, limitieren Sie die Schleife auf zwei Durchläufe und behalten Sie den Merge-Vorgang stets in eigener Hand.
Wenn Sie bereits zehn Coding-Agenten gleichzeitig betreiben, ist dies der nächste logische Schritt. Starten Sie kostenlos mit Sharkly und richten Sie Ihren ersten Reviewer-Agenten ein.
FAQ
Kann ein KI-Agent seinen eigenen Pull Request prüfen?
Grundsätzlich ja, allerdings übersieht er dabei deutlich mehr. Der Agent teilt die Denkweisen und Annahmen, die zum Code geführt haben. Ein separater Reviewer mit eigenen Anweisungen und idealerweise einer anderen Runtime liest das Diff unvoreingenommen.
Sollte der Reviewer ein anderes Modell als der Builder nutzen?
Ja, sofern möglich. In Sharkly wird das Modell über die Runtime definiert. Weisen Sie dem Reviewer-Agenten daher eine andere Runtime als dem Builder zu – beispielsweise Codex, um die Ergebnisse von Claude Code zu prüfen.
Was sollte ein KI-Code-Reviewer zuerst prüfen?
Die Tests. Lassen Sie den Agenten die Testsuite selbst ausführen und die Anzahl bestandener sowie fehlgeschlagener Tests protokollieren. Danach folgen Scope, Secrets, Breaking Changes und abgeschwächte Tests – genau in dieser Reihenfolge.
Kann ein Reviewer-Agent einen PR genehmigen und mergen?
Das sollten Sie nicht zulassen. Behalten Sie die Merge-Rechte über Branch-Protection-Regeln bei menschlichen Entwicklern. Der Reviewer gibt eine Beurteilung ab; die finale Entscheidung trifft ein Mensch.
Wie verhindere ich, dass die Review-Schleife endlos läuft?
Begrenzen Sie den Ablauf in den Instruktionen des Reviewers auf maximal zwei Durchläufe und nutzen Sie eine Kommentarphrase, die der Builder keinesfalls wiederholt. Nach Erreichen des Limits übergibt der Reviewer die Aufgabe an einen Menschen.
Funktioniert das auch mit GitHub-Pull-Requests, die außerhalb von Sharkly geöffnet wurden?
Ja. Verbinden Sie dazu einen GitHub-Webhook mit dem Webhook-Trigger einer Automatisierung. Bei aktivierter Prüfung akzeptiert Sharkly den Signatur-Header von GitHub problemlos.
