Most small engineering teams know their test coverage is thinner than they would like. The tests that exist tend to cluster around the code that was easy to test, while the gnarly branches, the error handling, and the integration seams sit uncovered. Nobody has a spare week to fix it, so the number drifts down release after release.
A coverage sprint run with Claude Code changes the arithmetic. Instead of a developer spending days reading unfamiliar code and hand-writing assertions, Claude reads the module, proposes the missing cases, writes the tests, and runs them against the suite. Your engineers move to reviewing and steering rather than typing. This piece walks through how to run one that produces real coverage, not vanity coverage.
Why coverage stalls on small teams
Coverage does not fall because people do not care. It falls because writing tests for existing code is slow, unglamorous work that always loses to shipping the next feature. On a five-person team in Sydney or Brisbane, that trade-off plays out every single sprint.
The uncovered code is usually the hardest to understand, so it is the most expensive to test by hand.
New joiners do not know which paths matter, so they test the obvious ones and skip the risky ones.
Flaky or slow legacy tests get skipped, and the habit spreads.
Coverage tooling reports a percentage but never tells you which uncovered lines actually carry risk.
The result is a suite that looks fine on the dashboard and misses the bugs that reach production.
What a coverage sprint looks like with Claude Code
Treat it as a focused two or three day block, not an open-ended clean-up. Point Claude Code at one service or one high-risk module rather than the whole repository, and give it the coverage report as a starting map.
Map the gaps first
Run your coverage tool and hand the output to Claude Code alongside the source. Ask it to rank uncovered code by risk, not by line count. A validation function that guards a payment path matters more than a getter. Claude reads the call graph and flags the branches where an untested error case would actually hurt, so your team spends its attention where it counts.
Write, run, and verify in a loop
Once the priorities are agreed, Claude Code writes the tests, runs them, and iterates on failures without a human in the loop for each cycle. Because it executes the suite itself, it catches its own mistakes: a test that passes for the wrong reason, a mock that hides a real bug, an assertion that never runs.
It writes cases for the error branches humans skip, because it does not get bored.
It keeps test naming and structure consistent with your existing suite.
It surfaces genuine bugs the moment a test it wrote fails against real behaviour.
It leaves a short note on each test explaining what risk it covers.
Guardrails so coverage means something
A coverage number is easy to inflate and easy to trust too much. Set the rules before the sprint starts so the result holds up.
Ban assertion-free tests. Every test must check behaviour, not just call the function.
Require a failing test to prove itself: if it never fails when the code is broken, it is not a test.
Review every generated test the same way you would review a human pull request.
Track branch coverage, not just line coverage, so error paths are counted.
Claude Code will follow these rules if you write them into the prompt and the project guidance file. The discipline is yours to set; the typing is what you hand off.
The economics for an Australian team
Put rough numbers on it. A mid-level developer in Australia costs something like $120,000 a year fully loaded, or close to $65 an hour. A manual coverage push on a legacy service might take that developer three full days, around $1,560 of time, and still leave the risky branches untested because they are the tedious ones.
The same three-day block with Claude Code doing the drafting and running typically compresses to a day or so of developer review time. You spend a fraction of the hours, you cover the branches that actually carry risk, and you come out with a suite your team understands because they reviewed every line. Across a year of quarterly sprints, that difference funds a meaningful slice of a developer month.
Where to start
Pick one service that scares you a little, the one where a silent bug would cost real money or real trust. Run the coverage report, hand it to Claude Code, and give it two days with clear guardrails. You will learn more about that code in those two days than in the last six months of shipping around it.
If you want help setting up a coverage sprint or a broader Claude Code adoption plan for your team, book a short brainstorm with us and we will map it to your stack.
