Code Reviews
When the code finally failed, it affected every tenth user who downloaded the update. After receiving several reports, we investigated our changes and isolated a Merge Request (MR) that had passed all tests and produced no warnings during static analysis. Upon closer inspection, we discovered that the system was failing due to stale cached data from a specific client version.
Our code was technically correct—it ran and fulfilled all the requirements enforced by our automated CI/CD process. If only someone had warned us about the behavior of our distributed legacy tools.
Reviewing code has historically been a manual step in the CI/CD process. Team members evaluate the quality of our changes and scan for errors that may have slipped through the automated test suite. Everyone makes mistakes, and two pairs of eyes are better than one.
While select companies have experimented with automated code reviews based on neural network pattern recognition, it's only since the rise of large language models in late 2025 that AI-powered code review has gained broad acceptance. These tools improve every month, generating better feedback at lower cost. Rather than asking whether we should include AI code review in our CI/CD process, the question becomes which tools to use and at what stage.
Although AI tools reduce the burden on team members, they do not fully replace the need for manual code review. Whether our code fails due to functional errors or a lack of historical context, we can assume our customers won't hold our AI agents responsible…
Benefits of Manual Code Review
If the sole motivation of code reviews were to gatekeep the quality of our code contributions, modern AI tools could arguably fulfill much of that requirement. Static analysis, automated linting, and AI-assisted reviews already catch a wide range of issues efficiently.
However, reducing code review to a quality filter misses its broader purpose. Code reviews are not just about code critique—they are as much about code study. Their collaborative practice strengthens teams, distributes knowledge, and shapes engineering culture. Reframing code review as a form of shared learning rather than evaluation changes both the tone and our expectation of the practice.
Sharing Knowledge
When fixing bugs or building features, we gain further understanding of the domain problem. Left isolated, that knowledge remains with us. Code review is a vehicle for sharing knowledge. We, as the author, open a Merge Request with an insightful description and the code shows our work. In turn, feedback from domain experts in our team expands our insights into the codebase and the problem.
Sharing knowledge horizontally shifts the burden from individuals to teams, meaning that even if our "specialist" is sick, on vacation, or has left our company, the work is competently done by the team. As knowledge is shared horizontally, we reduce pressure on individuals and diversify responsibilities across our organization. This approach enables us to ensure consistent career progression as we remove hard dependencies of members within set positions.
Building Trust
Over time, having our code reviewed and reviewing our team members' code builds the mindset of a blameless culture. We dissociate our work done as being "our" code and move emotional connotations from our contributions to the work our team does as a whole.
The sooner we embrace a collective mindset, the sooner our team builds professional trust across contributors. Teams that build in public, share work-in-progress, and confidently ask for the opinions of their peers uncover potential concerns earlier in the development phase and thus reduce the overall cost of producing working software.
Providing context
Not all knowledge is documented. Organizations and products that have been around for a while tend to have made long-lasting decisions and commitments.
The correct context should have been provided during the initial design phase of our development process. At minimum, we make sure the relevant people review our changes before we integrate and ship them. Without this input, our implemented decisions may be incorrect, suboptimal solutions may be reintroduced, and historical mistakes may be repeated.
Identifying common mistakes and extending automation
Code reviews offer an organic way of examining the limitations of our automation. Identifying common mistakes and establishing automation practices to rectify these automatically for future development cycles lie at the heart of continuous improvement and the spirit of this book. We review and improve the process of code reviews over time, as this practice has the potential to become a bottleneck for development velocity if our practices do not evolve with our needs.
Over time, teams can detect common mistakes or anti-patterns, recognize repetitive feedback themes, and identify gaps in tooling or guidelines. These insights can then be used to introduce linters, static analysis, or automated checks. To reduce cognitive load during reviews, we consolidate coding standards and documentation.
Increasing Code Quality
Ultimately, yes, code reviews directly improve the quality of the code at hand. Having multiple engineers with different experiences and backgrounds study each other's work leads to implementations that are standardized, readable, and efficient. A fresh pair of eyes is more inclined to find potential errors. Alas, this immediate increase in code quality comes at a cost…
-
Good read? Unlock the rest of the chapter!
Engineering Collaboration is currently available as an Advanced Reading Copy for select readers.