Free tool · runs in your browser

How many hours of code review does your week need?

Coding tools made changes faster to write and larger. They didn't make them faster to read. Put in last week's merged changes and the time your reviewers really have, and see the hours careful review needs at 400 lines an hour, the gap, which changes to split, and a one-page review routine to print.

Your numbers are saved in this browser only. Nothing is sent to us.

Start from an example

Illustrations, not benchmarks. Your own repository history has the real counts: the merged list for last week, with lines added plus removed.

Last week's merged changes

Changes up to 400 linesHow many were mergedTheir average size (lines)Changed lines, not counting tests and generated filesChanges over 400 linesHow many were merged; 0 if noneTheir average size (lines)Same count: added plus removed, without testsLines in the four areas (%)Sign-in, permissions, money or data migrations

Your reviewers

People who reviewAnyone who approves other people's changesHours each can give a weekHonestly, after their own workCareful pace (lines an hour)400 is the top of the SmartBear range; above 500 finds far fewer faultsSize limit (lines)Larger changes go back to be split

Your one-page review routine

Team or product (optional)Goes in the headingSecond reader for the four areasA name is better than a rule

Code review routine

1. The person who opens a change owns every line. They have read all of it before asking anyone, and can explain any part without looking it up. "The tool wrote that bit" is not an answer.
2. Size limit: 400 changed lines, not counting tests and generated files. Anything larger goes back to be split (data model, then server logic, then screens). Reformatting and renames go in their own change.
3. Four areas always get a second person, read slowly: sign-in and sessions, permissions (every read and write checks whose record it is, on the server), money (whole cents, one rounding place, a repeated request charged once, refunds, failures) and data migrations (can it be undone, backup from before, table locks, rows written during it). Second reader: a second reviewer (not the author). Also: new dependencies, keys, deploy scripts and infrastructure.
4. The tests are the contract, so a person decides them. Write the cases that must hold before the code is generated. Read the tests first, against that list. Any existing test changed or deleted needs a reason in writing. A new test must fail when the feature is switched off.
5. Read in a fixed order: summary, tests, files in the four areas, everything else. Sittings of up to an hour, at no more than 400 lines an hour. Then run it and try the unhappy path: signed in as one customer, ask for another customer's record by its number.
6. A machine reviewer is a first pass, not a signature. Run it before the person, never in place of one, and record which person approved each change.

From biz59.net/tools/review-load

Why 400 lines an hour

SmartBear's study of a programming team at Cisco concluded that a reviewer should look at no more than 200 to 400 lines at a time, that attention starts dropping off after about 60 minutes, and that reading faster than 500 lines an hour finds far fewer defects. Google's engineering guide says 100 lines is usually a reasonable size for a change and 1,000 usually too large. Meanwhile Faros AI measured teams using AI heavily merging 98% more pull requests, each 154% larger on average, with review time per request up 91%.

What reviewers miss in a long, tidy, generated change, and the six rules behind the routine above, are in our article who reads the AI's code?. To practise finding the fault in a confident change, try the code review take-home.

Sources: SmartBear, best practices for peer code review; Google engineering practices, small CLs; Faros AI, the AI productivity paradox (July 2025). A model, not a measurement. More free tools: biz59.net/tools.