What are quality gates?

A quality gate is a pass or fail decision that a code change must clear before it moves to the next stage, such as being merged or deployed. It compares evidence about the change (test results, review findings, approvals, policy decisions) against rules agreed in advance, and blocks the change automatically when the evidence falls short. What makes it a gate rather than a report is enforcement: a failed gate stops the change.

Where quality gates come from

The idea is older than continuous integration. Project management has long used stage gates: a project moves from one phase to the next only after a review against set criteria. Manufacturing has inspection points that a part must pass before assembly continues.

In software, the term became common through static analysis tools that let teams define thresholds, such as no new critical issues or a minimum test coverage on new code, and report the project as passing or failing them. Git hosts brought the same idea to pull requests with branch protection: a branch can require certain status checks to pass, and a number of approvals, before a merge is allowed.

Today a quality gate usually means a combination of those: automated evidence from CI, findings from code review tools, and human approvals, evaluated together at a defined point in the delivery pipeline.

What a quality gate checks

Gates are built from evidence. The common kinds are:

• Build. The code compiles and the artifact can be produced.
• Tests. The test suite passed on this exact version of the change.
• Coverage. Test coverage meets a floor, often only on new or changed code.
• Review findings. No open issues above a severity threshold from static analysis, AI review or security tools.
• Dependencies and licenses. No banned licenses and no known-vulnerable components above a threshold.
• Approvals. One or more people, other than the author, approved the change.
• Policy. The change does not touch protected paths, or it has the extra approval those paths need.
• Promotion. The change was deployed to an earlier environment, such as staging, before production.

Not every gate needs all of these. A gate before merge usually focuses on tests, review and approval. A gate before production adds promotion and release checks.

Quality gates vs checks

The words are often used loosely. The distinction is worth keeping, because it decides what actually stops a bad change.

A check becomes part of a gate when something refuses to proceed because of its result.

Properties of a good quality gate

It fails closed. If a test runner crashes, a review times out or the gate service is unreachable, the change is refused. A gate that lets changes through on error is silently off when you need it most.

No evidence is not a pass. A change with no test run, no review or no SBOM has not passed those checks. The gate either blocks it or shows the gap clearly. It never displays a missing result as green.

Evidence matches the version. A test run on an earlier commit says nothing about the current one. If the change is edited after its tests ran or after it was approved, those results should no longer count.

Reasons are readable. "Denied" is not enough. The gate should say which finding, which test or which rule stopped the change, so the author can act on it.

Every path uses the same gate. If a merge from the console is gated but a merge on the Git host is not, the gate has a side door. The same evaluation should be callable from CI.

Overrides are rare and recorded. Sometimes a team needs to ship despite a finding. That should be an explicit triage decision by an authorised person, kept with the change, not a disabled check.

Thresholds ratchet. Start with rules the codebase can meet today, then tighten them. A gate that fails on every change is soon bypassed.

Quality gates for AI-written code

AI agents change the economics of review. They can produce more changes than a team can read line by line, and each change can look plausible while being subtly wrong. Gates matter more in that setting, for three reasons.

First, the author's confidence is not evidence. An agent reporting that the tests should pass is a claim; a recorded test run on the exact change is evidence. Gates should read records produced by running things, not the agent's summary.

Second, the review must have actually happened. AI review can fail quietly, by timing out or returning text that is not a usable result. A gate has to tell "reviewed, nothing found" apart from "not reviewed".

Third, separation of duties. The person who asked the agent for a change is, in effect, its author. They should not be the only one approving it when someone else can. See How do AI agents fit into the software lifecycle? for where that approval belongs.

How to design quality gates

1. Map the path to production. List every way a change can reach your main branch and your production environment: console merges, Git host merges, direct pushes, release scripts. A gate only protects the paths that cross it.
2. Choose the gate points. Most teams need at least one gate before merge and one before production.
3. List the evidence for each point. Tests on the current version, review findings, approvals, licenses, prior deployment. Write down where each piece comes from.
4. Set explicit thresholds. For example: block on high and critical findings, on any failing test, and on a missing review. Write the rules down where the team can read them.
5. Decide the missing-evidence cases. What happens with no tests, no SBOM, or no review? Decide it on purpose, and never show missing evidence as a pass.
6. Make it fail closed. Errors in the gate deny the change and say so.
7. Expose it to CI. Make the same decision available to your pipeline, so merges outside your tooling can be held to it.
8. Define triage and overrides. Who can dismiss a finding, and how that is recorded.
9. Review the gate itself. Look at what it blocked and what slipped past. Tighten thresholds as the codebase improves.

How AI CodeOps does it

In AI CodeOps, every AI change passes a quality gate before it becomes a pull request, and again before the console merges it. The change is held if the AI findings review did not complete, if a finding of high or critical severity is still open, acknowledged or in progress, or if the project's tests fail in the sandbox. A test result only counts for the version it ran on. A person must approve, and the person who started the session cannot cast the approving vote while another approver exists in the workspace. Workspace policies can deny the pull request or require that approval for sensitive paths. Every gate fails closed.

Your CI can ask the same gate for a verdict on a pull request or commit, with a workspace API key, and add stricter rules per call:

curl -s -X POST "https://<your-console>/api/release/check" \
  -H "Authorization: Bearer $WORKSPACE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"pullRequestURL":"https://github.com/acme/checkout/pull/42","blockingSeverity":"medium","requireDeployedTo":"staging"}'

A denied answer, trimmed to the main fields:

{
  "allowed": false,
  "evidenceComplete": true,
  "summary": "HIGH security: Coupon code is passed to the pricing query without validation",
  "reasons": [
    "HIGH security: Coupon code is passed to the pricing query without validation",
    "Not yet deployed to \"staging\" — promote there before releasing"
  ],
  "testFailures": [],
  "coverageShortfall": null,
  "priorEnvironmentMissing": { "required": "staging" },
  "requiredGatesPassed": true,
  "missingRequiredWorkflows": []
}

The endpoint returns HTTP 200 for both outcomes, so read allowed. A change with no matching sessions is denied, and an evaluation error returns allowed: false. Other options include minCoveragePct, requiredWorkflows, blockOnInFlight and disallowedLicenses, which checks the project's latest recorded SBOM.

See AI code quality gates for the overview, Quality gates for triage and where results appear, and the API reference for every field.

Go deeper

• Fail open vs fail closed: how gates end up passing on error, how to decide missing-evidence cases, and how to fail closed without stalling releases.
• Test coverage gates: project floors, new-code coverage and ratchets, what coverage cannot prove, and what to pair it with.