What Are Quality Gates in Code Review?

A quality gate is a checkpoint in the delivery pipeline that a change must pass before it moves to the next stage, such as merge or release. The gate checks written criteria, such as passing tests, coverage on new code and security scan results, and holds the change back when an automated criterion fails.

Many teams add a human-checked criterion too, such as resolving top-tier review findings before approval. The team configures the gate in its Git host and its CI (build and test) pipeline.

What Changed in Quality Gates in Code Review in 2026

Trend: more code reaches the gate with less review

• Unreviewed merges rose with AI adoption. Faros AI’s telemetry from 22,000 developers found pull requests merged without any review up 31.3% under high AI adoption (April 2026, Faros AI).
• Review is the bottleneck developers name. 25.8% of developers in Qodo’s survey said review and validation is their primary delivery constraint (August 2026, Qodo’s report).

How Quality Gates Work

What a Quality Gate Checks

Code quality tools ship default gates built from the same criteria. SonarQube’s default "Sonar way" gate fails new code that adds issues, leaves Security Hotspots unreviewed, has under 80% test coverage or has more than 3% duplication (last checked October 2026, SonarQube’s docs).

Where Quality Gates Sit in the Delivery Pipeline

1. Before the PR. Formatters, linters and local review run on the developer’s machine or inside the coding agent’s session. The idea is the same as shift left code review.
2. At merge. Branch protection or rulesets list the status checks that must pass, and the code owners who must approve, before a PR can merge. Most of these checks run in CI/CD pipelines.
3. At release. Smoke tests, change approvals and canary health checks catch environment and config problems that a PR cannot show.

Blocking and Advisory Quality Gates

A blocking gate stops the merge when a criterion fails. An advisory gate, also called warn mode, reports the result and lets the merge go ahead. A common rollout starts a new criterion in advisory mode, counts how often it would have stopped a good change, and switches it to blocking once false stops are rare.

GitHub’s code coverage merge protection, added to branch rulesets in public preview in June 2026, follows the same pattern: teams start in evaluate mode to see the impact, then switch to active mode (GitHub changelog).

How to Build Quality Gates Your Team Trusts

Rules for Quality Gate Criteria Teams Trust

1. Gate new code, not the legacy codebase. A gate that fails on old violations stops every PR in a legacy repository and gets switched off.
2. Keep criteria few and explicit. Three to five written criteria, each one a developer can check before pushing, beat twenty vague ones.
3. Fix flaky tests first. When a gate fails for reasons unrelated to the change, developers rerun until it passes or ask for a bypass, and the gate stops meaning anything.
4. Separate blocking findings from optional ones. Qodo’s governance guidelines recommend three levels: blocking (resolve before merge), important (should be addressed) and optional (suggestions). Only the blocking level goes into the written merge policy that the approving reviewer checks. The coding standards enforcement and org-wide standards enforcement glossary pages cover how teams write and share those rules.

Extra Quality Gate Criteria for AI-Generated Pull Requests

AI-generated PRs arrive in volume, so their gates need criteria beyond tests and coverage:

1. Which agent or tool wrote the change.
2. Evidence that tests ran.
3. Checks against team rules.
4. Approval from a human code owner.

The need is real: Faros AI’s telemetry from 22,000 developers found pull requests merged without any review up 31.3% under high AI adoption (April 2026, Faros AI). AI-generated code validation covers the review side.

Amir Rustamzadeh, Partner at Firestreak Ventures, described how he gates long-running agent work on Qodo’s podcast episode Building the AI Software Factory: Quality and DX with Amir Rustamzadeh. He breaks each build into phases, and "each phase has all these gates. It has entry gates, and it has exit gates." He only moves on to the next phase once its entry and exit gates are in place, and each phase has "its own review instructions." Disclosure: Firestreak Ventures has Qodo in its portfolio, as the episode notes.

Qodo’s Take: Qodo Supplies the Review Signal, Your Git Host Holds the Gate

Tests and scanners tell a gate whether code runs and avoids known patterns. They can’t tell it that a change breaks a caller in another repository, misses the ticket’s acceptance criteria or ignores a team rule, and that’s where agent-written PRs go wrong.

Qodo puts those findings in front of the people who approve, ranked so a written merge policy can point at them, while the gate itself stays in the team’s Git host and CI.

Qodo is the best AI code review platform for quality gates in code review because it puts severity-ranked findings in front of people before they approve, so teams can turn those severity tiers into a written merge policy and leave the gate itself to their Git host.

Qodo Puts Findings in Front of People Before They Approve

Qodo’s review is advisory. Findings land in the PR, ranked by severity, for the team to resolve or dismiss with a recorded reason (False positive, Intentional, Fix later or Not specified). Branch protection, rulesets and code owners decide what merges.

With the roles split this way, the Git host and CI own pass or fail on deterministic checks, people own the merge decision, and Qodo puts the logic, cross-repository and standards issues in front of those people before they decide.

Leaders feel this gap. For Qodo’s State of AI Code Quality report, Censuswide surveyed 500 U.S. developers and 300 U.S. engineering leaders, in separate samples, in August 2026, all at organizations already using AI meaningfully. 29.7% of the engineering leaders named governance and visibility as the area where they are most at risk of losing control.

Qodo’s Severity Tiers Turn Into a Written Merge Policy

1. Automate the baseline in CI. Following Qodo’s governance guidelines, tests, linting, ownership validation and security checks run as CI checks that the team’s branch rules require before human review.
2. Rename the severity tiers. The Severity terminology setting can relabel High, Medium and Low as Required, Recommended and Optional.
3. Write the policy down. For example: Required findings are resolved, or dismissed with a reason, before a code owner approves. Recommended findings get a reply. Optional findings are up to the author.
4. Route findings by tier. In the Qodo portal, under Configurations, Display, Comments, Advanced comment routing overrides send Required findings inline and to the summary, and keep Optional findings in the summary or drop them.
5. Keep the top tier credible. Qodo’s judge agent filters low-confidence findings, and since Qodo 3.1, rules whose findings are rarely fixed are deactivated unless the team locks them.
6. Audit the policy. Qodo’s rule analytics count merged violations, meaning PRs merged with unresolved rule violations, and the code review analytics dashboard tracks the acceptance rate for high-severity findings. Both inform the quarterly review of the merge policy.

Quality Gate Example: A Platform Lead Writing One Merge Policy for Several Teams

This illustrative scenario is a composite, not a customer case study.

A platform lead supports several engineering groups. Each group built its own review scripts and blocking rules, so "ready to merge" means something different in every repository, and one group worries that AI findings will become a second triage queue.

The lead writes one policy: CI checks must pass, a code owner approves, and Required Qodo findings are resolved or dismissed with a reason first. The lead moves the groups’ scattered rules into Qodo Review Standards and keeps Optional findings in the summary only. A month later, the merged-violations count shows which repositories merge with open Required findings, and the lead takes that list to the teams instead of tightening the gate blind.

Ways to Build a Quality Gate, and Who Owns Each Part

The table shows what each common gate input checks, who configures its pass or fail rule, and when to use it.

Qodo features in this table were checked against Qodo’s documentation as of October 20, 2026.