Test Driven Development has nothing to do with the ‘testing’ aspect of software but the ‘development’ of it. As opposed to tests you’re actually writing ‘specifications’ or ‘scaffolds’ around what the code you’re about to write should do. The TDD practise is useful to safeguard the developer from human error when delivering business value by either going off on a tangent along with introducing unintentional behaviour along with learning the language and domain. Once you’ve completed development you can just delete these ‘specifications/scaffolds’ and create dedicated tests around business value in the form of unit/integration/e2e whilst keeping in mind the testing pyramid and business value of these tests.
There shouldn’t be any coupling when practising TDD.