Code review is not a checkpoint. It is how the team keeps up.

There is a small engineering habit I like more than most "Agile best practices": read yesterday's merged pull requests.

Not as surveillance. Not to count output. Read them to answer one question: what changed in the system while I was doing my own work?

That question is becoming more important. AI coding assistants make it easier to produce code. They do not make it equally easy for a team to understand, review, operate, and safely change that code later. If the bottleneck moves from typing to understanding, then code review stops being a technical side process. It becomes delivery management.

The evidence points in that direction.

Vella and Blincoe's 2026 longitudinal study of professional software engineers using AI coding assistants found that developers perceived less time spent on writing code and more emphasis on verification work. The authors call the new work category "supervisory engineering work": directing AI, evaluating output, and correcting errors. In their matched cohort, perceived productivity gains stayed high, while worsened developer-experience dimensions rose from 14% to 27%, especially around flow state and cognitive load.

That is not proof that AI makes teams slower. It is a warning that work is being redistributed. If leaders keep measuring only generated code, commits, or ticket movement, they will miss where the work went.

Code review is one of the places where it lands.

The older code-review literature is useful here because it does not treat review as only a bug filter. Bacchelli and Bird's 2013 study at Microsoft found that defect finding was a major expected reason for review, but not the whole story. Review also supported knowledge transfer, team awareness, and alternative solution discovery.

Google's 2018 case study makes the same point in a different setting. Sadowski and colleagues studied code review through 12 interviews, 44 survey responses, and logs from 9 million reviewed changes. At Google, review was lightweight: small changes, fast feedback, reviewer recommendation, ownership rules, readability expectations, and automated analysis visible inside the review tool. The median overall review-process latency was under four hours, and the median change size was 24 lines. Developers spent a median of 2.6 hours per week reviewing, and all survey respondents agreed code review was valuable.

Do not copy the benchmark. Most companies are not Google. Copy the mechanism.

Review worked because it moved information through the system. It taught. It reinforced local norms. It exposed context. It helped people notice changes outside their own task. Dorner and colleagues' 2025 paper on information diffusion in code review is careful about this: code review can be modeled as an information-exchange network, but actual knowledge transfer is hard to measure. That caveat matters. A clicked approval is not the same as understanding.

This is where many delivery systems go wrong.

They treat code review as a queue with a service-level target. "PRs must be reviewed within 24 hours." Fine. Waiting matters. Long review queues are WIP, and WIP slows delivery. But speed alone is a weak goal. A fast rubber stamp can preserve the metric while damaging the system.

The stronger question is: who needs to understand this change before we merge it?

That question changes the review design. It makes reviewer choice explicit. Sometimes the reviewer should be the code owner. Sometimes it should be the person who recently touched the affected area. Sometimes it should be a learner who needs exposure, paired with someone who can catch risk. Sometimes the review should not happen in a PR at all because the design question should have been handled earlier.

It also changes the author behavior. A useful pull request is not just a diff. It carries context:

• why this change exists
• what risk it introduces or removes
• how it was tested
• what the reviewer should focus on
• what follow-up is known but intentionally out of scope

If AI helped write the code, that context becomes even more important. AI can generate a plausible diff without sharing the reasoning that a teammate needs to maintain it. The author still owns that reasoning. "The tool wrote it" is not a review strategy.

For a Delivery Manager or Agile Coach, the practical diagnostic is simple. Take the last 20 merged items and inspect the flow:

How large were the changes? How long did they wait for first review? Who reviewed them, and why that person? Did the PR explain the business or technical context? Did review comments surface design, test, readability, or ownership issues? Were any changes reopened, reverted, or followed by incident work? Who else learned something from the change?

You do not need a maturity model for this. You need a whiteboard, the team's actual pull requests, and enough honesty to separate approval from understanding.

This also helps with the common complaint that teams are "doing tickets" instead of engineering. Ticket farming is often a symptom of broken feedback loops. People optimize for starting work, moving artifacts, and closing items because the system rewards visible motion. A healthy review loop rewards finishing in a different sense: the change is small enough to inspect, the context is clear enough to challenge, and the knowledge has reached the people who will live with the code.

One small routine can help: a daily or twice-weekly merged-change scan. Ten minutes. Not a meeting to report status. Look at what merged since the last scan. Notice risky areas, duplicated work, surprising dependencies, missing tests, and decisions that should be shared. This is not a replacement for review. It is a second loop for team awareness.

The point is not to add more process. The point is to stop pretending that code is done when a ticket is moved and a PR is approved.

In AI-assisted delivery, writing code may become cheaper. Understanding the system will not become optional. The teams that notice this early will manage review as a learning and flow-control system. The teams that miss it will get faster at creating work they do not fully understand.

Sources

• Bacchelli, A., & Bird, C. (2013). Expectations, outcomes, and challenges of modern code review. In Proceedings of the 35th International Conference on Software Engineering (ICSE '13) (pp. 712–721). IEEE. doi.org/10.1109/ICSE.2013.6606617
• Dorner, M., Mendez, D., Wnuk, K., Zabardast, E., & Czerwonka, J. (2025). The upper bound of information diffusion in code review. Empirical Software Engineering, 30(1), Article 2. doi.org/10.1007/s10664-024-10442-y
• Sadowski, C., Söderberg, E., Church, L., Sipko, M., & Bacchelli, A. (2018). Modern code review: A case study at Google. In Proceedings of the 40th International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP '18) (pp. 181–190). ACM. doi.org/10.1145/3183519.3183525
• Vella, A., & Blincoe, K. (2026). The impact of AI coding assistants on software engineering: A longitudinal study [Preprint]. arXiv. arxiv.org/abs/2605.23135