Code Quality Metrics That Actually Matter in 2026

Code quality metrics: the short answer

Code quality metrics are numbers that tell you how risky and how expensive a codebase is to change. The ones worth tracking are change failure rate, hotspots (complex code that changes often), cyclomatic complexity, duplication, short-term churn, test coverage on changed code, pull request size and security findings. Global coverage percentage and lines of code mostly mislead.

So.. almost every codebase I open for a technical due diligence arrives with a screenshot attached. An A rating, a healthy coverage number, zero critical issues. Then I open the module that handles payments, or permissions, and find the enormous function nobody wants to touch.

The numbers on the dashboard were accurate, just averaged across the whole repo, so the one file that actually hurts disappeared into the mean. This post is the list I use instead: what each metric tells you, the threshold I start from, the free tool that measures it, and how teams game it. It works the same for a 5-person seed startup and a 300-engineer enterprise platform team. The enterprise just has more places for bad code to hide.

What are code quality metrics, and why should anyone outside engineering care?

Code quality metrics fall into three groups:

• Structural metrics read the code itself: complexity, duplication, coupling, size.
• Behavioural metrics read the version control history: which files change, how often, how soon code gets rewritten.
• Outcome metrics read production: how often a change breaks something and how long it takes to fix.

Most teams only track the first group, because that's what static analysis tools show by default. The second and third groups are where the money is.

The best evidence I know for why this matters to a CFO or an investor comes from Tornhill and Borg's "Code Red" study of 39 proprietary production codebases^[1]. Across 30,737 files, low quality code contained 15 times more defects than high quality code, issues in it took on average 124% more development time to resolve, and the worst-case cycle times were 9 times longer. Worth knowing: one of the authors founded CodeScene, the tool used in the study, so read it as strong vendor-adjacent research rather than neutral gospel. The direction matches everything I see in practice.

At the macro level, the CISQ 2022 report put the cost of poor software quality in the US at $2.41 trillion, with accumulated technical debt at about $1.52 trillion^[2]. US figures, a few years old, and I haven't found a UK equivalent.

The 8 code quality metrics I actually check

In rough order of how much they tell me in the first hour.

1. Change failure rate

The share of deployments that cause an incident, a rollback or a hotfix. It's one of the four DORA delivery metrics, and it's the outcome every other metric on this list is trying to predict. If a team can't tell me this number, that's a finding in itself.

How to get it: count deploys and count incidents or reverts linked to them. Your CI/CD history plus your incident channel is enough for a first estimate. Tools like Sleuth, LinearB or a simple spreadsheet all work.

2. Hotspots: complexity multiplied by change frequency

This is the single most useful view of a codebase I know. A messy file nobody has touched in three years costs you nothing. A messy file that changes every sprint costs you every sprint. Rank files by how often they change, overlay complexity, and the top 10 usually explain most of a team's pain.

How to get it for free: git log --since="6 months ago" --format=format: --name-only | sort | uniq -c | sort -rn | head -20 gives you the most-changed files. Run a complexity tool over those 20 and you have a hotspot list in ten minutes. CodeScene does this properly, with history and trends, if you want it automated.

3. Cyclomatic complexity

The number of independent paths through a function, which is roughly the number of test cases you'd need to cover it. Microsoft's documentation quotes NIST Special Publication 500-235 on the threshold: McCabe's original limit of 10 "has significant supporting evidence", limits up to 15 have been used successfully, and going above 10 should be reserved for teams with experienced staff, formal design and a comprehensive test plan^[3].

I start at 10 per function and look hard at anything over 20. Free tools: lizard handles most mainstream languages, radon for Python, ESLint's complexity rule for JavaScript and TypeScript.

4. Duplication

Copy-pasted blocks mean every bug fix has to happen in several places, and in practice it happens in one. This metric matters more in 2026 than it did five years ago, for reasons I'll come to in the AI section. Free tool: jscpd covers most languages. I get uneasy above roughly 5% duplicated lines in application code, and I care more about where the duplication sits than the total.

5. Short-term churn

The share of new code that gets rewritten or deleted within a couple of weeks of being merged. Some churn is healthy iteration. A lot of it means requirements are unclear, reviews are too shallow, or code is being generated faster than anyone understands it. Git history gives you this directly; GitClear and similar tools chart it.

6. Test coverage on changed code

Global coverage is one of the numbers I ignore (more on that below). Coverage on the lines changed in each pull request is far more honest, because it measures whether the team is testing what it's building now. Most CI setups can enforce it: SonarQube's "new code" quality gate, Codecov's patch coverage and diff-cover all do this.

7. Pull request size and time to review

Large pull requests get rubber-stamped. Small ones get read. I look at the median lines changed per PR and how long PRs wait for a first review. If the median PR is over a few hundred lines, or reviews regularly take days, quality problems are being waved through regardless of what the scanner says.

8. Security findings and dependency age

Open high-severity findings from a SAST tool, secrets in the repo, and how far behind the main dependencies are. Free tools: Semgrep, GitHub's Dependabot and secret scanning, npm audit or pip-audit. In my experience, outdated frameworks are the finding that most often turns into a price chip in a funding round, because upgrading them is real, budgetable work.

Which code quality metrics should you ignore?

Not ignore completely. Stop using them as targets.

• Global test coverage percentage. Easy to inflate with tests that assert nothing. I've seen high coverage on codebases where the riskiest module had no meaningful tests at all.
• Lines of code. Tells you size, says nothing about quality, and rewards verbosity if anyone is measured on it.
• Total number of static analysis issues. A count of 4,000 "code smells" is noise. Ten blockers in the auth module is signal. Sort by severity and location, never by count.
• A single maintainability score. Visual Studio's Maintainability Index runs from 0 to 100 and rates anything from 20 to 100 as green^[4], which is a very generous band. Fine as a smoke alarm, useless as a target.
• Velocity and story points. These measure planning habits. I've called story points an arbitrary metric for years and I'm not changing my mind now.

Code quality metrics compared: thresholds, tools and how they get gamed

The thresholds are my starting points, not universal laws. A trading engine and a marketing site should not share a complexity budget.

How to measure code quality without buying anything

If you're starting from nothing, this is the order I'd do it in. It takes a competent engineer about a day.

1. Pull the change history. Run the git log command above and list the 20 most-changed files over six months.
2. Score those 20 files. Complexity with lizard, duplication with jscpd. Ignore the rest of the repo for now.
3. Write down your change failure rate for the last quarter, even if it's an estimate from Slack and the deploy log.
4. Add one quality gate to CI: coverage and new issues on changed code only. SonarQube, Codacy or Qodana will all do this; pick whichever your team will actually look at.
5. Review the list monthly with whoever owns the roadmap, and agree which hotspots get refactored while the team is already working in them.

If you want a quick single score to show someone non-technical, the code quality score checker turns a handful of these numbers into one figure. Treat that number as a conversation starter, not a verdict.

For running these metrics across an offshore or outsourced team specifically, I wrote a separate piece on code quality metrics for offshore teams, and the roundup of technical debt tracking tools covers the tooling side in more depth.

Do AI coding tools change which code quality metrics matter?

Yes, and duplication and churn are the two to watch.

GitClear's 2025 research analysed 211 million changed lines of code written between January 2020 and December 2024^[5]. Lines associated with refactoring (code being moved and reused) fell from 25% of changed lines in 2021 to under 10% in 2024, while copy-pasted lines rose from 8.3% to 12.3%. 2024 was the first year copy-pasted code overtook moved code. That's the period AI assistants went mainstream. GitClear sells analytics tooling, and the data shows a trend over that period rather than proof that each cloned block came from an AI, but it's the largest dataset I've seen on this.

Google's DORA research points the same way. The 2024 report found a 25% increase in AI adoption was associated with a 3.4% increase in code quality, alongside an estimated 7.2% reduction in delivery stability^[6]. The 2025 report, from nearly 5,000 respondents, found 90% now use AI at work and AI adoption still has a negative relationship with delivery stability; DORA's own summary is that AI "amplifies what's already there"^[7].

And on security, Veracode's 2025 GenAI Code Security Report tested code from more than 100 LLMs on 80 tasks and found security flaws in 45% of cases^[8]. Again, vendor research from a company that sells security scanning, so weigh it accordingly.

What I'd change if your team uses Cursor, Claude Code or Copilot heavily (and, honestly, most do now):

• Track duplication per pull request, not just as a repo total. Assistants happily regenerate a helper that already exists three folders away.
• Watch two-week churn. Code that gets rewritten almost immediately is often code nobody understood when it was merged.
• Keep PRs small, because the cost of writing code has dropped and the cost of reviewing it hasn't.
• Get a human to read authorisation and data access. Static analysis is weakest exactly where AI-generated code is most dangerous. Our guide to auditing AI-generated code goes through what to check, and our vibe-code fixes team does it for products that were mostly built by AI.

If you're rolling AI tools out across a larger engineering organisation, measure these before and after the rollout. That's a big part of how we run AI adoption for engineering teams: a baseline first, so you can tell whether the tools are helping or just producing more code.

A code quality dashboard vs a CTO reading the code

Tools are necessary. They're also where most teams stop. This is the difference I see between the usual options:

A dashboard tells you something is wrong. Someone who has run engineering teams tells you whether it matters, what it'll cost and what to do on Monday. You need both. Most teams only buy the first.

So, back to that A rating on the screenshot. Keep it, it's useful. Just put it next to the hotspot list, the change failure rate and the duplication trend, and look at the one file everybody avoids. That file is your code quality, whatever the average says.

Sources

1. Tornhill, A. and Borg, M. (2022). Code Red: The Business Impact of Code Quality, A Quantitative Study of 39 Proprietary Production Codebases. arXiv:2203.04374.
2. CISQ (2022). The Cost of Poor Software Quality in the US: A 2022 Report.
3. Microsoft Learn. Code metrics: Cyclomatic complexity, quoting Watson and McCabe, NIST Special Publication 500-235 (1996).
4. Microsoft Learn. Code metrics values.
5. GitClear (2025). AI Copilot Code Quality: 2025 Look Back at 12 Months of Data.
6. Google Cloud (2024). Highlights from the 10th DORA report.
7. Google Cloud (2025). Announcing the 2025 DORA Report: State of AI-Assisted Software Development.
8. Veracode (2025). AI-Generated Code Poses Major Security Risks in Nearly Half of All Development Tasks.

Frequently asked questions

What are the most important code quality metrics?

Start with change failure rate, because it measures the outcome you care about. Then track hotspots (complex files that change often), cyclomatic complexity, duplication, short-term churn and test coverage on changed code. Pull request size and open security findings complete the picture. Global coverage and lines of code are weak signals and easy to game.

How do you measure code quality?

Combine three sources. Static analysis tools such as SonarQube, lizard or jscpd read the code for complexity and duplication. Git history shows which files change most and how quickly new code is rewritten. Deploy and incident logs give you change failure rate. Focus on the most-changed files first rather than averaging across the whole repository.

What is a good cyclomatic complexity score?

Ten or below per function is the widely used starting point, from McCabe's original work as quoted by NIST Special Publication 500-235. Limits up to 15 have been used successfully by teams with strong testing and review practices. Anything above 20 deserves a close look, especially if that function also changes frequently.

Is test coverage a good code quality metric?

Coverage on changed code is useful; a single global percentage is not. Global coverage is easy to inflate with tests that assert nothing, and it averages away untested high-risk modules. Enforce coverage on each pull request's changed lines in CI, then spot-check whether the tests in critical modules actually verify behaviour.

Do AI coding assistants make code quality worse?

They can. GitClear's analysis of 211 million changed lines found copy-pasted code rising and refactoring falling as AI assistants spread, and DORA links higher AI adoption with lower delivery stability. Teams with small pull requests, strong tests and human review of risky code see the benefits without most of the downside.