Measuring Code Quality: Which Metrics Matter and Which Just Reassure

Code quality cannot be expressed with a single number. The measurement only becomes reliable once you look at four things together: test coverage of the changed lines, the duplication share, the change frequency of risky files, and the time to fix a bug. The international reference standard for this is ISO/IEC 25010:2023.

What is code quality, really?

Code quality is not an adjective, it is a model made of several characteristics. The authoritative standard is ISO/IEC 25010:2023, part of the SQuaRE family. The version revised in 2023 describes nine product quality characteristics.

New compared with the previous version is the Safety characteristic, with sub-characteristics such as risk identification, a safe state in the event of failure, and hazard warning. In addition, Usability and Portability were replaced by Interaction Capability and Flexibility; the earlier "Quality in Use" model has lived in its own standard, ISO/IEC 25019, since 2023.

For everyday work the standard is too coarse to measure directly. It is still useful because it structures a discussion: when someone demands "better quality," looking at the nine characteristics clarifies in two minutes which one is meant.

Which metrics really say something?

Four, and they only work together. Any single one can be gamed without quality actually improving.

Metric	What it shows	Why it is worthless alone
Coverage of changed lines	whether the new code has been checked	says nothing about the quality of the assertions
Duplication share	how often the same logic exists more than once	some duplicates are deliberate and correct
Change frequency times complexity	where changes actually hurt	shows symptoms, not causes
Time to fix	whether the system is manageable	can be dressed up by simply not reporting issues

Why is test coverage alone misleading?

Because it counts which lines were executed, not which behavior was checked. A test that calls a function and checks nothing produces a hundred percent coverage for that function and zero insight.

For AI-generated tests this is more than a theoretical objection. A model that writes tests for existing code derives the expected values from that code's own behavior. If the code contains a bug, the bug becomes the assertion. The test is green and protects the bug.

Two countermeasures: first, measure coverage of the changed lines instead of overall coverage; the overall figure gets diluted and barely moves. Second, occasionally run mutation tests: they deliberately alter the code and check whether at least one test notices. That is the only widely used method that measures the quality of the tests themselves. More on this under test coverage for AI code.

How do I introduce quality metrics without demotivating the team?

By applying metrics to changes rather than to people, and by setting thresholds for what is new rather than for the existing codebase.

• No metrics about people. Lines per developer, number of commits, bugs found per reviewer: all of that produces behavior that improves the number, not the product.
• Freeze the existing codebase, tighten the new. The old codebase stays as it is; the threshold applies to new and changed lines. That way every change becomes a small improvement, without anyone having to fund a big cleanup.
• History rather than a snapshot. A duplication share of nine percent is meaningless without a direction.
• Few numbers. Four metrics get read. Twenty turn into a report nobody opens.

Which metrics matter most for AI-assisted development?

Duplication share and dependency growth: both react directly to the typical patterns of generated code.

For the duplication share, the GitClear analysis provides the evidence: both duplicated blocks and copied code have increased markedly since 2022. Anyone who measures only test coverage does not see this movement: it happens between files, not within them.

Dependency growth is the second blind spot: a tool that adds packages along the way changes your attack surface and your license exposure without triggering a single metric that is normally monitored.

Frequently asked questions about quality metrics

What is good test coverage?

There is no universally valid target figure, and any percentage you hear quoted is a convention, not a standard. A more solid rule is: new and changed code should not fall below the project's existing coverage. That way the value rises on its own, without an arbitrary limit.

What is the difference between ISO 25010 and ISO 25019?

ISO/IEC 25010:2023 describes product quality, meaning properties of the software itself. The earlier "Quality in Use" model, quality from the perspective of usage, was moved into ISO/IEC 25019 as part of the 2023 revision.

Do I need a tool like SonarQube for this?

Not necessarily. Duplication share and complexity are also delivered by free analysis tools, and change frequency comes from Git itself. A platform pays off mainly for the history and the threshold logic; that is exactly what the term quality gate was coined for, see what is a quality gate.

How often should this be measured?

Automatically on every change, reviewed once a month. Looking more often creates noise, looking less often misses trends.

Measuring happens fast, acting on it happens rarely. Code Guardian closes this gap by not claiming the result of a change but proving it: with the output of the check, not with a promise that a check took place.

Sources

• ISO/IEC 25010:2023, Systems and software Quality Requirements and Evaluation (SQuaRE), Product quality model (nine characteristics, new: Safety; Quality in Use moved to ISO/IEC 25019).
• GitClear, The Maintainability Gap: 2026 AI Code Quality Research.

As of July 27, 2026. General professional context. Standard citations reflect the structure and do not replace consulting the standard itself.