There's a lot of conflating unit-testing/TDD and QA here.
Yes, when you start writing code, it may not be well defined, or you (the coder) may not understand the requirement as intended. That's OK.
Write your test. Make clear your assumptions and write the code against that. Now your code is easier to refactor and acts as living documentation of how you understood the requirement. It also acts to help other engineers not break your code when they "improve" it.
If QA, the client or God himself decides the code needs to change later, for whatever reason, well that's OK too.
Unless you need to change the design of the interface in any way -- then it's harder. Tests lock a particular interface in place -- which is great if you have a well defined interface. But if you're trying to figure out that interface then you've prematurely locked yourself in.
In my opinion, a lot tech debt comes from not changing the interfaces when they need to be changed. Tests fix your design so if your design is broken you're going to live with that.
But when I'm developing something new, I will frequently change the interface until I get something to be what I want to it be.
Yes, when you start writing code, it may not be well defined, or you (the coder) may not understand the requirement as intended. That's OK.
Write your test. Make clear your assumptions and write the code against that. Now your code is easier to refactor and acts as living documentation of how you understood the requirement. It also acts to help other engineers not break your code when they "improve" it.
If QA, the client or God himself decides the code needs to change later, for whatever reason, well that's OK too.