There's no general rule you can follow here, because it's always going to depend on context. In my experience the kind of feedback loops you create, and the kind of safety nets you need are defined entirely by the domain, the organization, and the team culture.
Here are a few examples:
- I do a bit of work for a medium-sized dental clinic. The business manager there is really fun to work with, but has the tendency of changing his mind six times before he settles his ideas. So when he asks for a report, I don't put any effort at all into writing tests or worrying about minor bugs even, because my only goal is to flesh out in code something vaguely resembling what he asked for.
Often times, this means doing a handful of 30 minute prototypes until the requirements settle, each of which would have taken me 2 hours if I drove them via TDD. When things finally cool down, I evaluate the complexity and maintainability of the resulting code and either leave it untested, add some acceptance tests, backfill unit tes