Code Review in the AI Era: From Human Bottleneck to Layered Quality Gate

Code review used to be one of the slowest steps in software delivery. AI did not fix that. It made it both worse and more important at the same time.

Developers can now ask Copilot, Cursor, Claude Code, Codex, or an internal agent to implement a feature, refactor a module, generate tests, even open the pull request. The volume of code reaching the review queue has gone up. The signal of what was actually thought about before it landed there has gone down. Reviewers are looking at diffs that compile, pass tests, read fluently, and were partly written by a system the author may not fully understand. The familiar question - is this safe to merge? - has gotten harder to answer, not easier.

That is why AI does not remove code review. It forces a redesign.

The mistake most teams make is to look for that redesign in the tool catalog. They compare CodeRabbit and Claude Code Review, run a pilot of Codex on a few repos, install Sonar, debate Semgrep versus CodeQL, and ship the same review process they had a year ago - only now with three more bots leaving comments on every pull request. The bots are not the problem. The absence of an operating model behind them is.

The redesign is not one AI reviewer replacing one human reviewer. It is a layered quality gate where every kind of risk has the right reviewer - and where the layer that owns a review signal matters more than the tool that produced it.

The economics of code review changed before the tooling did

Most conversations about AI code review start at the wrong end. They start with which tool to buy. The harder question, the one with operational consequences, is different:

Which type of review should run on every pull request, which should run only on risky changes, and which should block the merge?

This matters because AI review is not free. It has a cost model, and the cost model is what makes "just install another reviewer" a quietly expensive mistake.

Some tools are priced per developer. CodeRabbit is typically positioned this way. That makes it natural to treat as an always-on PR reviewer for any engineer who regularly opens or reviews pull requests. The marginal cost of an extra review is near zero once the seat is paid.

Other tools create a per-review or token-based cost. Claude Code Review can be powerful for deep, contextual reading of a risky change, but running it on every trivial pull request stops being economically rational quickly. A single deep review on a large diff can cost meaningfully more than the engineer's hour it might save, and the cost compounds across hundreds of PRs a week.

Codex-style workflows - programmable reviewers built on top of an API - sit in a different bucket again. They are attractive when a team already has the API access and wants to own the prompt, the review logic, and the cost ceiling. The flexibility is real. So is the responsibility: nobody else is going to tune the prompt, manage false positives, or evaluate whether the reviews are actually useful.

Sonar, linters, tests, CodeQL, Semgrep, dependency scanners, secret scanners - these belong in a different category entirely. They are not optional AI assistants. They are deterministic quality gates. Their cost model is closer to "fixed overhead per repo," and what they buy is not a probabilistic opinion. It is enforcement of known rules.

That distinction is the one most review systems get wrong.

AI reviewers are good at expanding coverage - at noticing things humans miss because there are too many diffs to read carefully. Static tools are good at enforcing known rules. Humans are still required for judgment, ownership, and production accountability. Treating any of those three as substitutes for the other two is how teams end up with more review activity and less review quality.

The new code review stack is layered, not linear

The old code review process was roughly linear. Developer writes code. Developer opens a pull request. CI runs. Another developer reviews. The team merges. Five steps, mostly sequential, with one human checkpoint that carried most of the load.

The AI-era process should be layered instead. Four layers, each with a different question, a different cost profile, and a different relationship to the merge button.

The first AI code review should happen before the PR exists

The first layer is where teams should catch low-quality AI output before it reaches anyone else's review queue.

A developer should not generate code, skim it, and immediately open a pull request. Before the PR exists, the author should use AI to challenge the change. Not the same AI that wrote it - a separate pass, with a separate prompt, asking the change to defend itself.

The pre-PR review should answer:

• What changed?
• What can break?
• What tests are missing?
• What edge cases did the implementation ignore?
• Is the code more complex than necessary?
• Are there obvious security or data risks?

This can run inside the IDE, the CLI, or a local script - using whatever tool the developer already has. Claude Code, Codex, Cursor, CodeRabbit's IDE mode, Copilot, an internal agent. The choice of tool matters less than the discipline of running the pass.

This layer should be fast. It should not be a formal gate the team has to wait on. Its purpose is upstream: to reduce the volume of obviously-broken-but-it-compiles code entering the review queue in the first place. Without it, reviewers spend their attention on problems the author could have caught alone in two minutes. With it, the in-PR review starts from a higher floor.

The cost of skipping this layer is invisible until you measure it. In the engagement I'm currently in, the first signal that review capacity had collapsed was not the queue depth. It was the comment density per PR - reviewers were leaving more comments because authors were sending more half-thought-through diffs, and reviewers were not yet adapted to the new shape of the problem. Adding a pre-PR self-review step, before any in-PR bot was installed, was the single change that moved that signal the most.

AI in the PR should start conversations, not close them

The second layer is where AI reviewers earn their place. It is also where most teams misplace them.

Tools like CodeRabbit, Claude Code Review, Codex-based GitHub Actions, or custom review agents can inspect the diff, summarize the PR, identify missing tests, flag suspicious logic, and suggest improvements. A good AI reviewer can give a human reviewer a first-pass map of the change before they read a line of it:

• Which files changed
• Which behavior changed
• Which risk areas exist
• Which tests are missing
• Which code looks suspicious
• Which downstream things might break

That map is real value. A reviewer who already has it spends their attention on the parts of the change the map could not analyze - design choices, domain assumptions, the things humans see and machines do not.

But this layer should usually stay advisory. AI comments should start conversations. They should not automatically block the merge - unless the organization has deliberately taken a specific AI finding and converted it into a deterministic rule, which is a different kind of decision and belongs in the next layer.

This is the place where the "install another bot" instinct does the most damage. If every AI comment is treated as a merge blocker, the team gets review paralysis. If no AI comment is ever taken seriously, the team gets review theater. The middle path - advisory by default, escalation when a finding meets a clear threshold - is the operating model that holds up under volume.

Make AI comments hard to ignore without making them blocking

The advisory-vs-blocking distinction has a practical failure mode. If AI comments are purely advisory, nothing forces anyone to read them, and the team learns to merge without looking. If they are made strictly blocking, the team learns to dismiss them faster - usually with a // AI false positive style override that turns into a culture, not a one-off.

The middle ground is a soft-block. When an AI reviewer flags a comment at major severity (or whatever threshold the team has agreed on), the comment automatically goes into a pending state on the PR, and the PR cannot merge while any major comment is still pending. Resolution is the unblock - the author fixes the issue, marks it acknowledged with a one-line justification, or escalates it to a human reviewer. It is not the most efficient flow in isolation, and some of those interruptions will turn out to have been false alarms. What it buys is a forcing function: the team actually reads the comments at the threshold it agreed mattered, instead of triaging by which bot was loudest that morning. The most useful side effect is not the comments themselves - it is that the team's notion of what severity means starts to stabilize, because the soft-block makes the team negotiate the threshold explicitly instead of leaving the question implicit on every PR.

A second layer worth adding once the soft-block exists is prioritization. The most valuable AI comment is the one a human would have missed; the least valuable is the one the linter already caught. Configure the AI reviewer to surface the high-priority finding visibly (a top-of-PR summary, a labeled critical issue) and to demote what overlaps with deterministic checks. The point is not to make the AI quieter. It is to make the AI's loudest signal correlate with the highest review value. If a team's AI reviewer is loudest about style issues a linter already enforces, that is not a tool problem; that is a configuration problem.

Deterministic gates block merges; AI reviewers don't

The third layer is the one that should actually block the merge.

Linters, formatters, type checks, builds, unit tests, integration tests, coverage thresholds, secret scanning, dependency scanning, SAST, CodeQL, Semgrep, and Sonar belong here. None of these tools have opinions. They have rules, and they enforce them consistently.

This layer answers a fundamentally different question from AI review.

AI review asks: What might be wrong?

Deterministic gates ask: Did this violate a known rule?

The two questions look similar from a distance. Up close, they are not interchangeable. A probabilistic answer to a yes-or-no question is the wrong tool for the job. If a leaked secret should block a merge, the gate that detects it cannot be advisory. If a critical vulnerability ships through a maybe-flag, the maybe is the problem.

A failed build should block. A failing test should block. A leaked secret should block. A critical vulnerability should block. A major coverage drop should block. A violated quality gate should block. The list is not long, but it is firm. The firmness is the point.

This is where Sonar fits especially well. It is not another conversational reviewer leaving comments. It is a governance layer for code quality, maintainability, reliability, and security - a set of rules the team has agreed are non-negotiable, enforced consistently across every PR. With AI-generated code rising in volume, the case for this layer has gotten stronger, not weaker. AI-written code can read fluently and still violate the same rules teams already agreed they care about. Deterministic gates are the only layer of the stack that catches that reliably.

A subtler point: the more sophisticated the AI advisory layer gets, the more tempting it becomes to thin out the deterministic layer underneath it - to delete linter rules because "the AI would have flagged that anyway," or to relax coverage thresholds because "AI tests are good enough." Both are mistakes. The deterministic layer is the floor. The AI layer sits on top. Lowering the floor because the ceiling got higher is how teams lose the bottom of their quality envelope without noticing.

Humans still own architecture, security design, and production accountability

The fourth layer is the one that cannot be outsourced. It is also the one that gets most distorted when the layers below it are missing or poorly placed.

Humans still own architecture, business logic, domain correctness, maintainability, security-sensitive design, and production accountability. AI can help a reviewer think. It can point to risks. It can suggest questions. It can compare a change against project conventions or call out a deviation from established patterns. What it cannot do is be accountable for the decision to merge. Accountability is a property of a person who has to live with the consequences, and no tool currently in the market changes that.

Senior engineers, tech leads, security reviewers, and domain owners belong in this layer. So do the questions that lower layers cannot answer well:

• Is this the right design?
• Is the abstraction justified?
• Does this create long-term maintenance cost?
• Is the domain logic correct?
• Does the implementation match the business requirement?
• Is the security model still valid?
• Is the rollback path clear?
• Will this be observable in production?

Each of these is a judgment call. A linter cannot make it. A test cannot make it. An AI reviewer can sometimes surface a useful angle on it, but the call itself sits with a person.

The goal is not to remove humans from review. The goal is to stop wasting human attention on things the lower layers can handle better - formatting, obvious style issues, the kind of nitpick comment that a reviewer leaves because it is faster than not leaving it. When formatting goes to the linter, when test gaps go to the AI advisor, when secrets go to the scanner, what is left for humans is the part of review that actually requires being a human.

Map each tool to a layer, not to a competitor

The mistake hiding under most AI-code-review discussions is comparing every tool against every other tool, as if they all solve the same problem. They do not. The useful question is not "which is best." It is "which layer does this belong in, and what does it own there?"

CodeRabbit - always-on advisory in Layer 2

CodeRabbit fits well as an always-on AI PR reviewer in Layer 2.

Its value is predictable workflow integration. It can review pull requests, summarize changes, suggest improvements, detect code smells, flag missing tests, and reduce the basic review work a human has to do. Per-user pricing makes it economical to leave on for any engineer who is actively in pull requests on a normal week.

Best placement:

• Every normal PR
• Developer workflow assistance
• First-pass review map
• PR summaries
• Missing-test suggestions
• Code-smell detection

Weakness:

• Can create comment noise if not configured
• Should never be treated as final approval
• May miss deeper architectural or domain issues

One caveat worth naming on positioning. CodeRabbit's product surface has been expanding beyond AI advisory - into linters, static analysis, and quality-gate territory that has historically belonged to Sonar. Some teams now evaluate it as a Sonar replacement rather than a complement. Whether that consolidation works for any given team is an evaluation that has to be done on the specific repo, not a default recommendation. The point for this article is narrower: when CodeRabbit is doing AI advisory on a PR, it lives in Layer 2; when it is doing deterministic linting or quality enforcement, it lives in Layer 3. The vendor is one. The layer is two. Mapping by tool name instead of by what the tool is actually doing on this PR is exactly the failure mode the layered model exists to prevent.

Claude Code Review - selective depth in Layer 2

Claude Code Review fits as a deeper, contextual reviewer. Use it selectively, not by default.

It is useful when the question is not "is this code clean" but "what can this change break?" Claude can reason across a broader window of context, inspect risky changes, identify edge cases, and help with security-oriented review. The depth is real.

So is the cost. A single deep review on a large diff can be expensive enough that running it on every small copy change or simple refactor stops making sense quickly. Used on the right PRs (high-risk, large, security-sensitive), the value is clear. Used on every PR, it scales cost without scaling quality.

Best placement:

• High-risk PRs
• Large diffs
• Security-sensitive changes
• Complex refactors
• Auth, payments, permissions, PII, infrastructure, data migrations
• Second-pass review when CodeRabbit or human reviewers flag uncertainty

Weakness:

• Cost scales with PR size and context window
• Not deterministic
• Still requires human judgment
• Should not become an automatic blocking gate on its own

Claude Security Review - Layer 2 specialist for security-sensitive change

Claude Security Review deserves separate treatment. Security review is not the same as general code review. A normal reviewer may check readability, tests, and maintainability. A security review asks a different set of questions:

• Can this be exploited?
• Does this change trust boundaries?
• Are secrets exposed?
• Is input validation sufficient?
• Can permissions be bypassed?
• Does the change create injection, authentication, session, or data-leakage risk?
• Does any AI agent, hook, or MCP integration introduce a new attack surface?

Claude Security Review fits between static security scanning and human security review. It can catch contextual vulnerabilities that simple rules miss - the kind of issue where the code is structurally fine but interacts with the rest of the system in a way that creates a problem.

It should not replace SAST, dependency scanning, CodeQL, Semgrep, Sonar, secret scanning, or human approval for sensitive areas. Security gates stay strict. AI can assist security review. It should not own it.

There is a category of risk here worth naming directly, because it changed the threat model rather than just the volume. AI-generated code introduces failure modes that did not meaningfully exist before: prompt-injection payloads embedded in code or comments that a downstream agent will execute; backdoors that a coding agent inserted because a compromised upstream tool nudged it to; MCP integrations that quietly expand the privileges a future agent inherits; data-exfiltration paths through tool-use that look like ordinary side effects in a diff. Some of these a careful human reviewer catches. Many they do not - not because the reviewer was sloppy, but because the failure modes are unfamiliar and the code looks normal. Deterministic security scanning does not catch most of them either, because the patterns are too new and too contextual for the rules to have been written yet. Contextual AI security review is one of the few layers positioned to surface them at all. That is the part of the case for it that does not get made enough: for some categories of AI-introduced risk, AI code review is not one option among several. It is the only review layer that can catch the problem before it lands in production.

Codex / Codex Action - programmable Layer 2

Codex-style review is useful when a team wants a programmable reviewer rather than a fixed SaaS workflow.

A Codex-based GitHub Action or CI workflow can be configured to check project-specific rules, generate PR summaries, review diffs, comment on missing tests, or enforce internal conventions that no off-the-shelf tool will know about.

Its biggest strength is flexibility. Its biggest cost is governance: the team owns prompt quality, cost control, false-positive management, and the ongoing question of whether the reviews are actually useful. Codex is not "free review automation." It is a programmable review layer that requires the same discipline as any other internal tool.

Best placement:

• Custom GitHub Actions
• CI-based review experiments
• Internal review policies that don't fit a SaaS tool
• Project-specific checklist automation
• Teams that want to own their review prompts and workflow

One pattern worth flagging here because it works in practice and the discussion around it has lagged the reality. The AI review itself does not have to be a single agent reading the whole diff. On larger PRs, the cleanest version is multiple subagents reviewing in parallel - each scoped to part of the change. One per module on a backend-only PR. One for the backend slice and one for the frontend slice when the PR spans both. A single-subagent review of a 40-file diff that touches three modules tends to lose context partway through; a per-module split keeps each subagent's window tight and the findings sharper. The trade-offs are real: subagents do not save as much context as it looks like they should, the orchestration has to be tuned, the false-positive rate per subagent has to be calibrated independently, and the results need a coordination layer to merge sensibly. But for diffs above a threshold the team will recognize when they see it, multi-subagent review is meaningfully faster and meaningfully better than one agent reading the whole thing. Codex-style flows are where this pattern is easiest to build - owning the prompt and the orchestration is what makes it work, and that is exactly what a programmable review layer is for.

Sonar - the centerpiece of Layer 3

Sonar belongs in the deterministic quality gate layer. Its job is not to act like a conversational reviewer. Its job is to enforce quality and security rules consistently, regardless of who or what wrote the code.

Sonar is especially valuable in the AI era because AI-generated code can look plausible while still introducing maintainability, reliability, or security issues. Plausibility is exactly what fools a human skim. Plausibility does not fool a rule.

Best placement:

• Mandatory PR quality gate
• Code smells
• Bugs
• Vulnerabilities
• Coverage rules
• Maintainability checks
• AI-generated code assurance
• Technical-debt control

Weakness:

• Does not understand all business logic
• Can miss architectural concerns
• Generates findings that require prioritization
• Should be tuned so the team is not blocked on low-value noise

Linters, tests, CodeQL, Semgrep, secret scanners - the floor of Layer 3

These are not glamorous, but they are the floor under everything else.

Before adding an AI reviewer, the team should already have formatting, linting, type checks, unit tests, integration tests, build checks, secret scanning, dependency scanning, static security analysis, coverage thresholds, and code-ownership rules. AI review without these basics is weak governance. It may look modern. It is fragile.

If a team is debating which AI reviewer to install while its main branch can still merge code with leaked secrets, the AI reviewer is not the next move. The deterministic floor is.

Block on objective gates, escalate on AI findings, decide with human judgment

Not every review signal should block a merge. This is where many teams get it wrong. They install an AI reviewer, let it comment on everything, and then nobody knows which comments matter. Without explicit separation between advisory and blocking, the reviewer's authority degrades within a few sprints - the same failure pattern the closing section returns to.

A mature review system separates advisory signals from blocking gates explicitly. Here is one way to draw the line:

The principle behind the table is shorter than the table:

Block on objective gates. Escalate on AI findings. Decide with human judgment.

That sentence is the operating model. Everything else - which tool, which layer, which policy - is implementation.

Route review work by risk tier, not by team norm

A strong review process should not treat every pull request equally. A copy change and an authentication refactor should not have the same review path. The volume of trivial diffs an AI-assisted team produces is exactly what makes uniform review routing collapse - every PR getting the same heavyweight treatment guarantees the heavyweight treatment loses its meaning fast.

The cleanest pattern is to route by risk tier.

Low-risk pull requests

Examples: copy changes, small UI tweaks, simple refactors, internal non-critical changes, low-risk configuration updates.

Recommended review stack:

• Linter
• Tests
• Build
• Secret scan
• Sonar or static quality gate
• Lightweight AI PR review
• One human approval

Expensive deep AI review is usually unnecessary here. The cost-per-PR has to make sense against the actual risk per PR.

Medium-risk pull requests

Examples: business logic changes, API behavior changes, database query changes, integration updates, moderate refactors, user-facing workflow changes.

Recommended review stack:

• Full CI
• Linter and type checks
• Unit and integration tests
• Sonar quality gate
• CodeRabbit or equivalent AI PR review
• AI-generated risk summary
• Human approval
• Optional Claude or Codex deep review when the diff is large or unclear

High-risk pull requests

Examples: authentication, authorization, payments, permissions, PII, infrastructure, data migrations, public APIs, production AI behavior, security-sensitive integrations, agent hooks, MCP tool integrations.

Recommended review stack:

• Full CI
• Full test suite
• Coverage gate
• Secret scan
• Dependency scan
• SAST
• Sonar quality gate
• CodeQL or Semgrep
• Claude Security Review or equivalent deep AI security review
• Senior human approval
• Security approval where needed
• Release checklist
• Rollback plan
• Observability check

This is where paying for deep AI review starts to make obvious sense. A deep review that looks expensive against a trivial PR looks cheap against a production incident, a security bug, a data leak, or a broken migration. The arithmetic only works the right way once.

Not every review needs to run inside the PR pipeline

A piece of the review system most teams under-use, especially once AI review is in the mix, is the part that runs outside the pull request entirely.

Some review work belongs on the PR. It needs to happen before merge, on the specific diff, with the result reaching the reviewer fast. Other review work does not. Heavyweight scans that take longer than the team is willing to wait at the merge gate, recurring sweeps over the codebase as a whole rather than the diff in front of you, dependency hygiene that depends on the rest of the world changing rather than this PR changing - none of these belong inside the per-PR critical path. Forcing them there turns every merge into a hostage of work that did not need to block this merge.

Two patterns work well here.

The first is scheduled scans. A nightly job, a weekly job, or even a monthly job that runs the expensive review work the PR pipeline cannot afford. OWASP Dependency Check sweeping every library and its transitive vulnerabilities once a week, then opening a PR with the fixes when something matches, is the canonical version of this pattern. Deep CodeQL queries scanning the whole repo overnight instead of per-PR are the same shape. SBOM diffs against upstream advisories on a cadence are the same shape. The work happens. It just does not block a 10-minute merge.

The second is moving AI review off the PR's worker pool. AI code review takes longer than most other CI steps - sometimes much longer on a large diff with a deep reviewer - and if it runs on the same workers as the build, the review queue and the build queue starve each other. The practical fix is a separate, smaller worker pool for AI review agents. The build pipeline finishes when the build finishes; the AI review comment arrives a few minutes later. Reviewers are fine with that, because human review has always worked this way - nobody expects a senior engineer's comment to land within thirty seconds of git push. Treating AI review as needing PR-pipeline latency when it does not is what makes review queues collapse under volume.

The diagnostic question is short. Does this review signal need to block the merge? If yes, it belongs inside the PR pipeline and on a fast worker. If no, it can move - to a scheduled job, to a background pipeline, to a separate pool - and the team gets the review coverage without paying the build-latency tax.

The pull request template is where the new review process becomes real

Process changes that live only in policy documents do not change behavior. The pull request template is where the new review process touches every diff. Most teams' PR templates are still optimized for the pre-AI world - a short description box and a couple of checkboxes - and the friction of changing it is small enough that it is one of the highest-leverage things a team can do in week one of redesigning review.

A good AI-era PR template should include:

1. What changed? A short human-readable summary.

2. Why did it change? The business or technical reason.

3. What can break? The risk areas.

4. What tests prove it works? Unit tests, integration tests, manual checks, screenshots, or test evidence.

5. Did AI assist this change? Not for blame. For review calibration - a reviewer reads an AI-assisted diff with different questions in mind than a hand-written one.

6. What did AI review find? Summary of relevant AI findings, not every comment. The author's job is to filter and surface; the reviewer's job is to act on the surfaced subset.

7. What needs human judgment? Architecture, domain logic, security, migration, permissions, or release risk. This is the field that routes the PR to the right layer-4 reviewer.

That last field is the most under-used. It is also the most useful. It turns code review from passive inspection - a reviewer looking at a diff and waiting to notice things - into structured verification, where the author has already named the parts that need human judgment and the reviewer can start there.

A quality gate model that survives volume

A practical AI-era quality gate could look like this. It is not the only shape that works, but it is a defensible starting point a team can adapt.

Mandatory for every PR

• Build passes
• Tests pass
• Linter passes
• Type checks pass
• Secret scan passes
• No critical dependency vulnerabilities
• Sonar quality gate passes
• Required human approval is present
• PR template is completed

Additional for medium-risk PRs

• AI PR review completed
• Risk summary included
• Test coverage checked
• Relevant code-owner approval
• Integration impact considered

Additional for high-risk PRs

• Deep AI review completed
• Security review completed
• Senior engineer approval
• Code-owner approval
• Rollback plan documented
• Observability impact checked
• Feature flag or controlled rollout considered
• Migration plan reviewed, if applicable

The real value of AI in this model is not more comments. It is better routing of attention - to the layer that owns the question, at the risk tier that justifies the cost.

Installing a bot is not a review-system redesign

The worst version of AI code review is simple to install and easy to declare done: drop a bot into the repo, let it comment on every pull request, and announce that review has been modernized.

What usually follows is noise. Developers start ignoring comments. Reviewers become unsure which findings matter. AI comments repeat what the linter already knows. The team gets more review activity without better review quality - the authority-degradation pattern named earlier, now showing up on the calendar.

The better approach is older than AI. Decide what each layer owns.

• Linters own style.
• Tests own expected behavior.
• Static analysis owns known quality and security rules.
• AI reviewers own first-pass reasoning, edge cases, missing tests, and risk expansion.
• Humans own architecture, domain correctness, security-sensitive judgment, and final approval.
• Release gates own production safety.

The question stopped being whether AI can review code. The question is whether the review system knows what to do with AI feedback once it arrives.

Practical tool comparison - by role, not by ranking

The table below maps tools to layers and roles, not to a leaderboard. The same tool placed in the wrong layer produces worse outcomes than not using it at all.

The best teams won't have the most AI reviewers - they'll have the clearest review system

AI-assisted development changed the volume, the speed, and the authorship of code reaching the review queue. The right response is not to trust AI more. The right response is to design a stronger review system around that volume.

The shape of that system, on a good week, has three layers of compute and one layer of human attention, each sized to its risk: cheap deterministic checks on every PR, predictable AI advisory broadly across them, deep AI review selectively on the risky few, and senior reviewers concentrated where architecture, security, and production accountability actually live. The earlier section's operating-model summary still holds - block on objective gates, escalate on AI findings, decide with human judgment - and is the rule the layered shape exists to make operable.

AI code review is not a replacement for engineering discipline. It is the moment to rebuild code review around the three things that always mattered - risk, cost, and accountability - and to put each review signal in the layer that can actually answer it.

If your branch-protection rules still treat every signal the same way, that is the place to look first. If your PR template still asks for a short description and nothing else, that is the next place. If your highest-paid engineer is still reviewing typo fixes on Monday morning, the review system already told you what it needs from you - you just have not redesigned around it yet.

The teams that will hold up under AI-assisted volume are not the ones with the most reviewers in their CI. They are the ones whose review system knows exactly where AI helps, where automation blocks, and where a human still has to own the decision.

Frequently Asked Questions