Hmm, maybe it's just me, but I fail to see how this problem is an artifact of TDD.
- Write tests first:
- Write broken test
- Write correct code
- Run test, which fails
- Change code, which breaks it
- Write code first:
- Write correct code
- Write broken test
- Run test, which fails
- Change code, which breaks it
So unless you're doing something different in 2.1 than in 1.2 (like for example eyeballing the code more thoroughly or running it manually, which is a kind of "test" in itself) you'll end up with the same result, I don't see how you can fault the methodology for this.
TDD does not guarantee that you produce exclusively working code. It's just a methodology which highlights errors more quickly and makes it less likely for broken code to appear in production (and IMO also gives you a better approach at code design for free)