"We outsource development, and every time we receive reports saying 'review completed.' Yet bugs still appear, and whenever we try to fix something later, we're told 'touching that will break things, so it will be a major undertaking.' Are reviews really doing anything?" We received this consultation from a business owner commissioning system development. Hearing reports that "code is being reviewed" sounds like proof of quality assurance. However, review frequency and comment volume do not necessarily correlate with quality.
When we categorized three months of review comments individually at one project site, the results were clear. Only two types of comments actually prevented bugs and simplified subsequent maintenance; the vast majority of the rest consisted of personal preferences and trivial formatting remarks. In this article, after explaining what these two effective types are, we outline the questions project owners should ask to determine whether their reviews are functioning effectively from a practical standpoint.
Most review comments do not improve quality
Let us start with a counterintuitive fact: the number of review comments does not scale with quality. In fact, reviews with high comment counts are often bloated with expressions of personal preference.
Categorizing three months of data revealed that most comments fell into categories like these: preferences on variable naming, styles of brackets and indentation, suggestions on "how I would write this," and minor formatting details that do not affect runtime behavior. While these may appear to indicate thorough review at a glance, fixing them does not alter product behavior in the slightest, nor does it reduce bugs. Moreover, handling these comments prolongs review discussions, causing points that truly require scrutiny to get buried. The assumption that a review with many comments is a good review must first be discarded.
Only two types work: comments on breaking behavior and comments on future headaches
So, what are the two types of comments that actually prevent bugs and ease future maintenance? They break down into the following two.
The first consists of comments pointing out that behavior will break. Things like crashing when specific input arrives here, duplicate data being created if this condition is missing, or corrupt results when processes execute concurrently—in short, comments identifying issues that will actually turn into defects if left alone. Each of these preemptively eliminates an incident that would have occurred on the client's end. The second consists of comments pointing out that code will become unmaintainable later. Examples include implementations where adding the next feature will force a complete rebuild, parts where identical logic is scattered across three locations causing inconsistencies if only one is updated, or code that nobody will understand six months from now—implementations that work today but cause future modification costs to skyrocket.
| Comment type | Effective? | Significance for project owners |
|---|---|---|
| Breaks behavior / leads to bugs | Effective | Preemptively eliminates incidents that would occur on the client's end |
| Architecture preventing future maintenance or modifications | Effective | Prevents future rework costs and code abandonment |
| Preferences regarding naming, formatting, or coding style | Hardly effective | An area that should be delegated to automated formatting tools |
| Minor comments that do not affect runtime behavior | Hardly effective | Increases back-and-forth and buries essential issues |
What these two have in common is that they impact the future rather than just the present. Bug-related comments preempt post-release incidents, while architecture-related comments preempt future modification expenses. Conversely, reviews lacking these two aspects do not reduce the maintenance and incident response costs project owners actually pay, even if labeled as "reviewed" in reports. While the question of how to review AI-generated code is covered in our article on reviewing AI-generated code, the core focus required of human reviewers remains unchanged across these two types.
Leave stylistic feedback to tools, not humans
Does this mean naming conventions and formatting do not matter? Not at all. The accurate framing is that they are jobs for automated tools, not tasks for humans to comment on.
Formatting code and standardizing syntax can be handled mechanically without human intervention by introducing automated formatting tools and static analysis. Offloading this to automated systems frees human reviews to focus on the two vital areas: comments on breaking behavior and comments on future maintenance issues. The concept of ensuring quality mechanically via testing is summarized in our article on guaranteeing test quality; reviews operate on the same principle—delegating what can be automated to machines, while humans focus on architecture and behavior that only humans can evaluate. Development teams that establish this division of labor achieve high impact with fewer comments.
Three questions project owners should ask
Project owners do not need to know how to read code to evaluate quality. Simply asking your development company the following three questions will clearly reveal whether reviews are functioning.
First: "Are formatting and coding style standardized using automated tools, or are people pointing them out manually?" If they answer that humans point them out manually, there is good reason to suspect human time is being spent on non-essential matters. Second: "What specific bugs or future rework are reviews primarily preventing? Could you share one recent concrete example?" If examples of comments on breaking behavior or future maintenance headaches come up readily, their reviews are focused on what matters. Third: "Have any defects slipped through reviews and surfaced later, and why were they missed during review?" Teams that can discuss causes without hiding failures possess the feedback loop needed to improve their reviews. The underlying mechanism for rapid review turnarounds is also discussed in our article on splitting PRs.
Measure quality by incidents prevented, not the number of comments
Code review is a vital process supporting the quality of outsourced development. However, reports stating "code is reviewed" and high comment counts do not serve as proof of quality. What actually works are just two types: feedback preventing broken behavior, and feedback preventing code from becoming unmaintainable in the future; everything else belongs to automated tools. Project owners will do well to evaluate quality by what incidents and rewrites are prevented, rather than by the number of comments.
A simple first step is to pose the three questions above to your current development company. If you are experiencing challenges such as "we are told code is reviewed, yet bugs don't decrease," "every subsequent fix turns into a massive effort," or "we have no way to verify quality from the outside," feel free to contact us via GleamHub's development, AI, and automation consultation. From inspecting whether existing development review practices focus on the core essentials to separating what should be automated, we will work alongside you from the project owner's perspective.
