Depends. Is it the crazy religious TDD where you somehow are supposed to write tests before writing any code, despite the fact that you're making exploratory code? TDD works best when you have figured out what to test for, unfortunately more than once I encountered people who wanted to write tests for exploratory code, in rigid TDD like environment.
(sidenote: It's possible to do kind-of TDD with exploratory code in certain environments - essentially, you start writing code from top to bottom and fill in missing bits using debugger all the time)
I have only toyed with it on personal projects. But that is kind of a misrepresentation from what a lot of them propose. You typically will not be writing more than a part of a test, just enough to get it to fail, before writing the code.
It can work good as a built in driver to exercise the code you are trying to write as you go. It also gives you a chance to test the interfaces to the code you are making as you go for usability, because you are coding to it.
There are actually some really interesting videos demonstrating the RED/GREEN/REFACTOR cycle they propose.
That's why I mentioned "crazy religious". I've seen it got that far in real world, which warps TDD to the point where a good technique is thrown away by people disgusted with the pushed purity message.
It doesn't help that often, even otherwise good material about TDD, didn't really talk about cases like exploratory coding - working from messing around in a REPL, formalizing the code into TDD skeletons, is pretty powerful method, but isn't (wasn't?) mentioned often when I learnt the most about TDD (granted, that was 2005-2015)
(sidenote: It's possible to do kind-of TDD with exploratory code in certain environments - essentially, you start writing code from top to bottom and fill in missing bits using debugger all the time)