Hmm, maybe it's just me, but I fail to see how this problem is an artifact of TDD.

1. Write tests first:
1. Write broken test
2. Write correct code
3. Run test, which fails
4. Change code, which breaks it
2. Write code first:
1. Write correct code
2. Write broken test
3. Run test, which fails
4. 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)