TLDR overview
- Measuring code quality means tracking quantitative metrics and qualitative signals that together reveal how maintainable, reliable, and secure a codebase is.
- Metrics like cyclomatic complexity, code coverage, and technical debt turn a vague sense of "high-quality code" into numbers you can track over time.
- AI-generated code now ships in volumes that outpace manual review, making consistent, automated measurement mandatory rather than optional.
- SonarQube measures code quality across all code with static analysis, quality gates, and metrics for reliability, security, maintainability, coverage, and duplication.
Everyone agrees code quality matters. Far fewer teams agree on how to measure it. That gap is where debates stall, reviews turn subjective, and technical debt quietly compounds.
The problem is sharper now. AI coding tools generate code faster than any team can read it, and "looks fine" is no longer a defensible standard. You need numbers.
This page explains how to measure code quality in practice: which metrics matter most, how to assess AI and agent generated code with one standard, when to lean on quantitative versus qualitative signals, and how to track technical debt over time.
What metrics should I use to measure code quality?
Measuring code quality means quantifying the attributes that determine how maintainable, reliable, and secure a codebase is—complexity, test coverage, duplication, and accumulated technical debt—and tracking those measurements over time.
No single metric tells the whole story. A codebase can have 90% test coverage and still be a nightmare to change if every function is deeply nested and tightly coupled. Quality lives in the combination.
Here are the metrics that carry the most signal:
Cognitive complexity and coverage are the two most actionable metrics for most teams. Cognitive complexity tells you where code is hard to understand. Coverage tells you where in the code you have gaps in test case coverage, leaving you blind to whether that segment of untested code fulfills the desired functional need. Track both, and you catch the majority of quality regressions before they reach production.
One caution: metrics are diagnostics, and setting them as targets should be done with caution. When a coverage percentage becomes a goal in itself, developers might write shallow tests that hit lines without asserting behavior. Measure to inform decisions, not just to hit a number.
How do you measure the quality of AI-generated code?
The principle is simple: measure all code by the same standard, regardless of who or what wrote it.
AI-generated code introduces a specific measurement challenge. It is often functionally correct. It compiles cleanly, but might not follow convention or read well. It can reference APIs that don't exist, ignore your architecture, or carry subtle security flaws that a quick glance misses. Functional accuracy is not high quality.
The volume problem makes this worse. An agent can produce dozens of changes in the time a developer writes one function. And even as models are improving, they are trending towards generating even more lines of code to solve the same problem. Manual review, the traditional check on quality, cannot physically keep pace with a 40,000-line pull request. This gap between how fast code is produced and how fast it's validated is the central risk of AI-assisted software development.
Three practices keep measurement consistent across code sources:
- Apply one quality gate to all code. Separate, softer rules for AI output defeat the purpose. A single pass/fail standard on every change keeps the bar even.
- Measure at the point of change. Assess new and modified code as it enters the pipeline, not weeks later in a batch audit. Regressions caught early cost less to fix.
- Automate deterministic checks. Complexity, coverage, duplication, and security rules don't require human judgment. Automate them so human review focuses on intent and business logic.
The origin of the code shouldn't change how you measure it. What changes is the pace, and that raises the bar for how fast and how consistently your measurement runs.
Quantitative vs qualitative assessment
A complete picture of code quality needs both hard numbers and human judgment. Each catches what the other misses.
Quantitative assessment
Quantitative assessment relies on measurable metrics: complexity scores, coverage percentages, duplication ratios, and technical debt estimates. These are objective, repeatable, and easy to track over time. Static analysis tools generate them automatically, which makes them ideal for automated enforcement in a pipeline.
The strength of quantitative measurement is consistency. The same rule applies to every change, every developer, and every commit. No fatigue, no bias, no rubber-stamping.
Qualitative assessment
Qualitative assessment relies on human review of things numbers can't capture: whether the code solves the right problem and whether names and abstractions make sense to the next reader. Peer review and design discussion are the main tools here.
The strength of qualitative review is context. A metric can tell you a function is complex. Only a person can tell you that the complexity is essential to the domain, or that a simpler design was available.
Key distinction
Quantitative measurement scales; qualitative measurement judges. Metrics enforce standards automatically across thousands of changes. Human review evaluates intent and design on the changes that need it. Use automation for standards and reserve human attention for the questions only a person can answer. Teams that try to do both manually burn out. Teams that automate the measurable free their reviewers to focus on what matters.
How to track technical debt
Technical debt, including architectural debt, shows best whether quality is improving or eroding over time. Single-point measurements are useful, but the trend is what tells the real story.
Technical debt is the estimated effort required to fix all maintainability and architectural issues in a codebase, usually expressed in time. Tracking it as a ratio of the remediation effort against the total cost to build normalizes it across projects of different sizes. A rising tech debt ratio signals that shortcuts are accumulating faster than the team pays them down.
To track effectively:
- Measure tech debt on new and changed code separately. Overall codebase metrics move slowly and focusing only on it hides recent trends. Measuring tech debt of recent code changes surfaces problems while they're cheap to fix.
- Watch the direction, not just the value. A tech debt ratio of 5% is meaningless in isolation. A climb from 3% to 8% over a quarter is a warning sign that the maintainability of your code is worsening.
- Tie thresholds to a pass/fail gate. Trends only drive action when they block a code merge. A gate that fails when new code exceeds a defect or tech debt threshold turns measurement into prevention.
Measurements without setting a threshold of an unacceptable level is just a dashboard nobody checks. The point of tracking these metrics is to act on them before tech debt compounds to the point of slowing down developer productivity and forcing a refactorization project to remedy the accumulated debt.
How SonarQube helps you measure code quality
SonarQube measures code quality across all code, human-written and AI-generated, using automated code verification that runs in your developer workflow. It deterministically reviews every change against consistent logic, so your code standard is met and code quality doesn't shift based on who or what wrote the code, especially as different developers employ different agents for code creation.
SonarQube reports on the metrics that matter for measurement: reliability, security, maintainability, code coverage, duplication, and complexity, including both cyclomatic and cognitive complexity. It quantifies technical debt as remediation effort and surfaces code smells, bugs, and security vulnerabilities with the specific lines that produced them.
The quality gate is where measurement becomes enforcement. A quality gate is a set of conditions including coverage thresholds, complexity limits, zero new critical issues, that a new code change must pass before it can be approved for merging. SonarQube applies the gate to new and changed code, so measurement catches regressions at the point of change rather than in a later audit post-merge.
SonarQube integrates directly into the developer workflow. It runs in the IDE through SonarQube for IDE, in CI/CD pipelines with GitHub Actions, GitLab CI/CD, Jenkins, Azure Pipelines, Bitbucket Pipelines and Codemagic with specific pass/fail quality gate details within the pull request comments itself. That places measurement where the code is written and reviewed, not in a separate reporting step.
To get started, connect SonarQube to your DevOps platforms and configure a quality gate every change must pass before merge.