The defect bucket in the Bacchelli and Bird sample holds roughly 80 comments, because 14 percent of 570 is 79.8, and the code-improvement bucket holds about 165 [1][3][4][1][2]. That is a thin evidential base for a claim as load-bearing as "review is not mainly bug-hunting," and worth saying before anyone rewrites a checklist around it. The later Microsoft paper puts possible-defect comments near 15 percent, within a point of the earlier figure [5][3], and reports at least half of comments concerned long-term maintainability [5] - more than three times the defect share [7]. Google's 2018 case study arrived somewhere similar by a different route, reading 12 interviews and 44 survey responses against logs from 9 million reviewed changes, and concluding that review served as teaching and codebase maintenance [6][7].
A comment classification measures what reviewers typed, not what they prevented. The 30-point distance between the 44 percent who rank defect-finding as their top motivation and the 14 percent of comments that were defect-related [2][3][5] is not a clean contradiction, and the dev.to writeup concedes the point: stated motivation and classified output are different instruments [10]. It is still an awkward gap. If a team's review metric is defects caught per review, the metric is tracking the smallest category anyone measured, and is silent on the largest.
The category no defect counter can see is the one the writeup is actually about: whether the change belongs where it was put [8]. Its worked example is a composite with invented details [9]. A payment path runs validate, authorize, capture, settle, and someone adds currency conversion inside authorize. The conversion rounds correctly and has unit tests. But the settlement amount is already computed upstream and shipped with the order, so the change couples the authorization path to an exchange-rate source it never needed, puts rounding and rate-selection policy in a second place where it can drift, and establishes that authorize may alter pricing, which opens the door to fees and discounts landing there next [9]. No syntax rule surfaces any of that, and more tests around the conversion do not address it either [11].
That is why the artifact of a good review is often a decision rather than a comment thread, which is the position the writeup ends on: fewer comments, better decisions [12]. A team that wanted to measure the work the research actually found would have to count something like reviews that changed where code lives, or that sent a responsibility back to its owner. Nobody's dashboard reports that. Meanwhile a review whose only output was a caught bug has, by omission, ratified every structural assumption in the diff [8].
