AI code review

Pull-request review is a bottleneck: reviewers are scarce, diffs are large, and AI-assisted coding (CODE-001, CODE-002) is increasing the volume of code to check. AI reviewers read each pull request with repository context, summarise it, comment on likely bugs, security problems and guideline violations, and propose fixes. Humans keep the merge decision and focus on design and intent.

Problem & value

• Today: a peer reviews each change, supported by linters, static analysis and CI. Reviews wait hours or days, quality varies with reviewer attention, and knowledge of conventions sits in people's heads.
• AI value: first-pass feedback within minutes of opening a PR; consistent application of team rules; PR summaries that speed up human review; catches of null-handling, concurrency, error-handling, injection and secrets issues that rule-based linters miss; less context-switching for authors.
• Evidence caveat: vendors publish detection and acceptance-rate numbers, but benchmarks are mostly vendor-run and measure different things. Measure on your own repositories before trusting any figure. Review-comment noise (false positives) is the main adoption risk.

Variants

• Open-source maintainers / small teams: free or cheap GitHub/GitLab bot on every PR.
• Enterprise: multi-repo reviewer with organisation-wide rules, codebase indexing, audit trail, SSO.
• Regulated engineering (medical, automotive, finance): AI as additional reviewer; the human sign-off required by the quality system remains (see CODE-020).
• Security-focused review: AI triage of SAST findings and secure-coding checks, see SEC-004.
• IDE / pre-commit review: local review of uncommitted changes before the PR (CODE-001).
• Agent output gate: review of PRs created by coding agents (CODE-002), where an independent reviewer model reduces correlated errors.
• Private use: hobby projects can use free tiers for open-source repositories.

How it works

1. PR opened / updated (webhook)
2. collect diff, PR description, linked ticket, CI/linter/SAST results
3. retrieve context (changed files in full, callers/callees, similar past changes, repo rules)
4. LLM analysis (summary, per-hunk or agentic multi-step investigation, optional verification run)
5. filter & rank (dedupe, severity, confidence threshold, suppress style noise)
6. post inline comments + suggested patches + summary
7. human reviewer decides; feedback (resolved / dismissed) tunes future comments

• Context is decisive: diff-only reviews miss cross-file effects. Better tools index the repository (embeddings, code graph) and let an agent open files, run tests or grep before commenting.
• Rules as prompts: guideline files (e.g. REVIEW.md, CLAUDE.md, .coderabbit.yaml, Copilot instructions) encode team conventions and what to ignore.
• Human-in-the-loop: findings are advisory; branch protection still requires a human approval. AI approvals should not count toward required reviewers for critical code.

Data preparation

The reviewer sees pull request diffs plus repository context. The sources are Git hosting (GitHub, GitLab, Bitbucket, Azure DevOps), CI results, linter and SAST output, and the team's coding guidelines, which often sit in a wiki, a PDF or in people's heads. Typical gaps: unwritten conventions, outdated style guides, huge PRs that exceed useful context, noisy linters that bury real findings, and secrets or customer data in diffs.

Preparation steps: (1) turn the coding guidelines into a short, concrete REVIEW.md or CLAUDE.md with examples of accepted and rejected patterns, see PREP-016 and PREP-014; (2) make linters, formatters and tests run in CI so the bot only handles what tools cannot; (3) agree on a PR size limit; (4) configure path exclusions for generated code and secrets; (5) collect 20 to 30 past PRs with known bugs or accepted review comments as a test set, see PREP-018 and PREP-020; (6) record which bot comments developers accept or dismiss (PREP-021) and tune the rules from that.

Effort share: low, roughly 10 percent. Writing the rules file is the main task; the rest is configuration.

Implementation paths

Which path for whom

• SMB: A - review bots (Copilot code review, CodeRabbit, Qodo, GitLab Duo) install in minutes on the existing platform and the process is standard.
• Enterprise: B - a custom review pipeline on cloud APIs can apply company-specific guidelines, combine SAST and CI results and keep logging under control.
• Developer: B - BYOK review actions and CLIs in CI give flexible model choice and pay-per-use costs.
• Public sector: C - code and review comments stay on own infrastructure with an open-weight model, which supports sovereignty and procurement rules.

Path A — Buy (recommended)

• Platform-native: GitHub Copilot code review, GitLab Duo code review, Bitbucket/Atlassian Rovo Dev review features.
• Dedicated reviewers: CodeRabbit, Qodo Merge (commercial PR-Agent), Greptile, Graphite Agent (Graphite was acquired by Cursor in Dec 2025), Cursor Bugbot, Sourcery, Ellipsis; Anthropic's managed Claude Code Review (launched March 2026 as a research preview; the current docs no longer carry a preview label; Team/Enterprise plans, GitHub only, not available with Zero Data Retention or HIPAA configuration) [1].
• Quality platforms with AI: SonarQube/SonarCloud AI CodeFix and AI Code Assurance (Sonar, CH), Codacy, DeepSource, Snyk Code.
• EU angle: few EU-native pure reviewers; check EU data residency, subprocessors and no-training clauses (CodeRabbit, GitHub and GitLab offer enterprise terms; SonarSource is Swiss; JetBrains Qodana is CZ-based static analysis; Mistral's Codestral/Devstral can be used via EU-hosted tools).
• Choose A when: code is on GitHub/GitLab, no hard on-prem requirement, goal is quick payoff.

Path B — Build on cloud APIs

• Models: Claude, GPT, Gemini frontier models or Mistral Codestral/Devstral (EU provider) via EU-region endpoints (Azure OpenAI EU, Vertex AI EU, AWS Bedrock Frankfurt/Paris).
• Building blocks: the anthropics/claude-code-action GitHub Action for @claude mentions and custom review workflows [2]; open-source PR-Agent as a GitHub Action/webhook with your own model key [3]; reviewdog to post findings as PR annotations.
• Orchestration: CI job on pull_request events → fetch diff → agent with read-only repository tools → post review via GitHub/GitLab API. Treat PR content as untrusted input (prompt injection); run with minimal token permissions and never on secrets-bearing fork PRs.
• Choose B when: you need custom rules, an internal model gateway or cost control.

Path C — Self-host (open source)

• Tools: PR-Agent (Apache-2.0) with a local OpenAI-compatible endpoint; Tabby; Continue; CodeRabbit and Greptile offer self-hosted enterprise deployments (commercial).
• Models: open-weight coder models such as Qwen3-Coder, Devstral, DeepSeek-Coder-V2/V3 family, GLM and gpt-oss, served by vLLM, SGLang or Ollama.
• Hardware: HW2 for ≤30B models on small diffs; HW3 for 70–120B-class models and long context; HW4 for the largest coder models. Quality of small models on subtle bugs is clearly lower.
• Choose C when: source code may not leave the premises (defence supply chain, banking, IP-sensitive).

Path D — Custom training

Rarely justified. Fine-tuning on historic review comments and accepted/rejected suggestions can reduce noise and encode house style; it needs thousands of resolved comments and an evaluation set. Usually rules files plus retrieval of past reviews achieve most of the benefit.

State of the art (2026)

• Agentic review (tool use, running tests, reading call sites) has replaced diff-only prompting in leading products; multi-agent setups split bugs, security and conventions, then verify findings to reduce false positives.
• Learning from feedback: products adapt to dismissed/accepted comments and repository conventions; one-click patches are standard.
• Review of AI-written code is the growth driver: more PRs, larger diffs, plausible but subtly wrong code.
• Limits: false positives and nitpicking erode trust; weak at business-logic intent, architecture fit and undocumented requirements; large diffs exceed attention; non-deterministic (the same PR may get different comments); models can approve insecure code or be steered by instructions hidden in code, comments or PR text. AI review complements, not replaces, tests, SAST and human review.
• Benchmarks for review quality are young and vendor-driven; use your own labelled PR set.

Shared resources & combinations

• Same stack (llm-code, agent-framework, embedding-text, vector-db): CODE-001 IDE assistants, CODE-002 coding agents, CODE-004 test generation, CODE-006 documentation, CODE-014 bug fixing, CODE-021 refactoring.
• Codebase index (embeddings, code graph) is shared with CODE-006 and CODE-001.
• Security: SEC-004 (SAST triage, auto-fix), SEC-016 (malicious dependency detection).
• Model server: one HW3 inference server can serve review, completion and agents.

Effort, cost & KPIs

• Path A: hours to days to enable; per-seat monthly pricing (typically tens of USD/EUR per developer) or usage-based; check current price lists.
• Path B: 2–6 weeks for a production workflow; token cost scales with diff size and agentic depth.
• Path C: 1–3 months; GPU server plus maintenance; lower quality unless large models are used.
• KPIs: time to first feedback, PR cycle time, share of AI comments accepted/resolved, false-positive (dismissed) rate, defects escaped to production, reviewer hours saved, security findings caught pre-merge. Watch for gaming and for reviewers rubber-stamping AI-reviewed PRs.

People & change

Involve the development lead as process owner and management for budget and policy (GUIDE-007). IT and information security configure permissions and repository access, the DPO checks the AVV and whether code or comments contain personal data. Reviewers and developers are the real users and should co-write the review rules.

Works council: depends. Review tools generate statistics on who authors how many defects and how fast reviews are done, which is suitable for performance monitoring under section 87(1) no. 6 BetrVG even if not intended; section 90(1) no. 3 requires early information. Switch off per-person dashboards or fix this in a works agreement (GUIDE-004). Public sector: staff council.

AI literacy: support staff under Art. 4 AI Act with a short session on what the bot catches and misses, false positives and automation bias (GUIDE-006). Run a pilot with one or two teams for 4 to 6 weeks in advisory mode (comments only, no blocking checks) and measure accepted comment rate and review time (GUIDE-009). Typical concerns are noisy comments, loss of mentoring through human review and fear of being judged: keep human approval mandatory for merges, let developers dismiss comments without justification, and communicate that the bot complements, not replaces, peer review (GUIDE-008).

Risks, regulation & compliance

• EU AI Act: minimal risk for developer tooling; no Annex III category. AI literacy duty (Art. 4) applies. Code review of a safety component does not itself change the product's classification, but the quality management system must define the AI's role. Do not use review output to evaluate or rank individual developers: that could fall under employment-related high-risk use (Annex III, point 4).
• GDPR: code contains personal data of authors (names, emails in commits) and sometimes test data or secrets; sign a DPA, confirm EU region, no-training and retention terms; avoid sending production data.
• Intellectual property and confidentiality: vendor code-retention and training policies; export-control or customer NDAs may require Path C. Zero-data-retention modes may disable some features.
• Security: prompt injection via PR content, over-privileged tokens, leakage of secrets in comments; use least-privilege tokens and secret scanning.
• Cyber Resilience Act / sector rules: AI findings can support secure-development evidence, but responsibility stays with the manufacturer; ISO 26262, IEC 62304 and DORA expect documented human review.
• Mitigations: advisory-only comments, mandatory human approval, audit logs, periodic accuracy sampling.

Getting started

1. Pick 3–5 recent PRs with known bugs and benchmark 2–3 tools (one platform-native, one dedicated, one open-source).
2. Enable the best on one team's repositories in comment-only mode; write a short rules file.
3. Tune noise: exclude generated code, set severity thresholds, track accepted vs dismissed comments.
4. Harden: least-privilege tokens, no fork-PR secrets, DPA and region check, branch protection unchanged.
5. Review KPIs after 4–6 weeks, then roll out and extend to agent-generated PRs.

Sources

1. Anthropic — Claude Code Code Review — https://code.claude.com/docs/en/code-review
2. Anthropic — claude-code-action — https://github.com/anthropics/claude-code-action
3. Qodo — PR-Agent (open source) — https://github.com/qodo-ai/pr-agent
4. GitHub Docs — About Copilot code review — https://docs.github.com/en/copilot/concepts/code-review
5. CodeRabbit documentation — https://docs.coderabbit.ai
6. reviewdog — https://github.com/reviewdog/reviewdog
7. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
8. Regulation (EU) 2016/679 (GDPR) — https://eur-lex.europa.eu/eli/reg/2016/679/oj