The problem is that OP is dealing with work where design is the hard problem. They need to do prototyping without considering all of the faults of their progra

The problem is that OP is dealing with work where design is the hard problem. They need to do prototyping without considering all of the faults of their programming language, all of the concurrency bugs they could make, and all of the logical errors they could make. TDD falls apart here because TDD helps you write code that does what you think it does. When you don't even know whether it's possible to implement what you want to implement, TDD doesn't help. I think the TDD model of implementation is a lot better than most sloppy dev workflows I've seen, but I agree with OP that small commits don't work out in this case. When you aren't sure whether something is possible, you need to stay less detail-oriented. To do so, you switch from TDD mode to prototyping mode. Personally, I have so little faith in my prototype code that I always rewrite it.