I think TDD works great if you have a very clearly designed input or interface. A programming language falls under this category: here's a piece of code, make sure it compiles and returns the correct output is a perfect test. And one which you can defined beforehand and is achievable to write as a test.
However, programmers are often not in such a luxurious position. Business requirements are unclear, it is unclear what the solution even should look like, and the requirements will change over time and are changed based on the software's progress. In this case TDD only slows you down. It's also why short iteration times (i.e. agile) seem work relatively well in software development.
It's exactly the opposite. TDD was a put forward as a solution to unclear, changing business requirements. It allows you to adjust course very quickly when the business realizes its requirements were off and new set of requirements are needed.
Robert Martin has even mentioned that it's a waste of time if you have a full 100% specification available to you, or when you already know what the final solution is and simply need to implement it.
I'm not an expert on TDD, but how does TDD help in this situation?
If your requirements change, your existing tests and code become (partly) useless. This would indicate the most efficient way is the exact opposite where you test minimally until the requirements have stabilized.
The goal of TDD is not to have tests, or a huge test coverage. Those are just important side-effects. One goal, ignoring how it improves focus and divides complexity up nicely, is to make cleaner code. If your code respects the single-responsibility-principle, is not duplicated, and doesn't have dependency issues, you can adjust the requirements faster. The test suite allows you to be confident your changes to some parts of the system don't break others.
You can keep more code, not even having to touch many parts of the system. You know that by changing x, you don't also have to change w, y and z. Of course code still must change, but its vastly simpler and quicker to change.
Now, that doesn't mean you can't have those benefits without TDD, it's just much easier and clear.
Because there is only so much talking is going to do, at some point you just need to build a prototype and see if it works and how it can be improved.
If pre-planning, talking and requirements solved this problem we wouldn't see failed (software) projects and companies. As a matter of fact, extensive requirement gathering before prototyping and iterating is a good way to fail a project as at some point you're just adding new towers to your castle in the air.
Yeah, but if you're prototyping, then that shouldn't be the actual code you use. You write a prototype to test your assumptions, have the people bang on it for a bit, then throw it away. You take the lessons you've learned from that, and now you have more of a "spec" than you did before. Thus, you can write your tests.
However, programmers are often not in such a luxurious position. Business requirements are unclear, it is unclear what the solution even should look like, and the requirements will change over time and are changed based on the software's progress. In this case TDD only slows you down. It's also why short iteration times (i.e. agile) seem work relatively well in software development.