How strict should we set coverage at the start?

Gate on deltas at ~80% for lines/functions and 75% for branches. Leave the global coverage alone initially and ratchet +2–5% per sprint. Blocking on legacy global coverage from day one will stall delivery.

What about languages not shown (Go, Java)?

Same pattern. For Go, use `golangci-lint`, `go test -coverprofile` plus `go tool cover` for thresholds, and `gosec`. For Java, use `spotless`, `errorprone`, `jacoco` coverage, and `OWASP Dependency Check` or CodeQL. Keep the workflow reusable with an input to switch stacks.

Is SonarCloud required?

Not required. If you already use Sonar, enable its quality gate and focus on delta coverage and new critical issues. Otherwise, keep it simple with ESLint/ruff + `diff-cover` and CodeQL. Add Sonar only if you’ll actually look at its dashboards.

How do we handle exceptions without opening floodgates?

Use a waiver file (`.gate-waivers.yaml`) or PR label that requires an owner, reason, and expiry date. CI should fail if the waiver is expired or missing an owner. Publish waivers in the weekly gate report.

Will this slow my team down?

In the first 2–3 weeks, yes a bit. After that, PR discussions shift from nits to substance and rework drops. The net effect is faster merges and fewer incidents. We’ve seen 30–40% reductions in escaped defects with a stable gate.

Platform-productivity · Nov 13, 2025 · 10 minute read

Quality Gates That Don’t Suck: The Boring Automation That Stops Technical Debt at the PR

Stop arguing in PRs. Ship a paved-road quality gate that blocks debt by default and only makes exceptions explicit.

Back to all posts

Quality Gates That Don’t Suck: The Boring Automation That Stops Technical Debt at the PR

Key takeaways

Implementation checklist