Indeed, and sometimes it's not worth to figure out, but sometimes it is. For example, if you have a piece of code that haven't changed since the beginning, and there been no bugs stemming from that code, adding tests to it is kind of futile unless you already know it has to be refactored soon.

On the other hand, if you join a existing project with almost no tests, and for the last N months, that code is responsible for introducing lots of bugs, then it's probably worth it to spend time building some testing infrastructure around the project with that part first up to be under lots of tests.

Basically, if the calculation shows that you can save more time by not having those bugs, you have some budget to spend on making the tests work well for that part.

Not OP, but this is the vibes approach I often use (and believe they're advocating for).

If it feels painful to add a new test, it's likely time (or nearly time) to make adding tests, or at least that test easier.

I've found that once it's easy to add tests, new tests often start appearing, so that first effort can be some of the most high-impact work available to me.