I think it depends on what you're exploring, honestly. TDD comes out of the same circles as Extreme Programming, aka XP. In XP, there's something known as a sp

I think it depends on what you're exploring, honestly. TDD comes out of the same circles as Extreme Programming, aka XP. In XP, there's something known as a spike, which is basically a short-lived technical prototype. If you really don't know how to tackle something, you build a quick one to throw away. In that case, yes, definitely don't do TDD, because a goal of TDD is to build up a good test suite for production code. It's not a good match for throwaway code (assuming the team really has the discipline to throw it away.) But if I'm exploring in a way that feels less disposable to me, which happens often, then I'm happy to use TDD. E.g., if I want to try out a new way of solving a problem, or I have an idea for an architectural improvement. Then I'll use TDD to force myself to think about it from the outside in, to keep design considerations to the forefront.