Review the review system

The workflow needs periodic inspection using its own records. Look at where changes wait, why they are returned, which checks fail late, and which areas repeatedly need specialist intervention. Use actual tasks and pull requests rather than a general impression that review feels slow.

A practical review-system check asks:

• Is unfinished work entering the human queue?
• Are tasks being split at boundaries a reviewer can understand?
• Do high-risk changes reach the right owner early?
• Are agents working concurrently on the same contracts?
• Do tests express behaviour or merely mirror implementations?
• Are review rounds resolving decisions or accumulating patches?
• Does the merge process test the combined target state?
• Can a later maintainer find the requirement and acceptance evidence?
• Are stale branches closed before their context decays further?

When the queue grows, reduce intake before trying to review faster. Then inspect the oldest high-risk item, decide whether it remains worth completing, and either give it a reviewer or close it. A smaller queue lets reviewers hold enough context to make an actual judgement.

Before merge, ask the approver to record the changed behaviour, the evidence checked and the recovery path if the decision is wrong. Keep the change out of the target branch until those answers can be supported without relying on the agent's summary alone.