Quality Gates and Enforcement

Your team merged a PR last Friday that introduced a subtle memory leak in the user session handler. The code passed all existing tests, the human reviewer approved it after a quick glance, and the linter had nothing to say. By Monday morning, the service was consuming 4GB of RAM and crashing every six hours. Quality gates are not about catching syntax errors — they are about catching the things that humans and linters miss.

What You’ll Walk Away With

• A multi-layer quality gate architecture that catches issues at every stage
• AI-powered code review workflows that go beyond style checking
• Measurable quality metrics that correlate with actual production stability
• Prompt patterns for deep code analysis including performance, security, and maintainability
• Automated enforcement strategies that do not slow down developer velocity

The Quality Gate Architecture

Quality gates work in layers. Each layer catches different categories of issues, and no single layer is sufficient on its own.

Layer 1: Pre-Commit (Developer Machine)

Cursor

Cursor’s inline AI catches issues as you type. Enhance with explicit quality rules:

.cursor/rules

CODE QUALITY STANDARDS:
Before suggesting any code, verify:
- No functions longer than 50 lines
- No files longer than 300 lines
- Cyclomatic complexity under 10 per function
- All public functions have JSDoc documentation
- Error handling follows our Result<T, E> pattern (no bare try/catch)
- No magic numbers - use named constants
- All database queries go through the repository layer

Claude Code

Claude Code hooks enforce quality gates before code is committed:

{
  "hooks": {
    "PreToolUse": [{
      "matcher": "write|edit",
      "command": "node scripts/quality-check.js \"$FILE_PATH\""
    }],
    "PostToolUse": [{
      "matcher": "write|edit",
      "command": "npx eslint --fix \"$FILE_PATH\" && npx tsc --noEmit"
    }]
  }
}

This ensures every file Claude Code writes passes linting and type-checking immediately.

Codex

Codex enforces quality through its sandboxed execution environment:

codex.md

After every code modification:
1. Run the file's test suite
2. Run the linter on changed files
3. Run type checking
4. If any check fails, fix the issue before proceeding

Quality thresholds:
- All new code must have accompanying tests
- Test coverage for new code must be > 80%
- No lint warnings allowed in new code

Layer 2: Pre-Push (CI Pipeline)

Tip

Copy-paste prompt for AI-powered PR review:

Review this pull request with the depth of a senior engineer who cares about production stability:

1. Architecture Review:
   - Does this change respect our module boundaries?
   - Are dependencies pointing in the right direction?
   - Is the abstraction level appropriate?

2. Correctness Review:
   - Are there race conditions or concurrency issues?
   - Are error cases handled completely (not just the happy path)?
   - Are there edge cases in the input validation?

3. Performance Review:
   - Are there N+1 query patterns?
   - Are there unnecessary allocations in hot paths?
   - Will this scale to 10x current load?

4. Maintainability Review:
   - Would a new team member understand this code in 6 months?
   - Are the test names descriptive enough to serve as documentation?
   - Is the commit history telling a clear story?

For each issue: severity (block/warn/note), file:line, description, and suggested fix.
Do not flag style issues - the linter handles those.

Layer 3: Post-Merge (Continuous Monitoring)

After code merges, AI tools can monitor for quality degradation.

Tip

Copy-paste prompt for codebase health monitoring:

Analyze our codebase health metrics and compare against last month:
1. Average cyclomatic complexity per module (flag any > 15)
2. Test coverage by module (flag any that dropped > 5%)
3. Number of TODO/FIXME/HACK comments added vs. resolved
4. Dependency freshness (packages more than 2 major versions behind)
5. Dead code detection (exported functions with no importers)
6. Duplicate code detection (blocks > 20 lines appearing in multiple files)

Present as a health dashboard with trend arrows (improving/declining/stable).
Prioritize the top 3 items that need immediate attention.

Deep Code Review Patterns

The Five-Lens Review

Apply five distinct analytical lenses to every significant PR.

Cursor

Run each lens as a separate Agent conversation for depth:

Lens 1 - Correctness: Review /src/services/payment.ts changes.
Assume every input is adversarial. Find every way this code could
produce incorrect results, crash, or behave unexpectedly.

Lens 2 - Performance: Same file. Assume 10,000 requests per second.
Find bottlenecks, memory leaks, and unnecessary allocations.

Lens 3 - Security: Same file. You are a penetration tester.
Find every way to exploit this code.

Claude Code

Use sub-agents to run multiple review lenses in parallel:

claude "Review the changes in the current git diff through five lenses.
For each lens, provide separate findings:

1. CORRECTNESS: Logic errors, edge cases, race conditions
2. PERFORMANCE: N+1 queries, memory leaks, unnecessary computation
3. SECURITY: Injection, auth bypass, data exposure
4. MAINTAINABILITY: Complexity, naming, documentation gaps
5. TESTABILITY: Missing tests, untestable patterns, flaky test risks

Rank all findings by severity and present the top 10 across all lenses."

Codex

Perform a five-lens code review on the changes in this PR:
1. Correctness: Will this produce wrong results for any valid input?
2. Performance: Will this degrade under production load?
3. Security: Can this be exploited by a malicious user?
4. Maintainability: Will the next developer understand and modify this safely?
5. Testability: Are there edge cases that the tests do not cover?

Post findings as inline PR comments at the relevant lines.

Quality Metrics That Matter

Beyond Coverage Percentage

Test coverage alone does not indicate quality. Track these metrics instead:

Metric	What It Reveals	Target
Mutation score	Tests actually catch bugs, not just execute code	> 75%
Mean time to detect	How quickly bugs are found after introduction	< 1 sprint
Escaped defect rate	Bugs that reach production	< 2% of changes
Review turnaround	How long PRs wait for review	< 4 hours
Rework rate	PRs that need > 2 review rounds	< 15%
Build reliability	CI pipeline pass rate	> 95%

Tip

Copy-paste prompt for mutation testing setup:

Set up mutation testing for our TypeScript project:
1. Install and configure Stryker Mutator for our Jest test suite
2. Configure it to mutate: /src/services/ and /src/utils/ (skip tests and types)
3. Set thresholds: break at 60%, low at 70%, high at 80%
4. Add to our CI pipeline as a weekly job (mutation testing is slow)
5. Generate an HTML report showing which mutations survived

Run it on /src/services/payment.ts first as a proof of concept.
Show me which test gaps the mutations reveal.

Enforcing Standards Across Teams

Shared Quality Configuration

1. Create a shared config package

   A package in your monorepo or a separate npm package that contains ESLint configs, TypeScript configs, Prettier configs, and your AI rules files.

2. Distribute through package management

   Each project extends the shared config. Local overrides must be documented and approved.

3. Enforce in CI

   The pipeline checks that shared configs are not overridden without approval.

4. AI rules inherit from shared config

   Your .cursor/rules or CLAUDE.md files reference the shared standards document.

5. Monthly quality reviews

   AI-assisted codebase health checks run monthly, comparing teams against shared benchmarks.

When This Breaks

“Developers feel like quality gates slow them down.” Your gates are too strict or catching the wrong things. Focus quality gates on high-severity issues (security, correctness, performance). Leave style and formatting to automated formatters that fix issues silently rather than blocking.

“AI code review produces too many false positives.” Tune your review prompts. Add “Do not flag style issues” and “Only report issues that could cause bugs, security vulnerabilities, or performance problems in production.” Review the AI’s findings for a week and adjust the prompt based on what was actually useful.

“Teams are gaming the metrics.” If teams are writing meaningless tests to hit coverage targets, switch to mutation testing. You cannot game mutation scores without writing tests that actually verify behavior.

“Quality is inconsistent between AI-generated and human-written code.” Apply the same quality gates to all code regardless of origin. The CI pipeline does not care who (or what) wrote the code.

What’s Next

Unit Testing Strategies Generate comprehensive unit tests that catch real bugs.

CI/CD Pipelines Build quality gates into your deployment pipeline.

Cost Governance Balance quality investment against development speed and cost.