TDD is very fast once you get into that flow. Consider the three rules:

1. You are not allowed to write any production code unless it is to make a failing unit test pass.
2. You are not allowed to write any more production code than is sufficient to pass the one failing unit test.
3. You are not allowed to write any more production code than is sufficient to pass the one failing unit test.

If you’re spending a lot of time planning each step ahead of time you might be doing Test First Development, but not TDD. The planning that takes place in TDD is more on the design level, but the actual coding can actually be faster because you’re making more real progress.

I’d be interested to know how you determined that you had the same number of bugs when you didn’t write unit tests? Generally, when I see bugs in code with good test coverage it’s the case that the tests were not testing behaviors but rather were tightly coupled to the code. The same assumption that went into the code went into the tests, so they end up not providing any value. Or the bugs were at the integration level and the tests were again tightly coupled.