Guide
The Six Dimensions of Code Quality
Velocity is how much; quality is how well. Here are the six dimensions that make code quality specific and improvable, how they are scored, and how to read your team median against the platform.
Velocity tells you how much a team ships. The six dimensions of code quality tell you how well. Breaking quality into named dimensions turns a vague "the code is good" into something specific and improvable: you can see that scope and impact are strong while test coverage lags, and act on it.
This guide walks through all six dimensions, how a per-pull-request score aggregates to a defensible team-level median, and how to read your team median against a platform median without turning any of it into an individual scorecard.
Scope and impact
Scope and impact asks whether the change does something that matters and whether its size fits its purpose. A tightly-scoped change that solves a real problem scores well; a sprawling change that touches everything and resolves nothing scores poorly. This dimension rewards focus.
Architecture and design
Architecture and design looks at whether the change fits the system: sensible boundaries, appropriate abstractions, and no needless coupling. Good design here is what keeps a codebase cheap to change later, so this dimension is a leading indicator of future velocity.
Implementation quality
Implementation quality is the craft of the code itself: clarity, correctness, error handling, and the absence of obvious foot-guns. It is the dimension most people mean when they say "clean code", and it is where reviews most often add value line by line.
Risk handling
Risk handling asks whether the change accounts for what could go wrong: edge cases, failure modes, backwards compatibility, and safe rollout. High-risk changes shipped without guards score poorly even when the happy path is elegant. This dimension is where speed most often borrows from future incidents.
Test coverage and review readiness
Test coverage measures whether the change is verified appropriately for its risk, not a blanket coverage percentage. Review readiness measures whether the change was easy to review: a clear description, a digestible size, and context a reviewer needs. Both are gameable if turned into individual targets, which is exactly why they are aggregated to the team level.
Read team median against platform median
Each dimension is scored per pull request and aggregated to a team median. Compare that to a platform median from opted-in teams to see where you are strong and where you trail. Read the shape across all six, not a single dimension, and keep it strictly team-level: dimension scores are never a per-engineer ranking.