Code Review Diff-Size & Pace Simulator

This Diff

Diff size 240 LOC

Review pace 300 LOC/hr

Defect density 15 / 1000 LOC

Prediction

Predicted P(catch)

—

Review time

—

This Run

Defects present

Caught / escaped

0 / 0

Cumulative

Runs

Overall catch rate

—

unreviewed line
defect (ground truth)
caught by reviewer
escaped to production

How it works

Peer code-review studies (Cisco's review of 2,500 reviews; SmartBear's "11 Best Practices for Peer Code Review") consistently find the same shape: defect-detection effectiveness holds up to roughly 200 LOC and ~300–400 LOC/hour, then falls off as diffs get bigger or reviewers rush. This model turns that curve into two multiplicative penalty factors on a base catch probability:

f_size(LOC)  = clamp(1 − max(0, LOC−200)/1600,  0.15, 1)
f_rate(rate) = clamp(1 − max(0, rate−400)/1400, 0.15, 1)
P(catch)     = 0.92 · f_size(LOC) · f_rate(rate)

defects present  = round(LOC · density / 1000)
review time (hr) = LOC / rate

Each defect in the diff is an independent Bernoulli trial with probability P(catch) — most runs land near the predicted rate but small diffs show real run-to-run variance, exactly like real review data.
The amber blocks are ground truth (only you can see them) — the scan line sweeping the grid represents the reviewer reading line-by-line at the chosen pace; each block resolves to caught (green) or escaped (dark red) the moment the scan passes it.
Push diff size or pace far enough and P(catch) collapses toward the 15% floor — the well-known "rubber-stamp review" failure mode where a review still happens but stops finding anything.

Real-world relevance: this is why mature mobile teams cap diff size (e.g. Google's ~200-LOC guidance) and set a maximum reviewing speed rather than just requiring "a review" — the practice matters far less than the size and pace it's done at.

Scanning row 0 / 0idle

⚠ Couldn't load the 3D engineThree.js failed to load from the CDN. Check your connection and reload.