Coding-Agenten im Hintergrund: Pull Requests, Queues und Review

Ein Coding-Agent war früher etwas, dem man zusieht. Man tippt eine Anfrage, bestätigt jeden Befehl und wartet auf den Diff. Die aktuelle Generation von Cloud-Agenten hat diese Interaktion verändert: Man übergibt eine Aufgabe an eine Queue, klappt den Laptop zu und kommt zu einem Branch oder einem Pull Request zurück. OpenAI Codex Cloud, der GitHub Copilot Cloud Agent, Claude Code Cloud-Sessions und Google Jules folgen demselben Muster, mit unterschiedlichen Grenzen und unterschiedlichen Vorstellungen davon, was der Agent berühren darf.

Das klingt nach einem Komfortfeature. Es ist eine Änderung der Arbeitseinheit. Ein asynchroner Agent produziert Artefakte, die andere prüfen müssen, und jede Schwachstelle im Repository-Workflow wird in Maschinengeschwindigkeit sichtbar: vage Issues, langsame CI, fehlende Branch Protection, ein ungelesener Backlog. Die DORA-Studie 2025 fand, dass 90% der Technologiefachleute KI bei der Arbeit nutzen und 30% wenig oder kein Vertrauen in KI-generierten Code haben; dieselbe Studie verbindet höhere Adoption mit mehr Durchsatz und mehr Instabilität. Dieser Beitrag handelt vom Workflow um den Agenten — Queue, Sandbox, CI-Gate, menschliches Review, Kostenmessung und Fehlerbilder.

Warum asynchron die Arbeitseinheit verändert

Ein synchroner Agent wartet auf dich, sein Durchsatz ist deine Aufmerksamkeit. Ein asynchroner Agent läuft unbeaufsichtigt, verbraucht ein Budget und produziert Arbeit, die in dieselbe Review-Pipeline kommt wie der Branch einer Kollegin. Der Deal sind parallele Versuche gegen Verifikationsarbeit — und nur Aufgaben mit maschinell prüfbarer Definition von „fertig“ gehören in diesen Deal.

Aufbau einer asynchronen PR-Pipeline

Zieht man das Branding ab, ist die Pipeline überall gleich. Eine Aufgabe kommt in eine Queue; ein Worker richtet eine Umgebung ein; der Agent bearbeitet Dateien und führt Befehle aus; das Ergebnis wird ein Branch und ein Pull Request; die CI läuft; ein Mensch reviewt; der Merge passiert oder schickt die Aufgabe zurück. Die interessanten Unterschiede liegen in den Limits jeder Stufe, nicht im Diagramm.

Zwei Eigenschaften trennen eine Aufgabe von einem Chat: Der Agent braucht eine prüfbare Definition von fertig, und die Umgebung muss reproduzierbar genug sein, dass ein grüner Lauf etwas bedeutet. Ein Agent, der die Testsuite nicht ausführen kann, rät, und ein Pull Request voller Vermutungen ist schlechter als keiner. Die Mechanik der Schleife steht in der Agent-Loop, erklärt.

Das sind Standardwerte, keine Obergrenzen. Self-hosted Runner, eigene Umgebungen und größere Runner verschieben einige davon. Was sich nicht verschiebt, ist die Form: Queue, begrenzte Ausführungsumgebung, Branch, Gate und Reviewer.

Die Queue ist das Produkt

Ein asynchroner Agent kann nicht fragen, was du gemeint hast — oder doch, aber die Antwort kommt Stunden später. Der Queue-Eintrag ist deshalb die Spezifikation: ein beobachtbares Ziel, der Befehl, der es beweist, die erlaubten Pfade und die Nicht-Ziele. Wenn das Issue-Template das nicht ausdrücken kann, ist die Aufgabe nicht bereit.

Duplikate sind das klarste Zeichen eines Queue-Problems. In einer manuell kodierten Stichprobe von 600 abgelehnten Agent-PRs wurden 142 — 23% — geschlossen, weil die Arbeit bereits anderswo existierte. Der Agent hat keinen schlechten Code geschrieben, sondern Code, den niemand brauchte. Vor dem Einreihen deduplizieren, nicht nach dem Öffnen des PR.

type AgentTask = {
  id: string;                 // dedupe key: repo + issue + base commit
  repo: string;
  base: string;
  goal: string;               // one sentence, testable
  acceptance: string[];       // observable outcomes
  testCommand: string;        // the agent must run this
  allowedPaths: string[];     // everything else is out of scope
  maxMinutes: number;
  maxCiRetries: number;
};

Den Umschlag mit dem Task speichern und die ID als Dedupe-Key nutzen: Repository, Issue und Basis-Commit. Bewegt sich der Basis-Branch, gegen ihn neu laufen lassen statt einen zweiten PR zu öffnen. Eine Queue ohne WIP-Limit ist ein PR-Generator; ich begrenze Tasks pro Reviewer, nicht pro Agent.

Sandboxes: was der Agent berühren darf

Drei Grenzen bestimmen den Blast Radius: was der Agent schreiben darf, was er im Netz erreicht und welche Credentials er ausgeben kann. Die gehosteten Produkte entscheiden unterschiedlich, und die Unterschiede zählen mehr als der Modellname im Task-Umschlag.

GitHubs Copilot Cloud Agent läuft in einer ephemeren GitHub-Actions-Umgebung mit standardmäßig aktiver Firewall, kann nur auf einen einzigen Branch pushen und führt git push nicht selbst aus. Codex Cloud führt Setup-Skripte mit Internetzugang aus und schaltet das Agent-Internet danach standardmäßig ab; Secrets sind nur im Setup verfügbar und werden vor der Agent-Phase entfernt. Claude Code Cloud hält Git-Credentials und Signing-Keys außerhalb der Sandbox und reicht sie über einen Proxy an.

Der Fehler ist, die Sandbox als ganzes Sicherheitsmodell zu behandeln. Ein Branch, auf dem CI mit Repository-Secrets läuft, ist ein Ausführungspfad, und ein Agent, der .github/workflows bearbeiten kann, kann diesen Pfad ändern. Copilots Standard ist lehrreich: Workflows aus seinen Pull Requests laufen erst, wenn ein User mit Schreibzugriff sie freigibt. Das ist eine eigene Kontrolle neben der Firewall, und du brauchst beide.

Lange Läufe, Timeouts und Wiederaufnahme

Asynchron heißt nicht unbegrenzt. Copilot begrenzt jede Session auf 59 Minuten und lässt keine Verlängerung zu. Claude Code cached ein Setup-Skript nur, wenn es in etwa fünf Minuten fertig wird, und idle Cloud-Sessions werden zurückgeholt. Codex cached Container-Zustand bis zu 12 Stunden — eine Performance-Eigenschaft, kein Versprechen, dass ein Task so lange laufen kann.

Für Unterbrechungen entwerfen: Checkpoints in den Branch committen, den Plan als Datei im Repository ablegen und den nächsten Lauf vom letzten grünen Commit starten. Ein Task, der einen Timeout nicht übersteht, hinterlässt einen halben PR und einen zweiten Task zum Aufräumen.

// Lease longer than the longest allowed run; heartbeat while the agent works.
const lease = await queue.claim({ visibilityTimeout: 90 * 60 });
try {
  const run = await sandbox.start({
    task: lease.task,
    network: "allowlist",
  });
  const result = await run.wait({ timeoutMs: lease.task.maxMinutes * 60_000 });
  if (result.exitCode !== 0) throw new Error(result.summary);
  await git.pushBranch(result.branch);
  await github.openDraftPr({ branch: result.branch, task: lease.task });
  await queue.ack(lease.id);
} catch (error) {
  await queue.nack(lease.id, { reason: String(error) });
}

Die Queue-Semantik zählt mehr als das Produkt: ein Visibility-Timeout länger als der maximale Lauf, ein Heartbeat, ein Ack erst nach dem PR und ein Dead-Letter-Pfad. GitHub Actions, SQS oder Temporal können das ausdrücken; ein Cronjob ohne Lease nicht.

CI ist der erste Reviewer

Branch Protection macht den Pull Request zum Gate. Required Checks können strikt sein (der Branch muss aktuell sein) oder locker (jetzt mergen, kaputte Basis riskieren). Eine Merge Queue testet den PR gegen die aktuelle Basis und die PRs davor, damit Grün auch für das gilt, was tatsächlich gemergt wird.

name: ci
on:
  pull_request:
  merge_group:

concurrency:
  group: ci-${{ github.ref }}
  cancel-in-progress: true

permissions:
  contents: read

jobs:
  test:
    runs-on: ubuntu-latest
    timeout-minutes: 20
    steps:
      - uses: actions/checkout@v5
      - uses: actions/setup-node@v4
        with: { node-version: 22, cache: npm }
      - run: npm ci
      - run: npm test -- --run

Ein Agent-PR ist ein fremder Beitrag mit vertrauenswürdig klingendem Autornamen. Deshalb gehören Workflow-Freigabe, minimale permissions und Branch Protection ins Design, nicht in eine Aufräumaufgabe danach. Dasselbe Prinzip steht in Harness Engineering für Coding-Agenten: Guides sagen dem Agenten, wie gut aussieht, Sensoren sagen ihm — und dir —, wenn es danebenging.

Ein roter Pipeline-Lauf kostet nicht nur den Re-Run. In der Studie mit 33.596 PRs war jeder zusätzliche fehlgeschlagene CI-Check mit etwa 15% geringeren Merge-Chancen verbunden. Ein fehlschlagender Check ist ein Ablehnungssignal, das sich verstärkt. Mach die Suite schnell und deterministisch, bevor du Agenten skalierst; sonst kaufst du Retries statt Durchsatz.

Menschliches Review ist der Engpass

Das empirische Bild ist interessanter als die Anekdote. Ehsani und Kollegen analysierten 33.596 von fünf Coding-Agenten erstellte Pull Requests: 71,48% wurden gemergt. In einer manuell kodierten Stichprobe von 600 abgelehnten PRs war Reviewer-Abbruch mit 38% die größte Kategorie, gefolgt von Duplikaten mit 23% und CI- oder Testfehlern mit 17%. Nur 2% wurden als Probleme auf Agentenebene eingestuft. Peralta und Kollegen untersuchten 11.048 geschlossene Agent-PRs und fanden, dass nur 35,7% der Ablehnungen klare Agent-Fehler waren; 31,2% waren Workflow-Einschränkungen und 33,1% hatten keine beobachtbare Begründung.

Die Schlussfolgerung ist nicht, dass Agenten gut oder schlecht sind. Merge-Ergebnisse messen den Workflow genauso wie das Modell. Ein Duplikat und ein verwaister PR sind Queue-Fehler. Ein roter CI-Lauf ist oft ein Umgebungsfehler. Wer nur den Code des Agenten instrumentiert, liest alle drei als Modellqualität.

• Den Pull Request als Draft öffnen, mit Aufgabe, Testbefehl und einer kurzen Zusammenfassung der Änderung. Der Reviewer soll die Anfrage nicht aus dem Diff rekonstruieren müssen.
• Grüne Required Checks verlangen, bevor der PR als bereit markiert werden darf. Ein Draft, der grün wird, ist ein Signal; ein Draft, der grün ist, weil die CI nie lief, ist eine Falle.
• Die Tests als eigene Änderung reviewen. Fragen, ob ein Test ohne die Produktionsänderung fehlschlagen würde und ob eine Assertion aufgeweicht wurde.
• Einen Reviewer pro Aufgabe verantwortlich machen, seine Drafts begrenzen und nie den Anforderer als einzigen Approver zulassen. Copilot erzwingt die letzte Regel; Branch Protection kann sie für jeden anderen Agenten erzwingen.

Das ist dasselbe Kapazitätsproblem wie in AI-Code-Review ist jetzt der Engpass und dieselbe Designfrage wie bei Human in the Loop für AI-Agenten: Wo muss ein Mensch hinschauen, und wofür haftet er? Bei einem Agent-PR sind das der Diff, die Tests und das Rollout-Risiko — nicht die Zusammenfassung des Agenten.

Kosten pro Aufgabe steuern, nicht pro Token

Ein asynchroner Agent hat vier Zähler: Modell-Tokens, CI-Minuten, Sandbox-Zeit und menschliches Review. Die ersten drei stehen auf einer Rechnung. Der vierte entscheidet, ob sich der Workflow überhaupt rechnet.

Die Anbieter messen unterschiedlich. GitHub hat Copilot am 1. Juni 2026 auf nutzungsbasierte Abrechnung umgestellt: Modellnutzung wird in AI Credits abgerechnet, die Infrastruktur des Agenten verbraucht Actions-Minuten. Codex-Cloud-Tasks teilen sich das Plan-Kontingent mit lokalen Nachrichten, und OpenAI schätzt einen typischen GPT-5.6-Sol-Task auf 2 bis 15 Credits. Claude Code Cloud-Sessions zählen aufs Plan-Limit, ohne separate VM-Gebühr. Jules verkauft Task-Zahlen und Parallelität: 15/3 im Einstieg, 100/15 bei Pro, 300/60 bei Ultra.

Miss Kosten pro gemergtem Pull Request, nicht pro Session: Tokens plus CI plus Sandbox plus Review-Minuten, geteilt durch gemergte PRs. Ein billiger Task, der nie mergt, ist teuer; ein teurer Task, der eine Woche Arbeit erspart, ist billig. Begrenze die Parallelität, bevor du Prompts optimierst.

Fehlerbilder und die passende Leitplanke

Die Fehlerbilder sind vorhersehbar genug, um gegen sie zu entwerfen. Die Prozentzahlen stammen aus der manuell kodierten Stichprobe abgelehnter Agent-PRs; sie beschreiben also, wie Ablehnung aussieht, nicht die Basisrate über alle Aufgaben.

Ein weiteres Fehlerbild ist leicht zu übersehen, weil es wie Erfolg aussieht: Der Agent repariert den CI-Fehler, indem er den Test ändert. Eine grüne Pipeline ist nur dann Evidenz, wenn der Test den Bug gefunden hätte. Lies den Test-Diff vor dem Produktions-Diff und verlange bei einem Bugfix einen fehlschlagenden Test, der das Issue reproduziert.

Rollout, ohne in PRs zu ertrinken

Mit Arbeit beginnen, bei der Erfolg maschinell prüfbar und der Blast Radius klein ist. Die 33k-PR-Studie fand die höchsten Merge-Raten für Dokumentation (84%), CI (79%) und Build (74%) und die niedrigsten für Performance (55%) und Bugfixes (64%). Diese Reihenfolge ist ein sinnvoller Rollout-Plan.

1. Ein Repository und zwei Aufgabentypen wählen: Dokumentation und Testabdeckung sind der sicherste Start.
2. Das Task-Template mit Ziel, Akzeptanzkriterien, Testbefehl, erlaubten Pfaden und Nicht-Zielen schreiben.
3. Draft-PR, grüne Checks und eine menschliche Freigabe vor dem Merge verlangen. Branch Protection zuerst einschalten.
4. Parallele Arbeit pro Reviewer und pro Agent begrenzen. Die Queue messen, nicht den Tokenverbrauch des Agenten.
5. Merge-Rate, Review-Zeit, CI-Fehlerrate und Kosten pro gemergtem PR vier Wochen lang verfolgen, bevor du erweiterst.
6. Bugfixes erst dazunehmen, wenn die Testsuite verlässlich genug ist, dass ein grüner Lauf etwas bedeutet.

Ein asynchroner Agent ist ein Multiplikator auf den Workflow, in den er kommt. Mit schneller CI, klarer Verantwortung und kleinen PRs entfernt er Routinearbeit. Mit flaky Tests und fehlender Review-Kapazität produziert er einen Backlog mit besseren Commit-Messages.

Quellen

1. GitHub Docs: About GitHub Copilot cloud agent
2. GitHub Docs: Risks and mitigations for Copilot cloud agent
3. OpenAI Developers: Codex cloud environments
4. Anthropic: Use Claude Code in the cloud
5. Google Jules: Limits and plans
6. Google Jules: Getting started
7. GitHub Docs: About protected branches
8. GitHub Docs: Models and pricing for GitHub Copilot
9. OpenAI Developers: Codex pricing
10. Ehsani et al.: Where Do AI Coding Agents Fail? An Empirical Study of Failed Agentic Pull Requests in GitHub (MSR 2026, arXiv 2601.15195)
11. Peralta et al.: Why Are Agentic Pull Requests Merged or Rejected? An Empirical Study (MSR 2026, arXiv 2605.22534)
12. DORA: State of AI-assisted Software Development 2025