Capability 03 of 04 · Development
Code Review & Quality
How AI-generated code is reviewed, validated, and approved before merging. Model upgrades do not buy security: the average GenAI security pass rate held flat year on year at 56%, and coding-specialised models scored no better than general-purpose ones.
5
maturity levels
15
practices
15
guides
L1 · Stage 01Assisted
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
- 02CI runs at least one automated check on each change
- 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 02Delegated
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
- 01An AI reviewer comments on pull requests in the repositories the team works in (CodeRabbit, Qodo, or equivalent)
- 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 04GovernedMost 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→
- Classification is fully algorithmic: the same change always lands in the same classThe verdict on a change is produced by algorithm rather than by whoever happened to look at it, and it is reproducible: the same change always lands in the same class.guide→
- Policy-based auto-approval driven by a risk classifier trained on your own incident history (Zalando: 33% of PRs auto-approved as low-risk, 20-40% lead-time reduction) - and every agent PR carries a named human owner, or it does not merge (agentic PRs merge at 79% elite vs 37% fair, and the gap is ownership)Setting a 60%+ Green rate as policy turns code quality into a measurable team KPI, with a risk classifier trained on your own incident history deciding what qualifies and a named human owner on every agent PR.guide→
Criteria - what to measure
- 01Automated Green/Yellow/Red classification runs on every PR
- 02Classification is deterministic: the same change lands in the same class on every run
- 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 05Self-improving
Practices - what it looks like3 guides
- Agent fleet self-reviews (error → fix → converge), bounded: a drafting agent never approves its own work, and LLM defect detection degrades across successive review roundsAt fleet scale, agents review and correct their own work in tight feedback loops - running tests, observing failures, fixing root causes and iterating to a passing state - bounded by a separate verifier, because a drafting agent must never approve itself and defect detection decays with each review round.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 →