Designing a quality gate your team won't route around

A quality gate is a promise: "we won't merge code that fails these checks." The fastest way to break that promise is to make the gate so strict that shipping anything requires an override — because once overrides become routine, the gate is theater.

Gate on the delta, not the absolute

The single most important rule: gate on what the change introduces, not on the state of the whole codebase. If you fail every PR because the legacy code has 3,000 issues, developers learn to ignore the red X. If you fail a PR only when it adds a new critical issue or drops coverage on the lines it touched, the gate is fair — the author can actually fix what they broke.

Start loose, tighten deliberately

A good rollout looks like this:

1. Observe. Turn the gate on in report-only mode for a sprint. Look at what would have failed.
2. Block the unarguable. New critical bugs, new hardcoded secrets, a coverage cliff. Nobody defends those.
3. Ratchet. Once the team trusts it, tighten one threshold at a time.

Make failure actionable

When the gate fails, the message should say exactly what to do: which issue, which line, and the suggested fix. A gate that says "quality score too low" teaches nothing. A gate that says "this PR adds a null-dereference at auth.js:214" gets fixed in minutes.

new_critical_issues: 0        # block new criticals
coverage_on_new_code: ">= 80%"
new_secrets: 0

The goal isn't to catch everything. It's to make the right thing the easy thing — so the gate becomes a tool the team relies on, not an obstacle they route around.