Coverage is a signal, not the goal
Coverage tells you which lines and branches ran during tests. It does not tell you whether those tests check anything. A codebase can reach a high percentage with assertions that never fail.
It is still a useful signal. Uncovered code is definitely untested, and a coverage map is the most direct way to find risk nobody has looked at. The right aim is covering the code that matters, with tests that would catch a regression.
That framing changes how to use an agent. The instruction is not to reach a number. It is to add meaningful tests where risk is high and coverage is low, and to report what was measured.
Start from a real baseline
Any coverage project needs a starting number that came from actually running the suite. Estimates from reading code are not coverage. If the test runner is missing, the command fails or no tests are collected, the honest result is that the baseline is unavailable, with the reason.
The same rule applies afterwards. Improvement is the difference between two measurements on known commits. Coverage from several branches cannot be added together, since they overlap in ways that are not computable without running the merged result.
- Measure with the project's own coverage tool
- Record the commit each measurement was taken on
- Report unavailable measurements as unavailable
- Measure the combined effect on the default branch after merging
Target risk, then guard the process
Not all uncovered code deserves the same effort. A reasonable ranking weighs how risky a file is, how little of it is covered and how large it is. Risk can be approximated from signals such as size, how many other modules depend on it, error-handling density and security-sensitive names. These are heuristics and should be labelled as such.
Then guard against gaming. The quick ways to raise a coverage number are excluding files, adding ignore markers, loosening configuration thresholds and deleting failing tests. A coverage workflow has to block all of them mechanically, because an agent optimizing for a target will find them.
Keep people in the loop at two points: approving the plan before credits are spent, and approving each pull request before it merges.
How PWR Test Coverage Autopilot works
Autopilot runs in stages. Analysis maps languages, frameworks, existing tests and coverage tooling, and flags high-risk components by heuristic. A baseline job then runs the coverage command in a sandbox and parses the report. A percentage is shown only when it came from a parsed report.
The strategy stage ranks under-covered files and proposes one task per file, each with targets, a rationale, a credit estimate and a scope limited to test files. A model may reorder or drop tasks. It cannot widen a scope, add files or introduce numbers.
You approve the tasks you want and set a budget. Each task produces a tests-only pull request through the normal workflow, protected by the pre-push guard. Each branch is then measured at its head and compared with the baseline. The combined figure is measured on the default branch after merges. Current reach: Python with pytest is verified end to end. Node and .NET have commands and report parsers in beta. Go is detected but not measured. Continuous threshold checks on pull requests are upcoming.