# Code review increases understanding of the underlying system The purpose of code review has shifted in the age of AI agents writing the majority of the code. Code review is no longer about finding bugs, debugging tricky logic, increasing code readability, or tidying up test cases. Code reviews are for increasing understanding of the underlying system. Review is an attempt to develop an internal mental model of the behavior of the system and reason about the changes that are being made. Code review is trying to catch undesirable changes to the system's behavior and architecture. Here is a process that I've been using that I'm finding fruitful: 1. **Form your understanding of the way the system currently works.** This might mean creating an architecture diagram to understand how the different components relate, or creating an interaction timeline. It might be worth inspecting some area of the codebase or interrogating an LLM about existing behavior. Whatever you need to form your mental model of the system. 2. **Understand what behavior is being changed and guess at a desired implementation.** Based on the description in the Pull Request, do you understand what is changing and why the change is happening? Do you agree that the change is reasonable? Importantly, you should imagine how the change to the behavior would be made without consulting the actual code yet. This acts an assessment of your own understanding of the code, which helps you avoid the illusion of understanding. 3. **Assess the actual code versus your guessed implementation.** Does the actual changeset surprise you? If you are surprised by some of the code changes, find out why you're surprised. Did you not understand the way the system worked? Is the change being made a stronger or weaker solution than you had imagined? Does the changeset loop in some unnecessary changes? If you have access to the original LLM session that created the PR, interrogate the LLM for why specific changes were made. Q: Can I review my own code? Absolutely! You could do code review on your own PR created by an LLM. Why have another reviewer on the team? [[Knowledge exists between people in their relationship|Understanding is something that we share]] across the team. By having another human reviewer, we are increasing our mutual understanding of the system and also sharing awareness of changes to the system. Q: What about code that changes the UI, docs, etc? These are often the most important behavior changes, but they are less about reviewing the code and more about verifying the behavior of the system through the user interface.