> TDD is a bit like waterfall, in the sense that you're assuming you know what the code needs to do before you write it

Very true; but there are cases where you actually have that knowledge. If you are asked to port some application to another framework or language, and have tests, I'd highly recommend you use them.

I have been refactoring an ETL pipeline (to offer extensible, more flexible behavior) that sort of grew out of interns applying ad hoc transient business rules. No tests were present but I had a quite large coverage over past inputs that were yielding a correct output. I'd say code size shrank about 70%.