We all agree that good quality code has been the holy grail of software. Quality directly impacts your bottom line. At XCentium we recently implemented an AI driven code review with considerable success to help in this effort.
I’ve heard arguments that modern software is so complex that bugs are expected. Instead of seeking a defect-free program, we should accept this reality and work around it. Fail fast and fix bugs quickly-even in production. That may work for some projects, but if you’re building code people pay for, I don’t think that’s the best approach.
For those who insist code can’t be defect-free, consider Margaret Hamilton, who wrote the Apollo Guidance Computer (AGC) software. The software was meticulously designed and rigorously tested to handle unforeseen issues. Its robustness was demonstrated during Apollo 11 when “program alarms” (like Error Code 1202) occurred due to hardware overloads. The software prioritized critical tasks and ignored non-essential ones, enabling a safe lunar module landing. Hamilton implemented error-detection and recovery mechanisms to ensure no known software bugs occurred during any crewed Apollo missions.
The next argument I hear is “Margaret Hamilton wrote her code 50 years ago; those were much simpler time. We don’t need NASA’s methodology today. Its overkill.” Wrong! With the advent of AI, we need defect free solutions more than ever. Take, for example, LexisNexis, which offers a legal LLM product, Lexis+ AI, designed to ensure high-quality and hallucination-free answers through rigorous testing and verification. This AI system includes hundreds of tests for each response.
That is QA in the new world of large language models. If you're involved in AI projects—and most of you will be—quality is no longer just about software defects. It also includes the accuracy and reliability of AI-generated output. The goalposts have shifted! With that in mind, any advantage we can gain in managing our workload, regardless of models, agents and automation, is a good thing.
According to recent GitLab data, nearly 60% of developers consider code reviews crucial for ensuring code quality and security, with regular reviews becoming standard practice across the industry.
At XCentium, we review every check-in. Yes, it’s more laborious, but we have evidence that this level of attention helps our teams and customers.
The structured process, where developers evaluate each other's code, ensures quality, efficiency, and adherence to established standards. Beyond catching bugs, code reviews foster an environment that promotes knowledge sharing and early problem detection.
The Impact on Software Quality
Teams that use systematic code review processes report up to 70% fewer defects in their source code. This dramatic improvement in code quality translates directly to business value, reducing rework costs and preventing critical issues from reaching production.
The impact of an effective code review extends far beyond technical improvements. Organizations report significant business benefits through reduced development costs.
Confronting Real-World Challenges
Despite the clear benefits, traditional code reviews present significant challenges. Time investment is perhaps the most pressing concern; developers typically spend between 2-15 hours per week on code reviews, with some teams seeing up to 35% of their time used by the process. This substantial commitment often creates bottlenecks in the development pipeline and can impact project deadlines, especially since many teams' defaults to just estimating the developers’ initial effort and complexity of tasks. Nobody plans to write bad code and spend hours fixing it.
The Human Element Challenge
Experienced reviewers bring valuable insights and context awareness, but they also face natural limitations. Cognitive fatigue sets in after reviewing large amounts of code, and maintaining consistent focus during long review sessions becomes increasingly challenging. Studies show that review effectiveness drops significantly after 60 minutes of continuous review, and defect detection rates decline as review sessions lengthen. In many projects, a senior developer or the senior architect is the designated reviewer. So, on a bad day, one of the best people on the project will be fatigued due to having too much code to parse through.
The Consistency Challenge
When we’ve tried switching the assignment to other team members, one of the most significant challenges became maintaining consistency. Different reviewers naturally apply varying standards, and thoroughness often fluctuates based on workload and time constraints. This inconsistency can lead to a frustrating experience for developers, where critical issues might be overlooked while minor stylistic preferences receive disproportionate attention.
Traditional code reviews can create significant workflow bottlenecks. Development teams report that review wait times can stretch from hours to days, with feedback loops extending even longer. The cost of context switching for reviewers compounds these delays, as developers must repeatedly pause their primary work to conduct reviews.
Industry data shows that these interruptions can reduce overall development productivity by up to 20%.
The Power of AI in Code Reviews
Organizations implementing AI-powered code review tools report remarkable improvements in their development processes.
The numbers tell a compelling story:
· up to 90% reduction in routine review time
· 70% fewer post-deployment bugs
· 50% increase in overall developer productivity
These improvements stem from AI's ability to provide instant, consistent feedback while handling routine checks that previously consumed valuable developer time.
Building Team Buy-In
The human element is still crucial in successful AI implementation. Organizations that achieve the best results focus on:
· Training to help developers maximize AI tool benefits
· Clear guidelines for AI-human collaboration that define roles and expectations
· Regular feedback channels that help refine and improve the AI review process
In our case, we ran a test of automated code reviews. Very quickly, we found that team satisfaction increased significantly once developers experienced how AI handles routine checks, leaving them free to focus on more complex and creative aspects of development.
One of the big selling points for the team was the ability of the system to catch hard-to-find logic issues AND to present code that addresses the problem.
Hard Numbers
I promised actual data from our experience. While the statistics listed earlier are correct, they are also abstract. Here is an example that is closer to reality. One caveat: you may read the following example and have an immediate reaction to that it is too high or too low. The example is not specific to you. Your mileage may vary. However, what does matter is the percentage of time the tasks take. Don’t be put off if you think the estimates are different from how you work. Look deeper and see the relationship between the tasks and their time as well as their potential savings.
Task Description
The task involves creating a Salesforce web page (LWR) that loads a grid based on Account and Contact data. The grid should be sortable, filterable, and pageable. One column should be based on data from an external API call (which means the API needs to be integrated as well).
Estimated Time Breakdown
Based on industry data and Salesforce development experience, the following estimated time breakdown is provided:
Development: 16 hours
Code Review: 2 hours
Fixes Based on Review: 4 hours
Total: 22 hours
Assumptions:
- The code fixing step is directly related to the code review changes.
- The developer has moderate experience with Salesforce development and LWR.
- The external API call is well-documented and relatively straightforward to integrate.
- The code review process is efficient and focuses on critical aspects of the code.
- The number of bugs found during testing is typical for a task of this complexity.
Bottom Line
By using automated code reviews, the time for this task is reduced by 37.5%, removing the 2 hours of reviews and 4 hours of related code changes.
Purely from a business perspective, the team cannot accurately anticipate the time needed for a given task to go through code reviews and bug fixes, but we do know that this time very often is not planned and regularly impacts velocity. Therefore, any savings that can be had in this area, while increasing quality, hit the bottom line directly.