Before Hiring More Reviewers, Count the Changes Waiting for Production

Before Hiring More Reviewers, Count the Changes Waiting for Production

When AI pushes pull-request volume up, adding reviewers looks like the responsible move. I would not sign off on that headcount until I knew where approved changes were piling up. A faster review stage buys you little if deployment stays constrained, and it can quietly make releases larger, diagnosis harder, and delivery less predictable.

Pull-request throughput is not delivery capacity. Before I touched engineering staffing, I would want four facts: how many approved changes are waiting for deployment, how large production batches have become, where approval time actually goes, and whether a single change can be released or reversed without dragging unrelated work along with it. If the persistent queue starts after merge, the first dollar belongs to release automation and progressive delivery, not to another reviewer.

AI moved work into queues rather than out of the system

GitLab’s AI Accountability Report, published on June 23, 2026, is a useful warning. It draws on a Harris Poll survey of 1,528 developers and technology buyers across six countries. Although 78% reported faster code output, 79% said end-to-end software delivery had not accelerated at the same pace, and 85% believed the bottleneck had shifted to review and validation.

Those numbers describe a widening gap between code generation and production delivery. What they do not do, on their own, is tell you where the constraint sits.

A pull request passes through a series of queues before it reaches a user: human review, automated testing, security checks, required approvals, artifact creation, deployment, rollout, and sometimes a separate release decision on top of all that. Raising the arrival rate at the first queue does nothing for the exit rate of the whole system. If downstream capacity stays fixed, work in progress and lead time climb. That is ordinary queue behavior, and AI coding tools make it easy to overlook because their output is immediate and legible. Generated code shows up as commits and pull requests. Deployment constraints surface later, as release calendars, change freezes, shared environments, manual runbooks, migration risk, and teams waiting on someone with production access.

So “AI code review bottleneck” is too narrow a phrase. Review may genuinely be constrained, but it may also just be the first visible place where excess inventory collects. Speed it up and you push the same inventory into a queue that is less observable and more dangerous.

GitLab’s incident finding makes that risk concrete. Of the organizations that had experienced an incident, 34% could not determine whether AI-generated code contributed to it. Attribution gets harder as releases carry more interacting changes. When twenty approved changes go to production together, the useful question stops being whether each pull request passed review. Operators have to work out which change altered runtime behavior, whether two of them interacted, and which one they can pull out without breaking the rest. Faster generation without tighter release control just enlarges that search space.

The post-merge queue hides behind healthy pull-request metrics

Most engineering dashboards stop at merge. They report pull requests opened, review turnaround, merge rate, maybe test duration. A team can look excellent on every one of those measures while production delivery gets steadily worse.

Picture a team that merges throughout the week and deploys on Thursday afternoon. Each production release carries a dozen pull requests, a handful of configuration changes, and a database migration. Review time might be under an hour. The oldest approved change might still sit for six days before it reaches production, and every change in that release shares one risk profile.

On July 21, Octopus Deploy’s Steve Fenton reported that 92% of teams in its data deploy multiple changes as a batch. That figure does not prove deployment is the constraint for every team. Some batching is deliberate, and a batch of two low-risk changes is nothing like a monthly release holding several weeks of work. What it does rule out is the comfortable assumption that more review throughput will convert into more production throughput.

Batching creates coupling even between changes that were developed in isolation. A failed rollout may force you to revert the entire release. A schema migration may block rollback altogether. A security approval may apply to the combined package rather than any single change. When production validation fails, everything in that release waits while the team investigates.

This is the exact path by which a review optimization degrades delivery reliability. More reviewed changes arrive at the constrained deployment stage, batch size grows, and each release becomes harder to validate or reverse. The review dashboard improves while change lead time and operational risk get worse.

For capacity planning, I treat the production boundary as the line that counts. A merged change is inventory. It has consumed engineering effort and carries integration risk, but it has produced no feedback from real traffic yet.

Four measurements locate the actual constraint

Before I discussed headcount, I would instrument the path from “ready for review” to production. The timestamps almost always exist already, scattered across Git hosting, CI, deployment tooling, change-management systems, and feature-flag platforms. The work is correlating them around the same change or artifact.

Four measurements do most of the work.

The first is approved-but-unreleased inventory. Count the changes that have cleared required review but are not yet running in production, and track the age distribution rather than just the count. An average will happily hide one release-blocking change that has been waiting far longer than everything else. The unit has to represent an independently meaningful change; raw commit counts are noisy because teams squash, rebase, and generate commits differently. Pull requests, tracked work items, or deployable artifact versions tend to be cleaner. Where feature flags are in play, keep deployment and exposure separate. A change that is deployed but permanently disabled has left the deployment queue, yet it may still be unreleased product inventory. Both states matter, and they are different queues.

The second is deployment batch size. Measure how many independently reviewed changes enter production in a single deployment, and note whether the batch crosses service, configuration, or database boundaries. Ten changes inside one stateless service present a very different failure surface from ten changes spanning a shared schema and several consumers. Take this from the production artifact or release manifest, not from a release note stitched together afterward. The concern is what has to move, validate, and potentially roll back together.

The third is approval delay. Separate time waiting for a reviewer from active review time, and separate both from later security, compliance, or change approvals. Lumping all of it under “review time” leads to the wrong fix. If a pull request waits two days for domain review, reviewer capacity may well be the issue. If it clears review in an hour and then waits three days for a production change window, no number of reviewers will move lead time. If automated checks eat most of the elapsed time, compute capacity, test selection, or test architecture deserves attention before staffing does.

The fourth is independent rollback capability. Record whether a single change can be stopped or reversed without withdrawing unrelated changes, because that is far more useful than a generic claim that the platform “supports rollback.” A previous container image may redeploy in seconds and rollback can still fail, because a migration was destructive, a message schema changed incompatibly, or an external side effect cannot be undone. Feature flags disable a code path; they do not reverse data corruption. Independent reversibility is an architectural property, not a button in the deployment UI.

Trend these together. Approved inventory without age can make a high-throughput team look worse than it is. Batch size without rollback data says almost nothing about recovery. Approval delay without the post-approval wait rewards local optimization. What you are hunting for is inventory that is both old and durable. A queue that appears during a release and drains is normal; one that survives multiple release cycles points at a capacity or coupling problem.

Review is the bottleneck only when its queue dominates

The strongest objection is simple. AI-generated code can raise review load while lowering reviewer confidence. A change can be syntactically plausible and still violate a domain invariant, misuse an internal API, weaken authorization, or ship tests that only restate the implementation. In that world, review and validation can genuinely be the limiting stage.

But I would want to see the evidence for it. The age of changes waiting for review would be climbing. Required reviewers would have persistent queues. Approved changes would reach production quickly once merged, which tells you the downstream path still has slack. Deployment batches would stay small, and release automation would sit idle a fair amount of the time, waiting on validated inputs.

Under those conditions, more review capacity may be the right call. Often the capacity you need is domain expertise, not generic pull-request throughput. A security-sensitive service needs reviewers who understand its trust boundaries. A payment workflow needs people who can reason about idempotency and reconciliation. Adding another review agent does not supply independent judgment when the agent carries the same blind spots as the generator.

Validation capacity may also call for deterministic tooling rather than headcount. Contract tests, static analysis, reproducible integration environments, dependency policies, and property-based tests reject whole classes of bad change without spending scarce reviewer attention. Human review should concentrate on the behavior and risk that automation cannot establish reliably.

The mistake is not hiring reviewers. It is concluding that review is the constraint simply because pull-request volume went up. Survey respondents can accurately say review feels slower while the organization still has a larger deployment problem downstream. Perceived pressure and system throughput are related, but you cannot swap one for the other.

A post-merge constraint needs release engineering

When approved changes are backing up before deployment, feeding that queue faster is actively counterproductive. I would spend the next increment on reducing release coupling and making production changes cheaper to reverse.

The foundation is an automated pipeline that promotes one immutable artifact through environments. Rebuilding for production weakens provenance and introduces a fresh variable at the most sensitive point in the process. Deployment records should connect the source change, artifact version, configuration, migration, and rollout state, so an incident responder can name exactly what moved.

Progressive delivery then limits exposure without giving up deployment frequency. A canary release sends a small slice of traffic to a new version and widens only while health checks stay in bounds. Blue-green deployment keeps a known environment available for a fast traffic switch. Feature flags separate code deployment from user exposure where the application design allows it. None of these patterns is free. Canary analysis depends on trustworthy service-level indicators. Blue-green raises infrastructure demand and does nothing for incompatible data changes. Feature flags accumulate operational debt unless someone owns their removal. Automate an unreliable manual process and you mostly get bad releases faster.

Database evolution usually decides whether independent rollback is real at all. Expand-and-contract migrations, backward-compatible message schemas, and staged backfills let old and new application versions coexist. A destructive migration bundled with application code defeats progressive delivery, because the previous version may no longer run once the schema has moved.

Release observability matters as much as deployment execution. Production telemetry should carry deployment markers and artifact identities, and logs, traces, and metrics need enough version context to compare the canary against the stable population. Without that correlation, a gradual rollout only shrinks the blast radius; it does not make diagnosis meaningfully easier.

The goal is smaller reversible releases, not maximal deployment activity. A pipeline that deploys often but bundles many unrelated changes still leaves you a wide diagnostic surface. A platform that deploys one service independently but needs a coordinated rollback across six services has relocated the coupling, not removed it.

Staffing should follow the oldest durable queue

Staffing decisions belong at the constrained stage of delivery, not the stage generating the most visible activity. AI sharpens that distinction, because code output can rise without any matching rise in deployable, operable change.

If review-ready inventory is old while approved inventory stays near zero, fund review and validation. If changes clear review and then wait for a shared test environment, the environment and test architecture deserve the budget. If approved changes pile up behind release windows or manual deployment steps, release engineering is the constraint. If deployments are frequent but still full of inseparable changes, architecture and reversibility need the work.

I would also resist treating AI output gains as a reason to cut engineering capacity early. GitLab’s findings point to faster code production sitting next to slower end-to-end delivery and weak incident attribution. That combination raises the need for validation, release control, and operational ownership, even when fewer hours go into drafting any single change.

Pull-request throughput is a local measure. Production throughput, change lead time, and recovery behavior describe the delivery system. When the queue lives after merge, progressive delivery and independent releases add real capacity, and another reviewer only helps the organization manufacture approved inventory faster.

References

• GitLab, “GitLab research reveals organizations are generating AI code faster than they can control it,” June 23, 2026: https://about.gitlab.com/press/releases/2026-06-23-gitlab-research-reveals-organizations-are-generating-ai-code-faster-than-they-can-control-it/
• Steve Fenton, Octopus Deploy, “Code review is not the bottleneck, even with AI,” July 21: https://octopus.com/blog/code-review-not-bottleneck-even-with-ai
• Nicole Forsgren, Jez Humble, and Gene Kim, Accelerate, 2018.
• Jez Humble and David Farley, Continuous Delivery, 2010.