Except I've seen too many spaghetti code craps in production to actually recommend this. There is a plethora of reasons why colleagues (or even you) will end up not waiting until code is production ready (e.g.: A new nice task comes in which you'd rather work on, you get reassigned, you get sick and someone else has to finish, you get a great opportunity to show off and say "hey I'm already done no problem", a tester sees and tests the features and misinforms the customer, etc. etc.) I am not saying your code needs to be perfect and then you only notice the one great flaw which requires re-engineering after weeks of hard work. I am saying find a good (backed by TDD) middle ground of fast work and fitting into existing / designing a decent architecture.
My 2 cents only, and if you can make it work that's great. But I will never go ahead and recommend this to juniors or even younger seniors.
As someone who otherwise works somewhat similar to OPs workflow, I have to agree.
One golden rule for me:
The "vomit draft" version cannot be your MVP. It is never Viable for production.
That said, TDD (with emphasis on driven) is no silver bullet either, especially when working that way - the tests are equally affected and I've seen enouph code bases where the initial test surface was so off compared to what was needed/sensible that it ended up being solely a hindrance and stifling to actual rework/refactor - with people ending up throwing it away and rewriting the tests from scratch, or worst case, simply setting them to be ignored on build.
My 2 cents only, and if you can make it work that's great. But I will never go ahead and recommend this to juniors or even younger seniors.