What is Eight Review Categories?

Why It Matters

Ad hoc review finds what the reviewer happens to think about. One engineer reads for security, another for readability, and neither notices that availability went unexamined in the last forty pull requests. The result is a process that feels thorough and has measurable blind spots.

A fixed rubric changes the question from “did anyone look” to “which dimensions did we cover, and which did we skip deliberately”. That is a decision a team can make once and then measure, and it is the reason a review tool needs a declared category list rather than a general promise to find issues.

The Eight

Security. Injection, unsafe deserialisation, credential handling, dependency risk, and the access boundary a change widens.

Availability. Failure modes, retry behaviour, timeouts, and what happens when a dependency is down rather than slow.

Performance. Query cost, algorithmic complexity, unnecessary round trips, and work that moved onto a hot path.

Scalability. What holds when the input is ten times larger, the concurrency ten times higher, or the data set grows by a year.

Architecture. Whether the change fits the intended design or quietly starts a second one, and whether the dependency direction still makes sense.

Error handling. Whether failures are caught, surfaced, and recoverable, and whether an error path was tested rather than assumed.

Code quality. Readability, naming, duplication, and the small decisions that determine what the next person can change safely.

Testing. Whether the change is covered, whether the test would fail if the behaviour regressed, and whether the edge cases in the code have a case in the suite.

How to Use It

Decide which categories matter for your codebase and which are genuinely out of scope, then make the tool enforce the list rather than trusting attention. A payments service and a marketing site will not weight these the same way, and stating the difference is what turns a checklist into a policy.

Coverage is also the honest way to compare tools. A tool that reviews for three of the eight categories is not weaker at review; it is reviewing something narrower, and the pricing should be read in that light.

Where It Breaks

Categories as a slogan. A tool that claims all eight and reports generic findings across them has a list, not a rubric. The test is whether a finding names the category and the reason.

Coverage without depth. Detecting an issue, explaining it, and proposing a fix are three different levels of usefulness. A tool that only detects leaves the interpretation to the reviewer, which is where the time goes.

The rubric that never changes. Categories are a policy, and policies need an owner. A list nobody revisits will keep checking for a class of bug the team eliminated two years ago.

Review volume as the metric. Comments per pull request rewards noise. Coverage of the categories that matter, and the rate at which findings are acted on, are the numbers that describe the process.

Coverage that stops at the diff. A change can be correct in isolation and wrong for the system. Architecture and scalability are category-level judgements, which is why they belong in the rubric rather than in a senior reviewer’s head.

How Flytebit Handles It

Our review product grades every commit across these eight categories, with a severity on each finding and the reasoning attached, which is what makes the coverage claim checkable rather than a feature list. The rubric is also the answer to a buyer’s question about scope: which categories a tool covers determines what you still need a person for. The comparison framework is in how to choose a code review tool, and the product itself is PASSR.