Ovid doesn't always use TDD, even for production-style programming. (That's non-exploratory programming.) He lamented that:
One problem I have with the testing world is that many "best practices" are backed up with anecdotes....
This will continue to be true until it's possible to measure the cost of creating and maintaining a piece of software throughout its lifecycle. If TDD costs me 25% of my initial development time but saves multiple day-long debugging sessions over five years, I'll stick with TDD. (I can give you plenty of anecdotes where the lack of tests cost lots of debugging time, including one amusing-only-in-retrospect semi-predicate problem where I reverted a checkin from another developer who reverted my checkin until we both realized that we had to account for all three termination conditions, and he was fixing one bug and I another.)
Of course, those studies still won't be valid until there's a way to get repeatable and condition isolated results out of the studies, but that requires turning programming into a mechanical practice devoid of all creativity and repeatable ad infinitum and unmodified in laboratory conditions.
I can only give you the best advice I have. In the past decade, I've become a much better programmer in part due to learning how to use TDD effectively. (I've also had a decade more practice, though.)