Coverage is the wrong target
A percentage tells you how much code was executed, not whether anything important is verified. Teams optimising it end up with thousands of tests asserting that getters return values, and no test covering the thing that breaks.
Automate what is expensive to get wrong
Money, permissions, data integrity, and anything irreversible. These have clear right answers and severe consequences, which is exactly the profile for automated assertions — the same logic as the never-events in an AI evaluation.
Automate what breaks repeatedly
Every bug that has occurred twice deserves a test, because it will occur a third time. A suite grown from real incidents is more valuable than one written to a coverage target.
A test suite grown from real bugs beats one grown from a coverage percentage.
Check by hand what needs judgment
Whether a page reads well, whether a flow feels right, whether an error message actually helps. Automation cannot judge these, and reading microcopy aloud finds problems no assertion will.
Some things are manual on purpose
Keyboard-only completion of your primary action, a real phone, a restore from backup. These are periodic rituals rather than continuous checks — the pre-launch list exists because they resist automation.
Speed decides whether it gets used
A suite taking twenty minutes is run rarely and eventually ignored. Fast and meaningful beats comprehensive and avoided, because the only tests that catch anything are the ones people actually run.