TDD is not a tool for preventing errors, although it has that effect. It's primarily a way to use the computer to help you design. It's an attention-helper.
Here are two things you have to do when programming: start with a problem that is somewhat vaguely specified and flesh it out, and break problems down into very tiny subproblems. We all have lots of ways of doing those things: talking with another programmer, writing things down in a notebook, writing a little bit of throwaway code to flesh out an idea or convince yourself that it works.
TDD gets the computer involved in that process. You can't solve the whole problem this minute, but you can bite off a piece. Saying, "I'll write a little unit test for this" means you're not just thinking, you're really seeing how your approach works. You're getting very clear. Now suppose you find that something is hard to test. This is often a sign that it's coupled to the rest of the system in a bad way. When you have a lot of tests, you can try out new ideas very quickly and see if you've overlooked something, or quickly get an idea of how much code needs to change to accommodate the new idea.
A big benefit of TDD is that it leads you to write much simpler code than you otherwise would. I don't expect my say-so to convince you of this; it's just something you have to play with and see for yourself. Many times, I've found that something like an if statement was all I actually needed to accomplish something that looked like it was going to be hard. I found the simple way because I wrote the test first. Sometimes, the resulting code doesn't feel like "I" wrote it. It has a strangely minimalist quality.
The biggest benefit of TDD, though, is as a tool for communication within a team. When pairing, the unit tests make very clear what the current problem is. When understanding someone else's code, the unit tests make very clear how you're supposed to call some code. When you modify someone else's complex code, well, that's when you really start to value unit tests. The unit tests store knowledge of the program in a way that humans can understand and the computer can verify.
Of course TDD does not solve all problems. It's just a neat tool, which often produces simpler code than you could write "by yourself". You should know what it's for, though. It's a design helper, not a QA department. If it's not helping you design better, then you shouldn't use it.