Capability 03 of 04 · Development
Code Review & Quality
How AI-generated code is reviewed, validated, and approved before merging. AI code has 1.7x more issues and 2.74x more security vulnerabilities - review is now critical infrastructure.
5
maturity levels
15
practices
15
guides
L1 · Stage 01Ad-hoc
Practices - what it looks like3 guides
- Every PR gets human reviewWhy relying entirely on human code review creates a quality bottleneck that scales poorly and establishes the baseline every higher maturity level is designed to escape.guide→
- Review turnaround measured in hours; 78.9% of agentic PRs pass through a single reviewerThe 2-hour average wait for code review feedback is a measurable symptom of L1's structural review problem - and a concrete baseline to improve against.guide→
- AI and human code share one review pathAt L1, teams can't see how much of their codebase is AI-generated - making it impossible to measure adoption, calibrate review depth, or understand quality patterns.guide→
Criteria - what to measure
- 01All code is reviewed by a human before merge
- 02Basic CI checks run on changes
- 03Code review turnaround is tracked (even if slow)
- 04Team is aware that AI-generated code has higher defect rates (1.7x issues, 2.74x security vulnerabilities)
L2 · Stage 02Guided
Practices - what it looks like3 guides
- AI-assisted review suggestions (CodeRabbit, Qodo, Claude Security beta)Using AI tools to generate a first-pass review frees human reviewers from routine checks and focuses their attention on architecture and business logic.guide→
- Basic linter rulesA shared linter configuration enforced in CI is the fastest, cheapest quality investment a team can make - and the essential foundation for every higher-level quality automation.guide→
- Diff awareness - reviewer knows it's AI code; reject code the human can't understand even if CI is green; humans write the PR description (the why)When reviewers know which parts of a PR are AI-generated, they can calibrate review depth to match the actual risk - spending more time on business logic and less on syntax.guide→
Criteria - what to measure
- 01AI-assisted review tool (CodeRabbit, Qodo, or equivalent) is active on all repositories
- 02Linter rules are configured and run in CI on every PR
- 03PRs clearly indicate whether code is AI-generated or AI-assisted (labels, tags, or commit metadata)
- 04AI review suggestions are triaged (accepted/rejected) rather than ignored
- 05Linter configuration is committed to the repository and versioned
L3 · Stage 03Systematic
Practices - what it looks like3 guides
- Lint-as-architecture (standards = enforced rules; Vercel Konsistent for agents and humans)Custom lint rules that enforce architectural decisions turn code review comments into machine-checked constraints - so architectural violations are caught at CI time, not weeks later in production.guide→
- AI review agent as first pass (self-verification; adversarial verification pass on whole-repo scans)A dedicated AI review agent that automatically reviews every PR before human reviewers are notified transforms review from a bottleneck into a parallel, always-available quality gate.guide→
- Architecture guardrails: Bug → Codify → Lint RuleA systematic process for converting recurring bugs into permanent lint rules turns each incident into an improvement to the quality gate, progressively hardening the codebase against known failure modes.guide→
Criteria - what to measure
- 01AI review agent runs as a first-pass reviewer on every PR before human review
- 02Lint rules enforce architectural standards (not just style) - the "Bug to Codify to Lint Rule" pipeline is active
- 03At least 3 architectural guardrail rules have been created from past bugs or incidents
- 04AI review agent findings are categorized by severity (info, warning, blocking)
- 05New lint rules are proposed automatically when recurring review comments are detected
L4 · Stage 04OptimizedMost teams aim here
Practices - what it looks like3 guides
- Green/Yellow/Red auto-evaluationA traffic-light quality evaluation system that replaces binary pass/fail CI with a nuanced, policy-driven assessment - enabling selective automation and focusing human review where it genuinely adds value.guide→
- Green = auto-merge (fully algorithmic)Automatically merging PRs that meet all quality criteria removes human review from the critical path for routine changes - and is the step that most teams find psychologically difficult but transformatively efficient.guide→
- Policy-based auto-approval: 60%+ Green target (anchor in mergeability + post-merge outcomes - OpenAI retracted SWE-Bench Pro; 63% of "solved" tasks were retrieved, not derived)Setting a 60%+ Green rate as an organizational policy turns code quality into a measurable team KPI - and makes the auto-merge system self-reinforcing as teams work to qualify more PRs.guide→
Criteria - what to measure
- 01Automated Green/Yellow/Red classification runs on every PR
- 02Green-classified PRs auto-merge without human review
- 03Auto-approve rate target of 60%+ Green PRs is tracked and reported
- 04Yellow PRs receive expedited human review (within 1 hour)
- 05Classification model accuracy is validated monthly against human review outcomes
L5 · Stage 05Autonomous
Practices - what it looks like3 guides
- Agent fleet self-reviews (Cursor model: error → fix → converge)At fleet scale, agents review and correct their own work in tight feedback loops - running tests, observing failures, fixing root causes, and iterating until the code converges to a passing state without human intervention.guide→
- Human review only for Red (architectural)At L5, human engineering attention is reserved exclusively for Red PRs - architectural changes, security-sensitive modifications, and business logic decisions that automated systems can't confidently evaluate.guide→
- Continuous auto-refactoring in backgroundBackground agents that continuously identify and execute code quality improvements - extracting duplication, simplifying complexity, updating deprecated APIs - eliminate technical debt accumulation without dedicated refactoring sprints.guide→
Criteria - what to measure
- 01Agent fleet self-reviews code (error-fix-converge loop) before submitting for merge
- 02Human review is limited to Red-classified PRs (architectural decisions only)
- 03Continuous auto-refactoring runs in background without human initiation
- 04Agent self-review catches 90%+ of issues that would be found by human review
- 05Auto-refactoring PRs are tracked separately and have their own quality metrics
From the Field
Recent releases, projects and discussions the AI Radar classified into this capability.
discovered
Claude Code plugin — code quality hooks, knowledge graph, impact-aware reviews, decomposition enforcement. Babysitter for your AI's code quality.
discovered
GitHub-style diff viewer for reviewing code changes. Works with Claude Code, Cursor and other AI tools.
discussion
AI agents pass the tests but break the architecture. What's your review process?
article
GitHub backs down, kills Copilot pull-request ads after backlash
discussion
I scanned 10 popular vibe-coded repos with a deterministic linter. 4,513 findings across 2,062 files. Here's what AI agents keep getting wrong.
discovered
AI code reviews grounded in 10 classic engineering books — decay risk diagnostics with book citations, severity labels, and 4 analysis modes
article
Extreme Harness Engineering for Token Billionaires: 1M LOC, 1B toks/day, 0% human code, 0% human review — Ryan Lopopolo, OpenAI Frontier & Symphony
article
AI Code Reviews for GitLab – custom agents – powered by Ollama
Which level is your team at in Code Review & Quality?
The criteria above are what we check in a facilitated assessment. Run it yourself to place this capability, see which gates you have passed, and compare it against the other 3 in Development.
Start the assessment →