Skip to main content
Architecture & Engineering

Code Review

Code review is the practice of having a second engineer read a change before it merges, checking correctness, design and risk. Done well it is the cheapest stage at which to catch defects and the main way architectural context spreads across a team; done badly it becomes a bottleneck or a rubber stamp.

What reviews actually catch determines what they should look at. Logic errors, unhandled edge cases, design drift from the surrounding system and missing tests all reward human attention. Formatting, naming style and import order do not — they belong to linters and formatters, and spending review time on them consumes the scarcest resource in the process.

Size dominates everything else. Defect detection falls sharply once a change passes a few hundred lines, because reviewers stop reading and start skimming; a thousand-line pull request gets approved on faith. The discipline that makes review work is unglamorous: small, focused changes; a description that states intent rather than restating the diff; and review latency measured in hours, because review wait time is cycle time and stale pull requests rot.

AI coding tools have shifted the balance rather than removed the need. LLM review assistants work well as a first pass on mechanical issues, which frees human reviewers for design and intent — the questions of whether this change should exist and whether it fits the system. The harder problem is volume: generated code arrives faster than humans generate it, which makes review the bottleneck and raises the cost of the rubber stamp. The standard has to stay where it always was — nobody merges code they could not defend in an incident review.

High-risk areas deserve more than the default process. Authentication changes, data migrations, payment logic and permission models warrant reviewers with specific context — sometimes a required second approval from the owning team — because the cost asymmetry is extreme: ten minutes of specialist attention against an incident that outlives the quarter. Checklists earn their place here, not as bureaucracy but as the guarantee that the obvious questions get asked every single time, including the tired Friday afternoon ones.

Review is also the main channel through which system knowledge spreads. The reviewer learns how parts of the codebase they do not own actually work; the author learns the conventions and the reasoning behind them; newer engineers grow faster through reviewed work than through any training material. Teams that optimise review purely for defect capture and speed miss that they are also running — or neglecting — their most effective mechanism for keeping more than one person able to maintain any given system.

Codazz builds this in production — QA & Testing.

FAQ

Code Review
FAQ.

Common questions about code review.

Ask Us Anything

A focused review of a small change takes 15 to 30 minutes; anything routinely longer means the changes are too large or the reviewer lacks context the description should have supplied. Waiting time matters more than reading time — reviews returned within a few hours keep cycle time healthy, while multi-day queues silently tax every change in the system.

Yes, in two directions. Automated review catches mechanical issues before humans look, which is genuinely useful. But generation also increases the volume of code arriving for review, and code nobody on the team wrote demands more scrutiny, not less — the reviewer becomes the only person who has actually read the change with intent to understand it.

As a default, yes — the moment exceptions become routine, the exceptions find the riskiest changes. The proportionate version is risk-tiered: a typo fix gets a fast skim, a payment-flow change gets a specialist. What does not work is exempting senior engineers, which quietly removes review from the changes with the largest blast radius and tells the whole team the process is optional.