Plan around how much you can review

I'd treat review as a stage with fixed capacity, and count work as ready when a reviewer can pick it up, which isn't always when the agent says it's done. A pull request that's missing context, failing checks or carrying generated files nobody has explained is unfinished work that's been dropped into someone else's queue.

Put a visible limit on how many changes can be waiting for human review. The number depends on the team and the risk, but the rule should be obvious: when the queue hits the limit, start fewer implementation jobs. Spare agent capacity can go into diagnosis, reproducing failures as tests, documentation or getting the next bounded task ready. Another overlapping patch will usually make the jam worse.

Review time depends a lot on the kind of change. A small copy fix and an authorisation change shouldn't sit in the same lane. I'd sort work by what affects how hard it is to inspect:

• What happens if the behaviour is wrong.
• How much code changed, and how concentrated it is.
• Whether data, permissions or external actions are involved.
• How well the reviewer knows that part of the code.
• How good the existing automated checks are.
• Whether the change can be cleanly reversed.
• How much of it is generated or mechanical output.

Use that to pick reviewers and order the queue, without letting it become a score that pretends you no longer need judgement. A short change to an access check can deserve far more attention than a big mechanical rename.

Watch age as well as count. An agent branch gets harder to review the longer it sits, because the base keeps moving and people forget what the task was about. Decide when stale work gets refreshed, re-scoped or closed. If the task and the reproduction evidence are still intact, regenerating a small change can be cheaper than rescuing every half-finished branch.