Test coverage targets when AI writes the tests

Use coverage to find untested code, not as a target. When AI writes tests, a hard threshold is easy to hit and says little about quality. Track coverage on new code as a floor, and judge test quality by whether tests fail on broken behavior.

What the long standing advice says

Martin Fowler calls coverage a useful tool for finding untested parts of a codebase and of little use as a numeric statement of how good your tests are. He adds that if you make a certain level a target, people will try to attain it. He is wary of 100 percent and mocks mandated thresholds such as a flat 87 percent. He also says low numbers, say below half, are a sign of trouble.

Those lines were written about human teams. They apply with more force when a tool can generate hundreds of assertions in a minute.

How AI changes the problem

A model asked to raise coverage will do so. It can call every function, assert that the result is not null and move on. The number goes up and the protection does not.

That is Goodhart's law in practice. DORA's guidance on delivery metrics gives the same warning in general terms: mandating targets invites teams to game the numbers.

A better set of signals

Pair coverage with signals that are harder to fake:

• Escaped defects. How many bugs reached production in code that had tests?
• Mutation survivors on changed files. See the post on mutation testing for AI written tests.
• Reviewer notes. How often do reviewers ask for a test to be rewritten?
• Developer confidence. Fowler suggests asking whether developers are rarely hesitant to change code.

Where a threshold still helps

A floor on new code is reasonable. A pull request that adds two hundred lines with no tests deserves a conversation. Set the floor low enough that it is a prompt, not a puzzle to solve.

SonarQube's documentation describes the same idea: its built-in quality gate applies conditions to new code only, so older gaps do not block today's work. That approach avoids a team gaming a global number.

A decision guide

• If coverage is under half on a critical module, treat it as a risk and plan real tests.
• If coverage is high and escaped bugs are low, leave it alone.
• If coverage is high and bugs escape, audit the tests, because they are probably weak.
• If someone proposes a company wide number, ask what behavior it is supposed to protect.

Quick check

Sources

• Martin Fowler, Test Coverage
• DORA, Software delivery performance metrics
• SonarQube documentation, About new code

Last reviewed: 19 October 2026.