Unit tests do not correlate to quality, and even at 100% coverage only guarantee that you've looked at every line of code twice (usually). Not only that, a lot of projects skip adding testing until well after a proof of concept is working... why? because we don't want to not ship features for two weeks while we backport in tests... Now you have less than optimal code and less than optimal tests.

This persists, every suggestion to refactor structure rebuffed, and this persists until the code debt is so high, it takes 4-5x as long to add a feature as it should. Where, if you're lucky, you can make a new version using only 3-5 year old technology, instead of the decade old stuff you've been supporting for half a decade. Even then the 2-5yo stuff isn't as nice as it was sold, but it's "enforced" by the company powers that be (god I hate angular sometimes).

While I wouldn't suggest that, I will say spending more time manipulating my code to work with the automated unit testing tool of the month has definitely lead to an occasional decrease in code reliability. Not all code can be unit tested [with every unit testing library], and being compelled to shape everything such that it works with all once and future automated tools often makes the mess worse.

I do think sometimes about TDD as Think less driven development. The problem is not that much in TDD itself, but how its usually implemented - as a safety net and excuse for producing all kinds of bad code.

That's what happens when you rely too much on something unreliable.