How AI Coding Assistants Changed the Way Teams Do Code Review

Code review practices at engineering teams have been evolving since teams started using pull requests as the primary mechanism for code change review. The emergence of AI coding assistants — GitHub Copilot, Cursor, Codeium, and others — and AI code review tools has introduced a new variable into how teams review code, who does what during review, and what human reviewers are expected to focus on when the first pass can be handled by a model.

The changes are observable in teams that have adopted these tools at any scale, and they’re more nuanced than the simple “AI reviews code now” framing suggests. What’s shifting is the distribution of review effort, the types of comments human reviewers make, and in some cases the relationship between author and reviewer — for better and for worse.

The Pre-Review Layer

The most direct impact of AI on code review is the pre-review automated check that has become standard at teams using tools like GitHub Copilot’s code review features, Sourcery, CodeRabbit, or similar. These run on a pull request before human reviewers see it, generating comments on style inconsistencies, potential bugs, obvious code quality issues, and security vulnerabilities that pattern-matching can catch reliably.

The practical effect is that routine, mechanical review comments — “this variable name isn’t consistent with the rest of the codebase,” “this function could be simplified to a list comprehension,” “this SQL query could be vulnerable to injection” — increasingly appear as automated comments before any human has looked at the PR. Human reviewers who see these automated comments can either verify them, dismiss them, or simply skip re-flagging what’s already been flagged.

The time savings on the reviewer side are real, particularly for reviewers who were spending meaningful time on style and convention enforcement. When an automated tool handles “your line is 103 characters, the project standard is 100,” the human reviewer can spend that attention on logic, architecture, and intent. In principle, this upgrades the quality of human review by shifting attention up the abstraction stack.

In practice, the effects are mixed. Teams report that automated pre-review catches legitimate issues that were sometimes missed in human review. But automated review tools also generate false positives — comments that are technically valid by the pattern matcher’s rules but contextually wrong, or suggestions that conflict with project-specific conventions the model doesn’t know about. Authors who receive automated review comments now have a two-tier review experience: responding to automated comments that may or may not require action, then addressing human reviewer comments. The overhead of triaging automated comments is real and not costless.

What Human Reviewers Are Actually Reviewing Now

The theory of AI-assisted code review is that automating the mechanical catches frees human reviewers to focus on higher-order concerns: design decisions, architectural consistency, business logic correctness, edge case coverage, and whether the change accomplishes what the PR description claims in a way that fits the broader codebase. Whether this theory holds in practice depends heavily on team culture and the reviewers involved.

Teams where reviewers had already developed a practice of focusing on design and logic during review find that AI pre-review fits naturally into their workflow — the tool handles the style pass they were mostly ignoring anyway, and they focus their attention where they already were. Teams where reviewers used style and convention feedback as the primary mode of review engagement find that AI pre-review reduces the review activity they were doing without necessarily upgrading them to higher-order review.

The code that AI generates (when authors are using AI coding assistants to write their code) presents specific review challenges. AI-generated code tends to be syntactically correct and style-conformant but may have subtle semantic issues: logic that looks right but handles edge cases incorrectly, abstractions that are more complex than necessary, or dependencies that could be avoided with simpler approaches. Reviewers who understand what they’re reviewing have observed that AI-generated code requires the same quality of attention as human-written code — sometimes more, because the author may have less deep understanding of what they committed.

This creates a tension: when the author used an AI assistant to write the code and an AI tool to pre-review it, and the human reviewer is reading code that was generated by one model and reviewed by another, the question of where actual human judgment was applied in the creation process matters for what kind of review the human reviewer should provide. Some teams have started asking authors to note when code was substantially AI-generated specifically to flag that the usual assumption of author understanding may not hold.

The Speed and Thoroughness Tradeoff

AI-assisted review workflows can meaningfully reduce review turnaround time for straightforward PRs. A PR with only automated review comments that have all been addressed, passing CI, and a clean diff is a much faster review than one requiring back-and-forth on style and convention. For teams with long PR review queues, this is a genuine productivity improvement that keeps delivery velocity higher.

The risk is that faster review becomes shallower review. When the pre-review tool has already caught the obvious issues and the diff is clean, there’s a cognitive pull toward approving quickly, particularly for reviewers with large review queues. The issues that AI pre-review misses are by definition the harder-to-catch issues — the ones where human judgment about business context, system architecture, and correctness in complex edge cases is most valuable. Fast review of a clean-looking AI-pre-reviewed PR is exactly the situation where those issues can slip through.

Team Culture Effects

Code review has always had social dimensions beyond technical quality assessment. Review is where engineers share knowledge with teammates, where junior engineers learn from senior engineers’ feedback, where team norms get reinforced, and where the implicit architecture of a codebase gets transmitted. When automated tools handle more of the review surface, these social functions are at risk of being reduced along with the mechanical ones.

Teams that have thought carefully about this have responded in various ways: maintaining expectations for human review depth on certain types of changes (architectural changes, new abstractions, complex business logic), pairing junior engineers with senior reviewers even on PRs with clean automated review passes, and creating explicit spaces for the discussion and knowledge transfer that can’t happen when all review comments are automated suggestions.

The engineering teams that have adapted most successfully to AI-assisted review are those that were thoughtful about code review culture before the tools existed. Teams that had vague expectations about what review was supposed to accomplish find that AI tools expose rather than resolve that vagueness. The question “what should a human reviewer focus on when the bot has already caught the style issues?” requires an answer that was probably worth having before the bots showed up.