Code Review in the AI Era: Practices, Anti-Patterns, and Trade-offs

2026-08-18 · 12 min read · Tools & Productivity

Something has shifted in the rhythm of engineering teams over the last two years. PRs are bigger, they arrive faster, and they're often written by developers who didn't type most of the code themselves. The AI didn't just change how people write code — it changed the economics of code review in ways most teams haven't fully reckoned with.

The old model: a senior engineer spends 20 minutes reviewing a PR that took someone two days to write. The new model: an engineer spends 20 minutes reviewing a PR that took someone two hours, but the PR is twice as large. The review budget hasn't kept up. The result, in most teams, is some combination of rushed approvals, review fatigue, and a slow erosion of collective code ownership.

This isn't an argument against AI coding tools. It's an argument for being deliberate about what code review is actually for — and what changes when AI is in the picture.

What Code Review Is Actually For

Before getting into what changes with AI, it's worth being clear on why code review exists in the first place. Most teams say "catching bugs" but that undersells it.

Finding defects. Yes — catching logic errors, edge cases, security issues, performance problems before they reach production.

Spreading knowledge. The author knows the code. The reviewer learns it. Over time, this creates the distributed understanding that makes teams resilient when people leave or rotate.

Maintaining architecture coherence. Individual PRs that each make sense locally can accumulate into a codebase that doesn't cohere. Review is one of the mechanisms that keeps the whole consistent with the parts.

Establishing and enforcing standards. Code style, naming conventions, test patterns, error handling — review is where the team's norms get transmitted and enforced.

Slowing down enough to think. The act of explaining your change to a reviewer often surfaces problems the author missed. "Rubber duck debugging" but with a real duck.

Mentoring and development. Junior engineers get better through review. The feedback they receive on PRs teaches them to write code that communicates intent, anticipates failure, and fits the system.

When AI enters the picture, some of these purposes get easier. Others get harder. And some new failure modes appear that didn't exist before.

What Changes With AI

PRs arrive faster and get bigger

When generating code with an AI assistant is trivially fast, engineers produce more of it. This is mostly good — more shipping, less boilerplate — but it shifts the review load. A team that used to manage a steady flow of medium-sized PRs now manages a higher volume of larger ones.

The instinct is often to approve faster to keep up. Resist this. The right response is to adjust PR sizing expectations (more on this below), not to approve code you haven't properly read.

AI-generated code looks clean but hides different failure modes

AI produces syntactically clean code. It follows style conventions, uses sensible names, and often has a surface-level coherence that makes it look reviewed even when it hasn't been. This is the most dangerous thing about reviewing AI-generated code: the normal visual signals that tell you "this code is probably wrong" are missing.

Human-written code that's subtly wrong tends to look subtly wrong — naming is imprecise, the logic is convoluted, the structure is odd. AI-written code that's subtly wrong looks fine. The bug is in the semantics, not the syntax.

The failures that AI models make are also different in character:

The knowledge transfer function breaks down

When an engineer writes code from scratch, they understand it. When a reviewer reads and engages with it, they learn it. This is how teams build shared mental models of how systems work.

When an engineer uses an AI to generate a solution they don't fully understand, the author-reviewer model breaks. The author is reviewing the AI's output, not explaining their own reasoning. The reviewer is reading code that the author can't defend. Review becomes a superficial pass over a black box.

The fix isn't to ban AI assistance. It's to require authors to be able to explain the code they're submitting — regardless of who wrote it. If you can't walk through the logic and defend the choices, it shouldn't be in a PR.

Automated tools now handle what reviewers used to catch

On the positive side: linting, formatting, type-checking, basic security scanning, dependency vulnerability detection — most of this is automated now. Reviewers who spent time catching trailing whitespace and inconsistent naming now have that time back.

The implication is that human review time should shift up the stack. The machine handles style. The human handles intent, architecture, and domain correctness. If your reviewers are still leaving comments about formatting, something in your tooling pipeline is broken.

Good Practices in the AI Era

Require authors to explain intent, not just code

A PR description that says "added user auth via Copilot" is not a PR description. Authors should be able to explain:

This doesn't need to be a novel. But it should demonstrate that the author understood what they were asking the AI to do and has verified that the output is correct. If they can't write this description, the PR isn't ready.

Keep PRs small enough to review properly

AI makes it easy to generate large changesets quickly. This doesn't mean you should review them as single PRs.

The research on code review effectiveness is consistent: review quality drops sharply after about 200–300 lines of changed code. Reviewers lose focus, miss defects, and start approving patterns rather than logic. The right answer is to enforce PR size limits, not to accept that large PRs will be reviewed superficially.

For AI-generated code especially, smaller PRs with clear single purposes are essential. A PR that does "switch auth library, update all callsites, and add new user fields" is three PRs written as one.

Prioritise domain logic and system integration over syntax

Given that automated tools now handle the surface layer, reviewers should spend their attention on:

Domain correctness — is the logic actually right for the business problem? AI is good at implementing patterns; it has no idea if the business rule is correct.

System integration — does this code interact correctly with the rest of the system? How does it behave under load, at the boundaries, with unexpected inputs?

Failure modes — what happens when this goes wrong? Is the error handling appropriate? Will failures be observable?

Security surface — every user-facing input is a boundary. Every new dependency is an attack surface. Every new permission grant is a risk.

Data consistency — database transactions, race conditions, cache invalidation. AI models are particularly bad at reasoning about concurrent state.

Use AI as a reviewer too — carefully

AI coding assistants are decent at reviewing AI-generated code. They can spot obvious bugs, suggest edge cases, identify missing error handling. Some teams run automated AI review passes before the PR reaches human reviewers.

This is a reasonable layer to add, with caveats:

The right place for AI review is triage and first-pass filtering, not final sign-off.

Slow down on security and performance

Two categories of change should always get more careful human review regardless of AI involvement:

Security-critical code: authentication, authorisation, session management, input handling, cryptography, secret management. AI gets these wrong in plausible-looking ways. Require a dedicated reviewer with security expertise for any change touching these areas.

Performance-critical paths: database queries, cache interactions, hot loops, API rate-limit logic. AI optimises for correctness and readability; it often generates patterns that look fine but degrade at scale.

Separate what you're reviewing

A good review practice in any context, but especially with AI-generated code: make explicit which things you are and aren't reviewing.

A review comment of "LGTM" is meaningless. A review comment of "Logic looks correct to me, I haven't tested the edge cases with null fields" is honest and useful. It tells the next reader where human attention was spent and where it wasn't.

Some teams use structured review checklists that force reviewers to explicitly verify specific categories (security, error handling, test coverage, performance). These work well when they're lightweight and the categories are meaningful — they work badly when they become bureaucratic checkbox theatre.

Anti-Patterns

Rubber-stamping because "the AI wrote it"

This is the most common failure mode. A reviewer sees clean, syntactically correct code, knows it came from Copilot or Claude, and approves it with the implicit assumption that "AI wouldn't write something completely wrong."

AI absolutely writes things that are completely wrong. The fact that it looks right is not evidence that it is right. Every line of code in a PR needs the same scrutiny regardless of who or what generated it.

Reviewing the AI's comments instead of the code

Many AI tools generate inline comments explaining the code as it's written. Reviewers sometimes read these comments, nod, and approve — without actually reading the code. The comment says "this function validates the user's email format" so the reviewer assumes the function validates the user's email format correctly. This assumption is frequently wrong.

The comments describe intent. The code is what runs. Review the code.

Approving to clear the queue

Code review queues get long. The social pressure to clear a queue — especially when you're blocking another engineer's work — is real. This pressure was already a problem before AI; it's worse now because AI increases the rate at which PRs arrive.

The answer is not to approve faster. The answer is to either:

  1. Fix the team's PR process so review load is distributed properly
  2. Be explicit about what you did and didn't review (see above)
  3. Build better tooling and automation so human review time is spent on the things only humans can assess

Approving code you haven't reviewed is not a kindness to the author. It's a debt you're burying in the codebase.

Large PRs as the new normal

AI makes it easy to generate large changesets. Teams that don't actively push back on this end up with PRs that no one can properly review, that are too large to revert safely, and that accumulate hidden coupling across the codebase.

If your average PR size has grown significantly since your team started using AI tools, and your review quality hasn't degraded, you're probably in the minority. Most teams should enforce smaller PRs more aggressively than they did before.

Using review as a quality gate rather than a quality practice

Review that happens only when a PR is "done" and needs to be merged is review as gate. Review that's integrated into development — early feedback on approach, drafts and work-in-progress PRs, pairing on complex pieces — is review as practice.

Gates are necessary but not sufficient. A reviewer looking at 400 lines of finished code has limited ability to change it. A conversation about approach before the code is written costs nothing and can prevent a week of rework.

With AI-generated code especially, early alignment on approach matters more, not less. AI can implement any approach very quickly — but "very quickly implemented the wrong thing" is still a loss.

Treating review comments as optional

If review comments don't result in changes or explicit discussions about why the change wasn't made, review isn't working. The author can disagree with a reviewer — but the disagreement should be explicit, reasoned, and visible. "Resolved" on a comment that was closed without action is a red flag.

For AI-generated code where the author may not fully own the reasoning, this is especially important. The review conversation is where understanding gets established. Closing it without engagement means no one understood the code.

Trade-offs Every Team Has to Make

Speed vs. depth

Every team lives somewhere on this spectrum and the right point depends on context. A startup in early product-market fit should probably review faster and accept more risk; a regulated fintech can't. What AI changes is that the speed pressure increases everywhere, which means teams have to be explicit about where they're drawing the line rather than letting it drift.

The rule of thumb: the slower your feedback loop from production bugs, the slower your review should be. If you can deploy, observe, and roll back in 20 minutes, you can take more review risk. If a production incident costs a week of engineering time to diagnose, your review standard should be higher.

Automation vs. human judgment

There's a strong case for moving as much of code review as possible to automation: linting, type checking, test coverage thresholds, security scanning, dependency audits. Everything automated leaves human reviewers free to focus on judgment-layer problems.

The risk is that automation creates false confidence. A PR that passes all automated checks has been verified against the rules encoded in those checks — not against correctness in general. Teams that treat "all checks pass" as a substitute for review will miss everything that isn't encoded in a rule.

The right model: automate everything that can be automated without judgment, and use the time saved to do deeper human review on the things that require judgment. Not: automate a lot of things and review less.

Individual vs. collective ownership

Strong code review culture tends toward collective ownership — multiple people understand most parts of the codebase, and PRs are how knowledge spreads. Weak code review culture tends toward silos — experts approve their own areas, others approve quickly, knowledge is concentrated.

AI accelerates silo formation. When code is generated rather than written from understanding, there's less inherent knowledge transfer. If the author doesn't deeply understand their own PR, and the reviewer gives it a quick pass, the code lands with no human having actually understood it.

This is a slow-moving catastrophe. It shows up months later as "no one knows how this works" on a system that's become critical. The counter is deliberate investment in review as a knowledge-sharing practice — which takes more time and produces less short-term throughput, but pays back compoundedly in system resilience.

Coverage vs. cadence

Should every PR have deep review, or should review be more selective — deep on high-risk changes, lighter on low-risk ones? Risk-stratified review is a reasonable answer for many teams. The danger is that "low risk" categories expand over time as teams optimize for throughput, and what was light review becomes no real review at all.

If you're going to risk-stratify, make the categories explicit and revisit them regularly. "Low risk" should mean "has high test coverage, touches no critical paths, author has strong track record, scope is narrow" — not just "this looks fine."

What Good Looks Like

A high-functioning team in the AI era:

None of this is compatible with treat review as a blocking queue to clear as fast as possible. It's only compatible with treating review as an investment in collective understanding and systemic correctness.

The teams that get this right will have a meaningful quality advantage over teams that let review degrade into a formality. That advantage will compound — better review means fewer production incidents, less time debugging unclear code, faster onboarding, better architecture over time. The teams that don't will ship faster in the short term and slower in the medium term, with a codebase that increasingly nobody understands.

AI didn't create this trade-off. It just made it more urgent.

Track engineering health, PR cycle time, and GitHub activity alongside your team development work in one place. Try Emtricks free for 30 days — no credit card required.