An engineer invests four days constructing a feature. The work involves refactoring two services, modifying the database schema, updating the API contract, and implementing tests. The pull request encompasses 47 changed files, 1,200 lines added, and 400 removed. A review is requested. Forty minutes later, a colleague provides feedback: “Looks good to me. Minor note: consider renaming this variable.” The pull request is approved.
This represents the current state of code review across the majority of engineering organizations. It is not review. It is a procedural ceremony that engineering teams perform to maintain the perception of a quality safeguard without actually constructing one. The approval indicator on the pull request signifies “someone examined this briefly,” not “someone verified this is correct.” At an organizational level, this distinction is well understood but rarely addressed.
Empirical Analysis: The 90-Second Review
Peer-reviewed studies on code review behavior consistently identify the same pattern: reviewers spend an average of 60 to 90 seconds per file. This figure applies uniformly, encompassing files with complex concurrency logic, files that modify authentication flows, and files that alter financial calculations. The median review time does not correlate with file complexity.
Within a 90-second window, a reviewer can determine whether the code compiles conceptually, whether variable names conform to conventions, and whether obvious syntax errors exist. A reviewer cannot verify that logic handles edge cases correctly. A reviewer cannot reason about race conditions. A reviewer cannot evaluate whether error handling is comprehensive. A reviewer cannot assess whether tests actually validate what they claim to validate.
What a reviewer can accomplish in 90 seconds is leave a comment regarding formatting. Research from SmartBear and Microsoft confirms that the majority of review comments, approximately 70-75%, address cosmetic concerns: naming, whitespace, and style consistency. Comments that identify actual defects, including logic errors, missing validation, and incorrect assumptions, constitute fewer than 15% of all review feedback. This is not attributable to reviewer negligence. It reflects the reality that identifying substantive issues requires the depth of focused analysis that a 90-second review structurally cannot provide.
Structural Impediments to Effective Review
Attributing the problem to individual reviewer performance is a misdiagnosis. The failure is structural, not personal. Every incentive in a modern engineering organization operates against thorough code review:
- ●Review time is unaccounted work. No sprint plan allocates capacity for “spend three hours reviewing another engineer's code.” Review time does not appear in velocity calculations, does not move tickets across the board, and does not contribute to individual output metrics. It is organizationally invisible labor.
- ●Large pull requests induce cognitive overload. A 1,000-line diff triggers a psychological response closer to “approve and proceed” than “analyze systematically.” Research demonstrates an inverse relationship between pull request size and review thoroughness per line. This is the opposite of what effective quality assurance requires: large changes carry higher defect probability, not lower.
- ●Social dynamics suppress critical feedback. Blocking a colleague's pull request introduces interpersonal friction. Requesting changes can be perceived as criticism. Asking “what was the rationale for this approach?” can be interpreted as “this approach is incorrect.” Most engineering teams have not established the psychological safety infrastructure required for genuinely rigorous peer review.
- ●Reviewers lack architectural context. The reviewer examines a diff in isolation. They do not possess the complete picture of why specific decisions were made, what alternatives were evaluated, or what constraints governed the implementation. Without this context, review is limited to surface-level analysis: syntax, style, and obvious errors.
Metric Misalignment: The Approval Speed Trap
A frequently overlooked factor: most engineering organizations track how rapidly pull requests receive approval, not how thoroughly they are reviewed. The metric under observation is “time to merge.” A short time to merge is treated as a positive indicator. A long time to merge is treated as a process inefficiency.
This creates a perverse incentive structure. The reviewer who invests two hours in careful analysis, identifies a subtle defect, and requests changes is penalized by the metrics. They have increased time to merge. The reviewer who scans the diff, provides an “LGTM” comment, and approves within five minutes is rewarded. They have maintained pipeline velocity.
Over time, this incentive structure shapes organizational behavior. Thorough reviewers learn that their diligence is not valued by the measurement system. Rapid approvers learn that speed is rewarded. The entire review culture migrates toward rubber-stamping, not because any individual or team decided it should, but because the incentive structure made this outcome inevitable. Organizations that measure review depth alongside review speed report 35% higher defect detection rates at the review stage.
Effective Defect Detection Mechanisms
If code review is predominantly theatrical in its defect detection capacity, what mechanisms actually identify defects? The evidence points to approaches that are less visible but measurably more effective:
- ●Synchronous pair programming for high-risk changes. Two engineers reasoning through a problem in real time identify more defects in 30 minutes than asynchronous review achieves in any timeframe. The synchronous conversation forces both participants to articulate their assumptions, and unexamined assumptions are the primary source of defects. Organizations utilizing targeted pair programming report 60% fewer defects in critical path code.
- ●Small, focused pull requests. A pull request that modifies a single concern is genuinely reviewable. A reviewer can maintain the entire change in working memory, reason about edge cases, and identify substantive issues. Data from GitHub and GitLab indicates that pull requests under 200 lines receive 40% more substantive review comments than those exceeding 500 lines.
- ●Automated analysis for deterministic checks. Static analysis tools, linters, type checkers, and security scanners do not experience fatigue. They do not experience social pressure. They evaluate every line, on every commit. Engineering teams should delegate mechanical verification to automated systems and reserve human review capacity for logic and design evaluation.
- ●Post-deployment review with observability. Some engineering organizations have determined that reviewing code after deployment, when actual runtime behavior is observable, produces more actionable insights than pre-merge diff review. This approach requires robust observability infrastructure and feature flag capability, but it identifies issues that no amount of static diff analysis would reveal.
Specifications for an Effective Review Process
Consider a code review process in which the reviewer checks out the branch, executes the code locally, and attempts to produce failure conditions. In which test assertions are evaluated not for existence but for correctness of coverage. In which data flow is traced from input to output with the question “what occurs if this value is null?” applied at every boundary.
That review requires two hours, not ten minutes. It is cognitively demanding. It would measurably reduce the team's throughput. And it would identify defects that no quantity of rapid reviews would ever surface.
Most engineering teams are not prepared to invest that cost on every pull request. This is a reasonable position. However, the honest articulation of that position is: “Engineering teams utilize code review for knowledge distribution and style consistency, not for defect detection.” If that statement were formalized, it would necessitate a different testing strategy, one that does not depend on a process that was never performing the defect detection function attributed to it.
Recommendations for Process Realignment
Code review delivers genuine value. It distributes architectural knowledge. It maintains style consistency. It provides cross-team visibility into implementation decisions. These are legitimate benefits that warrant preservation.
However, engineering organizations that depend on code review as a primary defect detection mechanism are depending on a process that does not perform that function reliably. The approval indicator on a pull request is not a certification of correctness. It is a record that someone examined the changes briefly and did not observe anything obviously incorrect. These are fundamentally different assurances.
High-performing engineering teams understand what code review does well and what it does not. They do not assign expectations the process cannot satisfy. They invest in mechanisms that actually detect defects: comprehensive automated test suites, observability infrastructure, canary deployments, and targeted deep-dive review for high-risk changes. They cease treating an LGTM comment as a quality gate. The first step toward constructing an effective quality assurance system is acknowledging that the current one is insufficient for its stated purpose.