Write tests for the weakest coverage first

A team used Claude to add tests for a coverage backlog, but the new suite slowed CI and included code meant to be replaced.

Done with Claude· Intermediate· Nov 2026

What they did
The team asked Claude to generate broad test coverage for parts of their codebase with the lowest coverage. After the new tests were merged into develop, they saw the suite become slower and more fragile, and someone traced the issue to the generated tests.
How it went
Their full test run usually took 30 to 40 minutes, but it could stretch past an hour and still fail. Claude also added tests for disabled features that were slated for a rewrite, so the effort only partly helped.
Tips
Be explicit about what should be left out, especially disabled code and features behind flags. Also set a clear limit on how much load the new tests can put on CI so “exhaustive” does not turn into slow, brittle coverage.

Try it yourself with Claude

In my repo at [path or repo name], review [module or directory] and pick the files with the lowest test coverage. Write tests in [test framework] for [number] files at a time, but skip anything disabled, behind flags, or already scheduled for replacement; check [config file, flag list, or docs] before you start. Keep the tests light enough for a small CI node by avoiding expensive fixtures, long loops, and other heavy setup. After each batch, run the tests locally, report the coverage change, and pause for my approval before you move on or make any change that would delete, submit, or replace existing work.

Fill in the [brackets]. Agents can make mistakes, so review anything before it is sent, paid or deleted.

Read the original on news.ycombinator.com ↗

Get 3 agent uses like this every morning

With the day's top AI news. Free, and one click to unsubscribe.