I think you missed my point, which is if you don’t find it obvious that loosely coupled code is going to be easier to maintain than tightly coupled code, then there are probably a lot of things going on in your code that will prevent you from getting full benefit from your tests.

The point of writing tests (first) is actually that it makes you a far better developer than people who don’t. You have to picture in your mind what your code should produce and formally describe that in code before you write the code you are testing. And you have to have a clear understanding of your dependencies, because you have to write something that’s similar to your dependencies, but provides hooks to allow you to know if you’re interacting with them correctly. IME, most developers’ understanding of even their own code is hazy at best.

After that, yes, tests do catch bugs early, often before even the first line of code is written. There’s a lot of business value from moving detection of bugs earlier in the cycle. So maybe you catch the bugs “somehow,” but now you have a QA person involved who has to retest and close that bug (assuming no rework), which is $$$ (or your local currency).

I’m also very skeptical that the QA process does catch all the bugs good TDD does. I recently wandered into a feature that had no tests (“hey, is anyone looking for work”), and I started writing tests before adding my own code. I immediately discovered holes in our parsing logic no one had yet found, and some of the code I wrote could not have been written without tests, because no one knew how to create the data conditions to exercise it until the last couple of days in the sprint. In the end, QA asked me to stop writing tests (in the remaining code for the feature that wasn’t mine), because every time I wrote a test I found a bug. YMMV.