Symphony Apps Development logo — teal interlocking S monogram beside the studio wordmark
All writing

What code review looks for that a linter cannot

Static analysis has absorbed most of the mechanical checks a reviewer used to do by hand. What is left is smaller and harder to automate away.

Category
Engineering
Reading time
6 min
Published
03 Jul 2026
Topics
Engineering, Quality, Process

A decade ago, a good reviewer caught formatting inconsistencies, unused imports, obvious null dereferences and naming that broke convention. Tooling now catches all four before a human sees the diff. That has not made review shorter — it has changed what review is for.

What is left after the machine pass

The remaining questions are all versions of "is this the right thing", not "is this correctly written". Correct-and-wrong is the failure mode tooling cannot see, because tooling has no model of intent.

  • Does this change match the ticket, or a plausible neighbour of it.
  • Does the error handling match the actual failure modes of the system it calls, not a generic set.
  • Is this the second implementation of a rule that already exists somewhere else in the codebase under a different name.
  • Will this be understandable to whoever touches it next, which is a judgement about the reader, not the code.

Why this got harder, not easier

Generated code raised the floor on mechanical correctness — it rarely has a typo or an unused variable — which removed the easy wins a reviewer used to get through quickly. What is left in every diff is the hard 20%, concentrated, with none of the easy 80% to warm up on or to pad a sense of thoroughness.

Automating the mechanical checks did not make review easier. It removed the parts that felt like progress and left the parts that require actually thinking.

The habit we had to build deliberately

Reviewers who came up checking formatting and naming had a rhythm that no longer applies. We now train new reviewers explicitly on the four questions above, with worked examples of diffs that pass every automated check and are still wrong, because that category of diff is now the majority of what reaches them.

Where this leaves pairing

We pair more than we used to, specifically on the intent-level questions, because two people forming a judgement together catches more than one person reading a diff alone, and judgement is exactly the part that resists a solitary checklist.

The number that moved

Review time per diff went down after we automated the mechanical checks. Review time per defect caught did not move nearly as much, which told us we had shifted effort rather than reduced the work that actually mattered.

Tell us what you’re trying to ship

A first call is thirty minutes and costs nothing. Bring the problem, not a spec — working out what to build is the part we are good at.

Or email office@symphonyapps.ro. We reply within one business day, in English or Romanian.