Put review capacity into planning

Treat review as a finite stage in the delivery system. Count work when a reviewer can begin it, not when an agent says it has finished. A pull request missing context, failing checks or carrying unexplained generated files is unfinished work that has been moved into someone else's queue.

Set a visible limit on changes awaiting human review. The number depends on the team and risk, but the rule should be clear: when the queue reaches its limit, start fewer implementation jobs. Use available agent capacity for diagnosis, test reproduction, documentation or preparation of the next bounded task. Producing another overlapping patch usually makes the blockage worse.

Review time varies with the kind of change. A small copy correction and an authorisation change should not occupy the same lane. Classify work by factors that affect inspection:

• the consequence of incorrect behaviour;
• the amount and concentration of changed code;
• whether data, permissions or external actions are involved;
• the reviewer's familiarity with the area;
• the strength of existing automated checks;
• whether the change can be reversed cleanly;
• the amount of generated or mechanical output.

Use the classification to assign reviewers and order the queue. It should not become a score that pretends to remove judgement. A short change to an access check may deserve more attention than a large mechanical rename.

Track ageing as well as quantity. An old agent branch becomes harder to review as its base moves and the task fades from memory. Decide when stale work must be refreshed, re-scoped or closed. When the task and reproduction evidence are intact, regenerating a small change may cost less than recovering every half-finished branch.