The reversal on coverage makes sense to me. When the thing writing code can produce something that compiles and does the wrong thing, coverage stops being a vanity number and becomes a measure of how much of the output anything is actually checking. And because the same tools write tests quickly, they also write too many, which is how you get to 1,700 files of copied setup.

The rule you landed on, that a test has to fail when something real breaks, is the right filter. Removing 2,000 lines and seeing coverage go up slightly is a nice proof that a lot of those tests were checking nothing.

At Ascendra Ventures we apply a similar check at handover: for each acceptance criterion we want one test that has been shown to fail with the behaviour removed. It keeps the suite smaller and gives the client something meaningful to run after we leave.

How do you decide which tests to delete in practice? Do you mutate the code to see which tests stay green, or is it a manual review?