Too many AI pull requests to review? Limit the queue

The problem

A pull request (PR) is a proposed change to your code that waits for someone to review it and merge it in. A draft pull request is one that is marked as not ready to merge yet. An unattended AI agent works through your tickets and leaves a draft PR for each one, so a person can check the work before anything reaches your product.

The agent can start a new ticket every half hour, day and night. Your reviewers can't keep up with that. They have their own work, meetings and time off. Reading a change carefully, running it and deciding whether it's right takes real time, whoever wrote it.

So the bottleneck moves. It used to be writing the code. Now it's reviewing it. If nothing links the two speeds, the review queue grows every day, and the agent keeps adding to a pile nobody can get through.

Why a pile of drafts goes bad

A big review queue isn't just slow. The drafts in it get worse while they wait.

Each draft starts from a copy of your main code as it was when the agent picked the ticket. Programmers call that copy a branch, and the main code the base branch. While the draft waits, the rest of your team keeps changing the base branch. The draft doesn't change with it, so it falls further behind. That's what stale means here.

Stale drafts cause two kinds of trouble:

• Conflicts. If two drafts change the same part of the same file, the first one to be merged makes the second one clash. Git calls this a merge conflict. Someone has to untangle it by hand before the second draft can go in.
• Wrong assumptions. A draft written against last week's code may rely on something that has since changed. Even without a conflict, it can be quietly wrong, and the reviewer now has to check it against today's code, not the code it was written for.

The more drafts wait, and the longer they wait, the more of this cleanup there is. An agent that opens twenty drafts in a week can leave your team with more work than it saved.

The fix: a limit on open drafts

The answer is backpressure. The term comes from plumbing: when a pipe downstream is full, pressure pushes back and slows what's coming in. For an AI agent, it means the agent only starts new work when your team has room to review it.

In practice, it's one number: the most drafts from the agent that can be open at the same time. Before each run, the agent counts its open drafts.

• If the count is below the limit, it can pick a ticket and work on it.
• If the count has reached the limit, it doesn't start anything. It's paused.
• When a person merges or closes one of the drafts, the count drops, and the next check can start a run again.

Nobody has to switch the agent off or on. The pause and the resume both follow from your team's own pace. If your reviewers land three drafts a day, the agent does about three tickets a day, however often it's scheduled to check.

A pause is cheap if the count happens early. The best place to check is before anything expensive starts: before a machine is switched on and before the AI model is called. Then a paused agent costs close to nothing, and the tickets it didn't start are still there for later.

Choosing the limit for your team

The right limit is roughly the number of drafts your team can properly review in a working day. Too high, and you're back to a growing pile. Too low, and the agent sits idle while reviewers are free.

These are starting points, not measured figures. Adjust them once you've seen how your team actually works:

Then watch two signs:

• Raise it if drafts are usually reviewed the same day and the queue is often empty.
• Lower it if drafts regularly wait more than a couple of days, or often need fixing because the base branch moved on.

Keep the limit lower if the agent's tickets touch the same parts of your code. Two drafts in the same file are the ones most likely to conflict.

The limit also works alongside your spending caps. A monthly budget stops runs when the money runs out. A draft limit stops them when your reviewers are full, which usually happens first. See what an AI coding agent costs per ticket for the money side.

Pick the newest tickets first

Once the agent is paced by your reviews, each run is worth more. So it matters which ticket it picks when it does run.

It's tempting to clear the backlog from the bottom, oldest first. For an agent, that's the wrong way round. An old ticket is the one most likely to be stale itself. It may describe code that has since been rewritten. It may already be fixed, with the ticket left open by mistake. The person who wrote it may have moved on, so nobody can confirm what it meant.

On one of our own repositories, 3 of 5 hand-picked "top tickets" were already in production. They looked important only because the tracker still said they were open. Picking by most recent update favours tickets someone still cares about, written against code that still looks like that.

Newest-first doesn't mean old tickets are ignored forever. Updating a ticket, for example by clarifying it or adding a comment, moves it back up. That's a useful habit anyway: a ticket worth doing is usually worth a quick check that it still makes sense. For what a ticket needs before an agent can work it, see is this ticket ready for an AI coding agent?

In practice with BacklogBeast

BacklogBeast is built around this limit. Here's how it works today:

• The default limit is two open drafts per repository. BacklogBeast counts its own open pull requests in each repository before it does anything else for that repository's tickets.
• The count comes before any spend. A repository at its limit is passed over before the readiness check, before a virtual machine starts and before the AI model is called. A paused repository costs nothing in model spend.
• It resumes on its own. BacklogBeast checks every half hour. When you merge or close one of its drafts, the next check can start a run. Merging on your own machine and pushing counts too.
• Newest first, never oldest first. It takes the most recently updated ready tickets, skips any that recent commits say are already done, and runs a readiness check on the rest.
• Drafts only, never merged. Every pull request is opened as a draft, which GitHub won't merge. A person always decides what lands. See letting an AI agent open pull requests safely.

In our own use, the draft limit usually stops runs before the monthly budget does. That's the point: the agent works at the speed your team can review, and the backlog waits safely until you're ready. If you'd like to try it on your own repositories, join the waitlist.