> Wie asynchrone Coding-Agenten Tasks einreihen, in Sandboxes laufen, Draft-PRs öffnen und CI passieren. Grenzen, Kosten, Review und Fehlerbilder.
>
> Web page: https://balazscsorba.com/de/blog/background-agents-async-pr-workflow · Language: Deutsch · Also available in: [English](https://balazscsorba.com/blog/background-agents-async-pr-workflow.md) · [Magyar](https://balazscsorba.com/hu/blog/background-agents-async-pr-workflow.md)
> Author: Balázs Csorba · Published: 2026-10-17 · Keywords: background coding agent, async coding agent, cloud coding agent pull request, copilot coding agent limits, codex cloud tasks, claude code cloud sessions, jules coding agent limits, agent pull request review, coding agent sandbox, agent CI gating, cost per merged pull request

[Blog](https://balazscsorba.com/de/blog)/KI-Agenten

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

Wie asynchrone Coding-Agenten Tasks einreihen, in Sandboxes laufen, Draft-PRs öffnen und CI passieren. Grenzen, Kosten, Review und Fehlerbilder.

[Balázs Csorba](https://balazscsorba.com/de/about)·17\. Oktober 2026·12 Min. Lesezeit

-   Coding agents
-   Pull requests
-   CI
-   Code review
-   Automation

![Eine Karte in einer Ablage fächert sich zu fünf Feldern auf, alle Pfeile führen zu einer Seite hinter einem Tor.](https://balazscsorba.com/images/blog/background-agents-async-pr-workflow/cover.webp?v=3ffd1f8c72)

## Das Wichtigste in Kürze

-   Ein asynchroner Coding-Agent verschiebt den Engpass vom Schreiben von Code zum Definieren der Aufgabe, zum CI-Lauf und zum Review des Ergebnisses.
-   Der Queue-Eintrag ist die Spezifikation: ein beobachtbares Ziel, ein Testbefehl, erlaubte Pfade und explizite Nicht-Ziele.
-   Sandbox, Branch Protection, Workflow-Freigabe und Required Checks sind getrennte Kontrollen; eine Sandbox schützt den Host, nicht das Repository.
-   Jeden Lauf zeitlich begrenzen und jede Aufgabe budgetieren; die nützliche Kostenmetrik sind Kosten pro gemergtem Pull Request.
-   Die meisten abgelehnten Agent-PRs scheitern an Koordination, CI und Review-Kapazität, nicht an der Modellfähigkeit.

Auf dieser Seite

1.  [Warum asynchron die Arbeitseinheit verändert](https://balazscsorba.com/#why-async-agents)
2.  [Aufbau einer asynchronen PR-Pipeline](https://balazscsorba.com/#anatomy)
3.  [Die Queue ist das Produkt](https://balazscsorba.com/#task-queue)
4.  [Sandboxes: was der Agent berühren darf](https://balazscsorba.com/#sandbox)
5.  [Lange Läufe, Timeouts und Wiederaufnahme](https://balazscsorba.com/#long-runs)
6.  [CI ist der erste Reviewer](https://balazscsorba.com/#ci-gating)
7.  [Menschliches Review ist der Engpass](https://balazscsorba.com/#human-review)
8.  [Kosten pro Aufgabe steuern, nicht pro Token](https://balazscsorba.com/#cost-control)
9.  [Fehlerbilder und die passende Leitplanke](https://balazscsorba.com/#failure-modes)
10.  [Rollout, ohne in PRs zu ertrinken](https://balazscsorba.com/#rollout)
11.  [Quellen](https://balazscsorba.com/#sources)

Diesen Artikel anhören

0:000:00

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.

Die Schleife ist der wichtige Teil. Eine Pipeline, die einen Fehllauf nicht mit Kontext zurückschickt, macht aus jedem CI-Fehler eine neue Aufgabe.

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](https://balazscsorba.com/de/blog/agent-loop-explained).

System

Einstieg

Isolation und Netz

Veröffentlichte Grenzen

GitHub Copilot Cloud Agent

Issue zuweisen, `@copilot` erwähnen oder im Agents-Panel starten

Ephemere Umgebung auf GitHub Actions; Firewall standardmäßig an

59 Minuten pro Session; ein Branch und ein PR pro Task; kann nicht approven oder mergen

OpenAI Codex Cloud

Task in Codex Cloud oder aus GitHub, Linear und Slack

Container pro Task; Agent-Internet standardmäßig aus; Setup-Secrets vor der Agent-Phase entfernt

Container bis zu 12 Stunden gecacht; PR auf Anfrage

Claude Code Cloud

`claude.ai/code`, `claude --cloud` oder eine Routine

Anthropic-verwaltete VM; begrenztes Netz; Git-Credentials außerhalb der Sandbox

Zählt aufs Plan-Limit; idle Sessions laufen ab

Google Jules

Prompt, `jules`\-Label oder API-Session

Google-Cloud-VM mit Internetzugang

15, 100 oder 300 Tasks pro Tag; 3, 15 oder 60 gleichzeitig

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.

**Eine Sandbox schützt den Host, nicht das Repository**

Isolation hindert einen Agenten daran, deinen Laptop oder die Daten der Nachbarn zu lesen. Sie hindert ihn nicht an einem schlechten Commit, einem aufgeweichten Test oder einem bearbeiteten Workflow, der später Secrets erhält. Behandle jeden Agent-Branch als fremden Beitrag: Default-Branch schützen, Checks und Review verlangen, die Freigabe von Workflow-Läufen einschränken und `CODEOWNERS` auf CI- und Testdateien setzen. Die [AI-Agent-Sandbox-Checkliste](https://balazscsorba.com/de/blog/sandboxing-coding-agents-ci-checklist) geht die Schichten der Reihe nach durch.

## 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](https://balazscsorba.com/de/blog/harness-engineering-coding-agents): 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](https://balazscsorba.com/de/blog/ai-generated-pr-review-bottleneck) und dieselbe Designfrage wie bei [Human in the Loop für AI-Agenten](https://balazscsorba.com/de/blog/human-in-the-loop-ai-agents): 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.

Zähler

Was ihn verbraucht

Hebel

Modell-Tokens

Input-Kontext, Thinking, Tool-Calls und Output pro Turn

Engerer Task-Zuschnitt, kleineres Modell wo es hält, maximale Turns

CI-Minuten

Jeder Push, jeder Re-Run und die Merge Queue

Fail fast, überholte Runs abbrechen, flaky Tests reparieren

Sandbox-Zeit

VM- oder Container-Minuten inklusive Setup

Dependencies cachen, Wall Clock begrenzen, idle Sessions stoppen

Menschliches Review

Die knappste und am wenigsten instrumentierte Ressource

Kleine Diffs, WIP-Limit pro Reviewer, Draft zuerst

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.

Fehler

Symptom

Leitplanke

Doppelte Arbeit

Zwei PRs für dasselbe Issue; einer wird als überholt geschlossen (23% der abgelehnten Stichprobe)

Dedupe-Key, Claim-Label, offene und kürzlich geschlossene PRs vor dem Einreihen durchsuchen

Rot bei Ankunft

Der Agent öffnet einen PR, der sofort an der CI scheitert (17%)

Testbefehl in der Sandbox ausführen; bereit für Review erst nach grünen Checks

Reviewer-Abbruch

Der PR bekommt kein nennenswertes Review und wird veraltet geschlossen (38%)

Reviewer beim Öffnen zuweisen, SLA setzen, veraltete Drafts automatisch schließen

Aufgeweichte Tests

Der Diff lässt den Test bestehen, indem er Assertions löscht oder lockert

CODEOWNERS auf Tests, Test-Diff separat reviewen, zuerst einen fehlschlagenden Test verlangen

Prompt Injection

Versteckte Anweisungen in Issue, README oder Dependency-Seite steuern den Agenten

Issue-Text als nicht vertrauenswürdig behandeln, versteckte Zeichen filtern, keine Secrets in der Agent-Phase, Netz-Allowlist

Scope Creep

Aus einer kleinen Aufgabe wird ein Multi-File-Rewrite, den niemand reviewen kann

Pfad-Allowlist und Diff-Budget; die Aufgabe teilen statt sie zu erweitern

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](https://docs.github.com/en/copilot/concepts/agents/coding-agent/about-coding-agent)
2.  [GitHub Docs: Risks and mitigations for Copilot cloud agent](https://docs.github.com/en/copilot/concepts/agents/cloud-agent/risks-and-mitigations)
3.  [OpenAI Developers: Codex cloud environments](https://developers.openai.com/codex/cloud/environments)
4.  [Anthropic: Use Claude Code in the cloud](https://code.claude.com/docs/en/claude-code-on-the-web)
5.  [Google Jules: Limits and plans](https://jules.google/docs/usage-limits/)
6.  [Google Jules: Getting started](https://jules.google/docs/)
7.  [GitHub Docs: About protected branches](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches)
8.  [GitHub Docs: Models and pricing for GitHub Copilot](https://docs.github.com/en/copilot/reference/copilot-billing/models-and-pricing)
9.  [OpenAI Developers: Codex pricing](https://developers.openai.com/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)](https://arxiv.org/abs/2601.15195)
11.  [Peralta et al.: Why Are Agentic Pull Requests Merged or Rejected? An Empirical Study (MSR 2026, arXiv 2605.22534)](https://arxiv.org/abs/2605.22534)
12.  [DORA: State of AI-assisted Software Development 2025](https://dora.dev/dora-report-2025)

## Häufige Fragen

Was ist ein Background-Coding-Agent?

Ein Coding-Agent, der asynchron auf entfernter Infrastruktur statt im Editor läuft. Man übergibt eine Aufgabe, er arbeitet in einer eigenen Sandbox, pusht einen Branch und öffnet meist einen Pull Request. Codex Cloud, Copilot Cloud Agent, Claude Code Cloud-Sessions und Jules funktionieren so.

Kann ein Agent seinen eigenen Pull Request mergen?

Bei den hier beschriebenen gehosteten Produkten nicht. Der Copilot Cloud Agent kann einen Pull Request weder als bereit für Review markieren noch approven oder mergen, und die Person, die die Änderung angefordert hat, kann sie ebenfalls nicht approven. Branch Protection sollte dieselbe Regel für jeden anderen Agenten erzwingen.

Wie lange soll ein Hintergrund-Task laufen?

Kurz genug, dass ein Fehlschlag billig ist. Copilot erzwingt ein hartes Limit von 59 Minuten pro Session. Claude Code holt idle Cloud-Sessions zurück und cached ein Setup-Skript nur, wenn es in etwa fünf Minuten fertig wird. Braucht eine Aufgabe länger als eine Stunde, teile sie in Etappen mit einem Commit oder einer Plandatei dazwischen.

Wie verhindere ich doppelte Agent-Pull-Requests?

Vor dem Einreihen deduplizieren. Einen Schlüssel aus Repository, Issue und Basis-Commit bilden, offene und kürzlich geschlossene Pull Requests nach derselben Änderung durchsuchen und der Aufgabe ein Claim-Label geben. In einer Stichprobe abgelehnter Agent-PRs waren 23% Duplikate bereits vorhandener Arbeit.

Brauche ich Self-hosted Runner für Hintergrund-Agenten?

Nicht zwingend. Die gehosteten Produkte liefern verwaltete VMs oder GitHub-Actions-Umgebungen. Self-hosted Runner und eigene Umgebungen zählen, wenn der Agent privaten Netzzugang, eine bestimmte Hardware oder eine Datengrenze braucht, die das Compliance-Team verlangt.

Warum werden so viele Agent-PRs ohne Review geschlossen?

Weil Review-Kapazität und nicht Agent-Kapazität der Engpass ist. In einer Studie mit 600 abgelehnten Agent-PRs wurden 38% ohne nennenswerte menschliche Beteiligung aufgegeben. Ein Reviewer beim Öffnen zuzuweisen und die parallele Arbeit zu begrenzen, bringt mehr als der nächste Prompt-Feinschliff.

Geschrieben von Balázs Csorba

Senior Fullstack & AI Engineer in der Steiermark – über 10 Jahre Vue, Nuxt, Node.js und PHP, heute baue ich Werkzeuge für KI-Agenten.

[KI-Entwicklung & MCP-Server →](https://balazscsorba.com/de/expertise/ai-engineer)[Über mich →](https://balazscsorba.com/de/about)

## Weitere Artikel

-   [Tools für KI-Agenten gestalten: Namen, Beschreibungen, Schemas und Fehlermeldungen](https://balazscsorba.com/de/blog/agent-tool-design-descriptions-errors)
-   [Legacy-Codebase mit Coding-Agenten migrieren: ein Strangler-Fig-Playbook](https://balazscsorba.com/de/blog/coding-agents-legacy-codebase-migration)
-   [Context Rot bei langlaufenden Agenten: Leeren, Compaction, Memory und Sub-Agenten](https://balazscsorba.com/de/blog/context-rot-compaction-long-running-agents)
-   [Browser-Agenten für E2E-Tests: Agenten Playwright-Tests schreiben lassen, nicht ausführen](https://balazscsorba.com/de/blog/browser-agents-e2e-testing-playwright)

## Klingt nach dem, was du suchst?

Erzähl mir von deinem Projekt oder deiner Stelle – ich freue mich, von dir zu hören.

[Kontakt aufnehmen](mailto:contact@balazscsorba.com) [Auf LinkedIn vernetzen](https://www.linkedin.com/in/balazs-csorba)