The State of Code Review Automation 2026

The pull-request gate has become a programmable mix of humans and CI, and in 2026 the pipeline, not the reviewer, is most often the thing a merge is waiting on.

Executive summary

The pull-request gate is where code review automation lives, and in 2026 it has matured from optional convention into enforced policy across the majority of active repositories. Required status checks, branch protection, and auto-merge have turned the merge button into a programmable gate that humans and CI now share. What used to be a social agreement, please get a review before you merge, is now a machine-enforced contract that a change cannot reach the default branch until a defined set of conditions, human and automated, are all satisfied.

That shift is healthy. Enforced gating raised the floor on code quality, made review a consistent step rather than an optional one, and gave teams a single, auditable place to express what 'ready to merge' means. But automation moved the bottleneck rather than removing it. As required checks became standard, a growing share of pull requests that sit waiting are not waiting on a reviewer at all. They are waiting on CI to go green. The constraint migrated from the human in the loop to the pipeline behind the gate, and many teams have not updated their mental model to match.

Auto-merge raises the stakes further. Once a human approves, the only thing standing between an approved change and production is a pipeline that must pass reliably and quickly. A slow gate adds latency to every merge. A flaky gate is worse: it re-opens a gate the team thought was closed, silently holding a green-lit change because of a transient failure that had nothing to do with the code. Under auto-merge, pipeline reliability stops being a CI-team concern and becomes a delivery-flow concern that touches every engineer who opens a pull request.

This report quantifies that migration. We look at how widely the gating mechanisms are adopted, what a blocked pull request is actually waiting on, how long it waits by blocker type, and what happens when a required check fails on a transient error rather than a real defect. The throughline is that automated gating only pays off when the gate itself is fast and trustworthy, and that the failure mode of a slow or flaky gate is invisible: it shows up as review latency and stalled delivery rather than as an obvious CI problem.

The teams shipping fastest treat the CI gate as the critical path it has become. They keep required checks fast, they kill the flaky failures that re-open a closed gate, and they lean on auto-merge precisely because their pipeline is reliable enough to trust unattended. The good news, mirrored across every Latchkey report, is that the levers here are mechanical and well understood. A fast, self-healing required check is pipeline hygiene, not a research project, and it is what turns automated gating from a quiet tax into a genuine accelerator.

Required checks are now the default, not the exception

Two-thirds of active repositories enforce at least one required status check, and branch protection plus reviewer approval cluster close behind. The merge button has become a programmable gate. That is a quiet but profound change in how software ships: the conditions for reaching the default branch are now declared in configuration, enforced by the forge, and auditable after the fact, rather than living in a team's collective memory and good intentions.

The upside is real. Enforced gating removes the worst failure mode of voluntary review, the rushed merge under deadline pressure that skips the check entirely, and it makes the quality bar consistent across every contributor regardless of seniority or familiarity with the codebase. A required check that runs the test suite is a far more reliable guarantee than a convention that everyone is supposed to follow.

The cost is that the gate's speed and reliability now directly govern how fast a team can ship. When 'ready to merge' is a machine condition, the machine becomes part of the delivery path in a way it was not when review was advisory. A required check that takes twenty minutes adds twenty minutes to every merge, and a required check that fails intermittently adds an unpredictable tax on top. The chart of gating adoption below shows how broadly these mechanisms have spread, and the breadth is exactly why their performance matters so much.

CI, not humans, is the most common thing a PR waits on

Once required checks are standard, the largest share of blocked pull requests are waiting on a pipeline rather than a reviewer. This inverts the mental model most teams still carry. For years the story of code review was about human latency: the reviewer who is in a different timezone, the senior engineer who is the bottleneck for a whole team, the change that sits for a day waiting for someone to look at it.

That problem has not vanished, but it is no longer the dominant one. In 2026, more often than not, the change has been approved and the only thing standing between it and the default branch is CI going green. The reviewer did their job in the morning; the pull request is still open in the afternoon because the pipeline is slow, queued, or recovering from a transient failure. The latency is real, but it is mechanical, and it is invisible to the standard 'time to first review' metrics that teams instrument.

This matters because teams optimize what they measure. A team that tracks review latency and not gate latency will keep pushing reviewers to respond faster while the actual bottleneck, the pipeline, goes unaddressed. The split of what a blocked pull request is waiting on, shown below, is the single most useful diagnostic in this report: if CI is the majority blocker, the highest-return investment is a faster, more reliable gate, not a faster reviewer.

• When CI is the majority blocker, faster reviewers do not move the delivery needle; a faster gate does.
• Gate latency is invisible to standard time-to-first-review metrics, so it goes unmeasured and unfixed.
• The change is usually already approved: the pipeline is the last thing between approval and the default branch.

Auto-merge raises the cost of a slow or flaky pipeline

Auto-merge is enabled in roughly a third of repositories, and where it is on, the pipeline is the last thing standing between an approved pull request and production. Auto-merge is a delegation of trust: the team is telling the forge, once a human approves and the checks pass, ship it without waiting for anyone to press the button. That delegation is only safe if the checks are both fast and reliable.

A slow pipeline under auto-merge is merely annoying: the change ships, just later than it should. A flaky pipeline under auto-merge is genuinely dangerous to delivery flow, because a transient failure silently holds a green-lit change instead of shipping it. The approving engineer has moved on, confident the change is on its way. Nobody is watching the pull request. It sits, blocked on a failure that a single retry would clear, until someone happens to notice that a change everyone thought had shipped is still open.

This is why auto-merge adoption and pipeline reliability have to advance together. A team that turns on auto-merge without first making its required checks reliable has not removed human attention from the merge, it has removed human attention from a process that still needs it whenever the gate misbehaves. The teams that get the full benefit of auto-merge are the ones whose gate fails only on real defects, so that 'no human is watching' is a safe state rather than a hidden risk.

A flaky required check re-opens a gate the team thought was closed

When a required check fails on a transient error, the most common outcome is a manual re-run that then passes. That is pure wasted latency: the change was always correct, the pipeline hiccuped, and a human had to notice the red check, understand it was spurious, and click re-run before the gate would close again. None of that work improved the code or caught a defect.

A meaningful share of these failures do worse than waste a few minutes: the pull request simply stalls until a human notices it is stuck. This is review latency created entirely by an unreliable gate rather than by any real defect or any slow reviewer. The change is done, approved, and correct, and it is sitting blocked because a network blip during dependency install turned a green check red and nobody has looked at the pull request since.

The breakdown of what happens when a required check fails on a transient error, shown below, makes the waste concrete. The large majority of these failures end in 'passes on retry', whether that retry is manual or automatic, which means the failure carried no signal at all. Only a small slice surfaces a real problem. A gate that cries wolf this often trains engineers to reflexively re-run red checks without reading them, which is exactly the habit that lets a genuine failure slip through.

• The most common outcome of a transient required-check failure is a manual re-run that then passes: latency with no signal.
• A non-trivial share of transiently-failed PRs stall until a human notices, turning an infrastructure blip into review latency.
• Frequent false reds train engineers to re-run without reading, which is how a real failure eventually slips past.

The merge queue is the next gate to get slow

Merge queues are the newest mechanism in the gating stack, adopted by a smaller but growing share of repositories, and they exist to solve a real problem: on a busy default branch, a change that passed CI against an older base can still break the branch once it merges, because it was never tested against the changes that landed ahead of it. The merge queue serializes merges and re-runs the required checks against the actual target state, which closes that gap.

The catch is that a merge queue multiplies the importance of gate speed and reliability. Every change in the queue runs the required checks again, in order, and a slow check now gates not just one pull request but the entire queue behind it. A flaky check in the queue is worse still: a transient failure can eject a change from the queue and force it to re-enter at the back, paying the full wait again for a failure that was never about the code.

Teams that adopt a merge queue without first making their required checks fast and reliable often find that the queue, intended to protect the branch, becomes the new bottleneck. The mechanism that serializes merges is only as good as the checks it serializes, which is why merge-queue adoption and pipeline hygiene are tightly coupled. A fast, self-healing gate is a prerequisite for a merge queue that accelerates rather than throttles.

Gate latency hides from the metrics teams actually track

The latency a pull request accumulates while blocked on CI is structurally harder to see than the latency it accumulates waiting for a human. Review latency shows up in obvious places: time to first review, time to approval, the dashboards every engineering org already watches. Gate latency hides inside the gap between 'approved' and 'merged', a window most teams do not instrument at all.

The modeled median block times by blocker type, shown below, make the relative weights visible. Human review and requested-changes cycles still carry the longest individual waits, which is intuitive: those involve a person reading and responding. But CI block time is large, frequent, and entirely mechanical, and because it recurs on every single change rather than only on changes that need a second look, it accumulates into a tax that rivals the human latency in aggregate while staying invisible to the tools that track the human side.

The practical takeaway is to measure the full pull-request lifecycle, not just its human stages. A team that instruments time-blocked-on-CI alongside time-to-review will usually discover that the gate is a larger and more addressable source of delay than they assumed, and that fixing it requires no behavior change from any engineer, only a faster and more reliable pipeline underneath the required check.

Fast, self-healing checks are what make automated gating pay off

Automated gating only delivers speed if the gate itself is fast and trustworthy. Required checks and auto-merge are accelerators when the pipeline behind them is reliable, and they are quiet throttles when it is not. The same configuration that ships changes in minutes for one team holds them for hours at another, and the difference is entirely in the pipeline, not the policy.

Elite delivery, with a lead time of less than one day and recovery in less than one hour, depends on a gate that closes once and stays closed. That is incompatible with a required check that fails intermittently on transient errors and re-opens the gate after the team thought a change was on its way. The reliability of the gate is not a CI detail; it is a direct input to the delivery metrics leaders care about.

This is where managed runners and self-healing earn their place in the workflow story. Managed runners keep the required check fast by removing queue and cold-start time, and self-healing retries the transient failures, the network blip, the registry timeout, the undersized-runner OOM, that would otherwise stall a pull request, before a human ever sees a red check. The result is that auto-merge and required checks accelerate delivery instead of quietly throttling it, because the gate fails only on real defects and closes the first time on everything else.

Recommendations

Measure what a blocked PR is actually waiting on

Instrument the gap between approval and merge, not just time to first review. Break down open pull requests by their primary blocker, CI, human reviewer, requested changes, or conflict, and watch the split over time. If CI is the majority blocker, you have located your highest-return investment, and it is the gate, not the reviewer.

Make the required check fast before you make it required

A required check sits on the critical path of every merge, so its wall-clock time is multiplied by your merge frequency. Cache dependencies, shard the suite, and right-size the runner so the gate closes in minutes, not tens of minutes. A slow gate taxes every change whether or not that change had any risk.

Auto-heal transient failures before they reach the gate

The majority of transient required-check failures pass on a clean retry, which means they carried no signal. Retry mechanical failures, network, registry, OOM, cold cache, on a fresh environment automatically so they never turn a green-lit change red. This removes both the re-run latency and the stall-until-noticed failure mode that hurts auto-merge most.

Adopt auto-merge only on top of a reliable gate

Auto-merge is a delegation of human attention, and it is only safe when the gate fails exclusively on real defects. Earn the right to auto-merge by first driving your transient failure rate toward zero. A team that turns on auto-merge over a flaky pipeline has hidden the merge from the one person who would have noticed it was stuck.

Treat the merge queue as a multiplier on gate quality

A merge queue re-runs your required checks against the real target state, which protects the branch but multiplies the cost of a slow or flaky check across the whole queue. Do not adopt a merge queue to paper over an unreliable gate; make the gate fast and self-healing first, then add the queue to close the stale-base gap.

Outlook

Expect the gating stack to keep getting richer and the cost of an unreliable gate to keep rising with it. Required checks, branch protection, auto-merge, and merge queues are converging into a default configuration that most active repositories will run, which means the pipeline behind the gate moves further onto the critical path of delivery every year. The teams that treat gate reliability as a first-class concern will compound their advantage; the teams that bolt on auto-merge and merge queues over a flaky pipeline will feel the opposite compounding as every new mechanism multiplies the cost of each transient failure.

The measurement gap is the thing most likely to close next. As more teams realize that CI, not the reviewer, is their most common blocker, the standard delivery dashboards will start to instrument time-blocked-on-CI as a peer of time-to-review. Once that latency is visible, the case for a fast, self-healing gate stops being an intuition and becomes a line on a chart that leadership can act on.

The durable takeaway is that code review automation succeeded at its first job, enforcing the gate, and its second job is making the gate fast and trustworthy enough that enforcement does not cost delivery speed. That second job is mechanical and well understood: a managed runner layer that keeps the required check fast and a self-healing layer that retries transient failures before they reach a human. The organizations that wire those in will spend the next two years shipping approved changes in minutes while their peers keep losing hours to a gate that fails on everything except real defects.

Methodology

This report combines publicly available data on developer workflows and pull-request practices with Latchkey's modeled estimates of gating adoption, blocker mix, and PR block latency across active repositories. The adoption, blocker-split, and latency figures are illustrative models rather than a primary survey and will vary with repository size, team norms, and pipeline reliability; the DORA delivery bands referenced are used verbatim from the published program. Figures labeled "modeled" are illustrative estimates derived from public pricing and typical pipeline shapes, not a primary survey; figures attributed to a named source reflect that source. Pricing reflects published rates at time of writing and should be verified against current provider pricing.

Sources

• GitHub - Octoverse
• DORA State of DevOps Report
• GitHub Actions documentation
• Stack Overflow Developer Survey

More Latchkey reports