Code review is the bottleneck

In the age of AI, writing code has become cheap. In the StackOverflow survey of 2025, 84% of developers are currently using or plan to use AI in their workflows. Among those currently using it, 51% of them already drive it daily.

Writing code faster is the usual productivity developer's associated with AI. However, it comes with a trade-off: code review. A separate survey carried out by Sonar revealed that AI accounts for 42% of committed code yet 38% of developers report that reviewing said code takes more effort than those written by human colleagues.

In other words, while writing code has become a lot easier, reviewing it is becoming more difficult. Code review has always been viewed as a difficult yet necessary task, but it's been made even more challenging because there's now more code to review than before.

Code Review: A difficult (but necessary) task

The consequence of a slow review process is ultimately a slow ship speed. The slower you ship, the slower your software can add features, address bugs, or deploy changes.

This is what happened to our engineering team at Anycase. As the team started utilizing AI tools to assist with code, we found it a lot easier to implement tasks. However, code review would slow down since there was so much more of it to go through. Some pull requests would wait a week to get to a first review.

Sometimes these changes were shallow (e.g. syntax fixes, nits) while some weren't (e.g. this doesn't align with the expected behavior), but each one costs the same to make since it took the time and attention of a senior engineer. What did we do?

Correctness comes in two layers

We held a couple of internal workshops to discuss the issue and one of the insights we arrived at was there were two types of correctness that have to be reviewed in a pull request: implementation correctness and product correctness.

The former is easy to identify and cheap to fix as implementation context is just in the code. These are details like:

• Was an error properly handled?
• Can this value be null?
• Is this conditional properly implemented?

The latter, product correctness, is more challenging because product context isn't necessarily in the codebase. It's scattered across Slack chats, Jira tickets, Google drive documents. Oftentimes it may not even be written down at all - it just lies in the head of an engineer. The only central place you can pull this context from is the engineer who owns that slice of the product.

Consequently, we want these engineers to focus on identifying product correctness concerns because they're the ones who understand how it's supposed to behave. We want them to spend less time worrying about implementation concerns because the answers to those can just be found in the codebase.

The two types of correctness: Implementation and product

With this insight, we introduced a two-pass review flow.

The two-pass review flow

The first pass is a review from a coding agent (we use Codex, but this works with any coding agent) that focuses on implementation correctness, where much of the evidence already exists in the code:

• Unsafe assumptions
• Error handling
• Missing validation
• Possible test gaps
• Implementation inconsistencies

The agent categorizes its findings into P0, P1, or P2 issues and comments them in the PR. The author of the PR then addresses these issues accordingly.

Once addressed, the author requests a second pass review from an engineer with product context. The engineer brings in context that aren't always found in the code:

• Product requirements
• History
• Architecture
• Known edge cases
• Business rules

The reviewer feeds this context to Codex and asks it to look for product correctness-related issues. Note that the second pass can still leverage an agent, but the reviewer guides it on what to look for. Once the agent generates its output, the reviewer can cross-reference it with the code to check if the comments are valid.

Once validated, these second-pass comments are put up for the author to address. If changes are requested, the author addresses them and repeats this review workflow until the changes are accepted.

As a result of this two-pass review, we were able to reduce the time it takes to review a PR to roughly 1 day.

Things to keep in mind

Context makes review faster

Formulate your PR description in such a way that it's easy for the reviewer to reconstruct the problem you're trying to address. Details like screenshots/recordings, instructions for them to test the changes themselves, and description of the task allow the reviewer to piece together the problem more quickly.

It's the author's responsibility for ensuring there is enough context present. A one-line description won't cut it.

Spend senior attention wisely

To reiterate, writing code is now a lot cheaper because of coding agents, so we tend to write more of it. Consequently, it will take senior engineers more time to sift through all of it.

Previously, they would have to review both implementation correctness and product correctness. However, with coding agents having access to the codebase, we can have them focus on the former type of correctness, allowing the senior engineers to focus solely on the latter.

AI can't invent product context

Coding agents have no sense of what product correctness looks like. To be able to provide this context to them, you must keep knowledge portable. What does this look like for a particular product?

First, someone has to own it. If nobody owns the product, then no one has an idea of how the product is supposed to behave correctly. Additionally, this responsibility shouldn't belong to a single person since they can become the bottleneck if code changes for that product occur frequently. Ideally, 2-3 people should share the responsibility so the review workload can be distributed among them.

Finally, document their product understanding. By explicitly documenting it somewhere, the knowledge is kept portable, allowing it to be shared with other members of the team who may be working on the feature or coding agents that are used to assist with the feature.