Check how the review process itself is going

Every so often I'd look at the workflow through its own records. Where do changes wait? Why do they get sent back? Which checks fail late, and which areas keep needing a specialist to step in? Use the actual tasks and pull requests for this, not a general sense that review feels slow.

The questions I'd go through:

• Is unfinished work getting into the human queue?
• Are tasks being split at boundaries a reviewer can follow?
• Do high-risk changes get to the right owner early?
• Are agents working at the same time on the same contracts?
• Do the tests describe behaviour, or do they just mirror the implementation?
• Are review rounds settling decisions, or just piling up patches?
• Does the merge process test the combined state of the target branch?
• Can someone maintaining this later find the requirement and the acceptance evidence?
• Are stale branches being closed before their context fades even further?

When the queue grows, I'd cut intake before trying to review faster. Then I'd take the oldest high-risk item, decide whether it's still worth finishing, and either give it a reviewer or close it. A smaller queue means reviewers can keep enough context in their heads to make a proper call.

Before anything merges, ask the approver to write down what behaviour changed, what evidence they checked and how you'd recover if the decision turns out to be wrong. If they can't back those answers up without leaning on the agent's summary, the change stays out of the target branch for now.

That queue full of pull requests that all look reasonable is where the trouble starts. Agents can turn out changes faster than people can properly check them, so the number of changes the team can actually verify has to set the pace for everything before review. That's why I'd put the limit on the queue, write tasks a reviewer can follow without the chat session and keep merge authority apart from the agent. The first thing I'd check is how many changes are waiting for human review right now, and if that's over the limit, I'd stop starting new implementation jobs until reviewers have caught up.