AI writes the code. Why is the pull request still waiting?
Your agents produce changes all morning. Your senior engineer reviews them all afternoon. Find the queue before buying another coding tool.
On this page
The short version
- Measure waiting, reviewer effort and rework alongside implementation time.
- Limit incoming review work to the capacity your team actually has.
- Send one reviewable behavior change with evidence and a named owner.
- Bound automated review by explicit rules and observed outcomes, not model confidence.
The code is ready. The reviewer is not.
The pull request is open. CI is green. Your only available reviewer is already reading another change. Asking an agent to start the next feature adds another item to that queue.
Samuel Corso describes review becoming a bottleneck after code output increased. Bryan Woods describes a small team separating routine changes from work requiring human review. These are practitioner reports, not independent evidence that any particular routing policy improves delivery.
For the next release, track ready-for-review time, first substantive response, active review effort, author rework and merge time. Keep drafts separate. A quick acknowledgment is not substantive review; a requested correction is not queue waiting.
- Ready
Scope and evidence are complete.
- Waiting
No reviewer has started.
- Reviewing
A reviewer checks behavior and impact.
- Reworking
The author resolves concrete objections.
- Merging
Current revision meets acceptance criteria.
Give the queue an owner and a limit
Use the pull-request list and review-request features you already have. Assign a primary reviewer and backup before adding more ready work. Reserve review time explicitly; otherwise the same engineer is scheduled to implement and review simultaneously.
Agree a work-in-progress limit from available reviewer time. When the queue reaches it, authors resolve review feedback, reproduce reported issues or help prepare existing changes. Keep urgent fixes visible in a separate priority lane with an owner.
Inspect the oldest waiting item daily. Record whether it lacks capacity, a decision, evidence or a suitable reviewer. Each reason needs a different response. Publishing more pull requests does not resolve any of them.
Shrink the decision the reviewer must make
Google’s review guidance recommends self-contained changes with related tests and enough context to understand them. Use that boundary rather than a universal line-count target. Separate unrelated cleanup; include callers needed to understand a new interface.
Illustrative scope: “Preserve the selected invoice filter after reload.” Keep billing calculations and table restyling outside that request. State the starting state, expected behavior, persistence boundary and what should happen when the saved filter is invalid.
Attach the author’s reasoning, the affected paths and check results for the current commit. Ask a reviewer to reproduce the acceptance behavior independently. Tests generated alongside the implementation are useful inputs; examine whether their assertions would catch the original failure.
Automate a defined slice of review
Start with existing formatters, static analysis and required CI checks. If adding AI review, ask it to investigate specific failure paths. Deduplicate findings and require a location, consequence and supporting evidence before sending them to the author.
- Classify
Apply an explicit scope and risk rule.
- Inspect
Run a bounded pass against this commit.
- Resolve
Fix or explain each supported finding.
- Escalate
An owner decides unresolved objections.
As a starting policy, permit one automated pass and one focused recheck after corrections. Escalate continuing disagreement to the owner. Record accepted defects, false alarms and reviewer time saved or added. More rounds need a reason beyond the model asking for another round.
Keep payment, authorization, data migrations and uncertain classifications with a qualified human reviewer. Trial routine routing under human audit before expanding automation. A confidence score alone cannot demonstrate correct classification. Agent execution controls belong in the separate coding-agent guardrails guide.
Judge the release, not the PR count
- Every ready request has one behavior goal, evidence and a reviewer.
- Queue age, active effort and rework are recorded separately.
- Review objections have reproductions or explicit reasoning and named resolution owners.
- Changed commits receive the affected checks and review again.
- Compare comparable changes for delivery time, review effort, reverts and escaped defects before expanding automation.
Questions we hear
Should every AI-written change get extra reviewers?
Assign expertise by the behavior and risk involved. Add a reviewer when an unresolved decision needs another specialty.
Can a small change skip review?
Size alone is insufficient. Define eligible scope and exclusions, require current evidence, and audit outcomes before allowing automatic approval.
What shows that the queue improved?
Shorter waits with acceptable reviewer effort, rework and post-release outcomes for comparable changes. Higher PR volume alone cannot establish improvement.
Sources
- Code output increased; review became the bottleneckSamuel Corso on LinkedIn
- When agents write code, review becomes the bottleneckBryan Woods on LinkedIn
- Small CLsGoogle Engineering Practices