The code review process most engineering teams use was designed for a specific kind of input: human-authored code, written one function at a time, usually by someone who understood what they were building and why.

AI-assisted development doesn’t produce that kind of input. It produces larger diffs, faster. It produces code that is syntactically correct and logically plausible without necessarily being understood by the person who committed it. It produces patterns that pass automated checks and look reasonable in a diff view, while quietly introducing churn, duplication, and technical debt that won’t surface for weeks.

The review process hasn’t changed to account for any of this.

What a standard code review is optimised for

A conventional code review asks, implicitly: does this code do what the author says it does, and does it follow the team’s standards? The reviewer reads the diff, runs it mentally against what they know about the codebase, and either approves or requests changes.

That works reasonably well when the author and reviewer share context — when the author wrote the code intentionally, understands its relationship to the surrounding codebase, and can defend their decisions in review comments.

AI-assisted code complicates each of those assumptions. The author may have accepted a suggestion without fully evaluating it. The diff may be larger than usual, making thorough review harder. The code may be locally correct but globally problematic — fitting the immediate requirement while introducing patterns that will cause trouble later.

The patterns reviewers should be looking for now

The signals that indicate AI-assisted code quality problems are different from the signals that indicate human-authored code quality problems.

Human code quality problems tend to be: logic errors, poor naming, insufficient test coverage, missing edge cases. These show up fairly directly in review.

AI-assisted code quality problems tend to be more structural: elevated churn (code that gets rewritten shortly after being written), duplicate logic across the codebase, large additions accompanied by large deletions in subsequent commits, and low net lines — lots of activity that doesn’t accumulate into net new capability.

These patterns don’t show up in a single diff. They show up across commit history. A reviewer looking at one commit in isolation can’t see them.

What this means for how teams should structure review

A few things change once you accept that AI-assisted code needs a different review frame.

The diff is not the whole picture. For AI-assisted commits especially, it’s worth asking what happened in the commits before and after. Elevated churn often looks fine at the point of creation and only reveals itself later.

Context should be stated explicitly. If a developer is using AI assistance for a particular piece of work, the review conversation changes. The reviewer’s job shifts from “does this look right to me” to “does this look right given what the AI was being asked to do and what the developer was trying to achieve.”

Reviewers need aggregate data, not just individual diffs. Knowing that a particular developer’s AI-assisted commits churn at twice the rate of their human-authored commits is useful information in a review. Without measurement, reviewers don’t have it.

The gap between what review currently does and what it needs to do

Code review in most teams is still optimised for a world where AI assistance was the exception. The process works for what it was designed for. The problem is that the inputs have changed faster than the process has.

That’s not a criticism of engineering managers or reviewers. It’s a structural lag that’s happening across the industry. Most teams haven’t made the review process visible enough to know where it’s falling short.

The starting point is data: understanding which commits are AI-assisted, what their churn rates look like compared to human-authored code, and whether the patterns you’re seeing in review are representative of what’s actually landing in the codebase.

Review processes that don’t have that visibility are making quality decisions with partial information. Some teams will get lucky. Most won’t know either way.

Scryable reads your git history to surface churn rates, duplicate code patterns, and before/after comparisons for AI-assisted commits. Get early access.