A coding agent can finish a task in minutes. Then its pull request waits for a human, and it waits longer than the PRs people write by hand.
LinearB's 2026 Software Engineering Benchmarks Report covers more than 8.1 million pull requests from over 4,800 organizations. It found that "AI PRs wait 4.6x longer before review" but "are reviewed 2x faster once picked up". So the slow part is getting someone to pick it up. For agents, the gap is wider: "Agentic AI PRs have a PR Pickup Time 5.3x longer than Unassisted ones".
The AI Productivity Paradox Report 2025 from Faros AI used telemetry from over 10,000 developers across 1,255 teams. Developers on teams with high AI adoption "complete 21% more tasks and merge 98% more pull requests, but PR review time increases 91%".
In October 2025, GitHub said: "Coding agent now contributes to roughly 1.2 million pull requests per month".
Our team at DX Heroes sees the same thing: agent PRs finish fast and then wait for review.
A better agent won't fix this. Every agent PR has to reach a person who knows it's theirs. Everything below works without extra tools. My own app gets one short section at the end.
Why agent PRs get lost: every agent files them differently
Whether a PR shows up in your queue depends on who GitHub or GitLab thinks opened it. Agents don't agree on that.
| Agent | Who opens the PR | Where it lands |
|---|---|---|
Claude Code CLI via gh pr create
|
You | author:@me |
| Claude Code on the web, routines | You | author:@me |
| OpenAI Codex cloud, "Create PR" | You (not in the docs, so check your first one) | author:@me |
| GitLab Duo Developer Flow | You | Your merge requests |
| GitHub Copilot cloud agent | Copilot, as a draft | Your review requests |
| Claude and Codex agents on GitHub | The agent, as a draft | Drafts for you to review |
| Claude in custom GitHub Actions (why) | A bot, such as claude[bot]
|
No personal view |
| Cursor cloud agents | The Cursor app, as a draft | No personal view |
| Devin | Devin, unless set to open as the linked user | No personal view |
That gives three buckets.
Opened under your account. author:@me finds these. With Claude Code routines, "commits and pull requests carry your GitHub user". The CLI marks the PR body "Generated with Claude Code" by default. GitLab Duo attributes the merge request "to the human user who triggered the flow instead of the service account", for compliance. The risk is forgetting a PR because you didn't write it.
Opened by a bot as a draft, with you as the reviewer. Copilot will "raise a pull request, then request a review from you when it's finished". It "cannot mark its pull requests as 'Ready for review'", so the PR stays a draft until a person marks it ready. GitHub also "prevents the user who asked Copilot cloud agent to create a pull request from approving it" (risks and mitigations). A second person has to review, and that person needs the PR in their queue too. If your review queue hides drafts, you won't see any of these.
Not tied to you at all. The default Claude Code GitHub Action doesn't open PRs itself. Claude pushes a branch, posts a link, and "the user must click the link and create the PR themselves". Custom workflows that open PRs with a bot token show up as claude[bot] or github-actions[bot]. Cursor cloud agents work "through the Cursor GitHub or GitLab App, not through any single person's credentials" and "open draft pull requests". Devin opens PRs as Devin unless an admin sets "Open PRs as" to the user and your GitHub account is linked. No personal filter catches these, so you need a label or a repo-wide view.
Four queues that cover all three buckets
No single filter catches all three buckets. Keep four views, each answering one question.
On GitHub, start with the new pull requests dashboard at github.com/pulls, generally available since July 9, 2026. Save each queue below as a view there. On GitLab, the merge request list with Reviewer, Author and Label filters does the same job.
1. Waiting for my review
is:pr is:open review-requested:@me
Leave out draft:false if you use cloud agents. They request your review while the PR is still a draft. review-requested:@me also matches requests to teams you're on, and user-review-requested:@me keeps only the direct ones (search docs).
2. Opened by me
is:pr is:open author:@me
This covers agents that open PRs under your account and, on github.com since June 18, 2026, pull requests Copilot opened at your direction. Treat those PRs as yours, because everyone else will, and watch their CI, merge conflicts and approvals. Nobody else will fix a red build on a PR with your name on it.
3. Agent PRs by label
Cloud agents push to branches with recognizable prefixes. By default you'll see copilot/, claude/, codex/, cursor/ and devin/. Claude Code routines, for example, push to "branches prefixed with claude/". Check yours, because some tools let you change the prefix.
Turn the prefix into an agent label. actions/labeler matches head branch names (since v5):
# .github/labeler.yml
agent:
- head-branch: ['^copilot/', '^claude/', '^codex/', '^cursor/', '^devin/']
# .github/workflows/labeler.yml
name: "Pull Request Labeler"
on:
- pull_request_target
jobs:
labeler:
permissions:
contents: read
pull-requests: write
runs-on: ubuntu-latest
steps:
- uses: actions/labeler@v6
That's the README example, unchanged. Create the agent label first, or add issues: write so the action can create it. The PR that adds the workflow won't get labeled, because pull_request_target runs from the base branch.
Local sessions, like Claude Code in your terminal, use whatever branch name the agent picks. Add one line to the agent's instructions file (CLAUDE.md, AGENTS.md) asking for branches named agent/..., and add '^agent/' to the list. The queue is then is:pr is:open label:agent.
4. The lead view
This is for a tech lead or a rotating reviewer. It shows everything that's stuck, no matter who opened it.
is:pr is:open org:your-org -label:dependencies status:failure
is:pr is:open org:your-org -label:dependencies review:changes_requested
is:pr is:open org:your-org -label:dependencies updated:<YYYY-MM-DD
That's failing CI, changes requested, and nothing updated for a few working days. -label:dependencies drops Dependabot's PRs, because by default "All pull requests have a dependencies label" (Dependabot options). GitHub search has no qualifier for merge conflicts, so you'll spot those on the PR page or in a tool that reads the mergeable state.
Five habits so the team isn't waiting on you
Queues show the work. These habits get it picked up.
- Review before you hand the agent its next task. Otherwise every new task adds one more PR to the pile, and the pile is yours.
- Two fixed review windows a day. For example, after standup and after lunch. Nothing waits more than half a day, and you don't switch context every twenty minutes.
- A team-agreed time to first response. Not time to merge, only the time until a person looks at it. Write it down, for example "first response within four working hours". It's the same pickup time that LinearB measured as 5.3x longer for agentic PRs.
- Notify only on review requested, changes requested and CI failed. If every comment pings you, you'll mute everything, including the pings that matter.
- Give agents small tasks. Faros tied AI adoption to "a 154% increase in average PR size". A small PR fits into a review window. A large one waits for "later".
What I built for this: Gitwall
This problem is why I built Gitwall, a free, open-source (MIT) macOS app. It puts these queues in the menu bar and in desktop widgets in four sizes (Counter, List, Board, Wide Board), each showing one preset. It supports GitHub.com, GitHub Enterprise Server, GitLab.com and self-managed GitLab 16+, several accounts at once.
Each queue above is a preset. Every account gets "Waiting for my review", and since 0.4.0 a draft that names you as a reviewer stays in it, which is exactly how cloud agents file their pull requests. "Opened by me" is "Authored by me", and the agent queue is either "Any of these labels" set to agent or "Any of these authors" set to the bot logins. For the lead view, put dependencies into "None of these labels" and make one preset per condition (Checks "Failed", Review "Changes requested", Merge "Conflict"), because filter groups combine with AND. There's no stale filter yet.
Copilot's own PRs don't match "Authored by me". They arrive through "Review requested from me" and "Assigned to me", or through an author filter on copilot-swe-agent. A review GitHub asks of a team you belong to counts too, as long as your token may read your team memberships (a classic token needs read:org).
Limits: macOS only, no Bitbucket, and notifications only arrive while the app runs. No server, no analytics, and your OAuth or read-only token stays in the macOS Keychain.
Try it and tell me what's missing
- Download: latest release, signed and notarized. The Mac App Store version is in review.
- Source: github.com/prokopsimek/gitwall
- It launches on Product Hunt on Saturday, September 12: Gitwall for Mac
I care more about feedback than upvotes. Which queue or filter is missing for your setup?
How does your team keep agent PRs from waiting? Do you have a review SLA?
An AI assistant researched and wrote this post from my brief. Every claim links to its source.
Top comments (1)
Useful framing: separating review-requested, author:@me, and agent-label queues prevents the classic blind spot. I’d add one lightweight invariant: have CI post a structured agent summary with intent, files touched, tests run, and known uncertainty, and keep each PR under a review budget. That makes two daily review windows sustainable and gives the reviewer a fast risk scan without trusting the agent blindly. The first-response SLA is especially useful because it measures pickup time, not merge time.