The reason TDD never really caught on is because it doesn't really work. You don't know in advance what tests need to exist. A test suite is not sufficient to understand the program. Nor is a spec sufficient to understand the program. You have to read the program to understand the program. A spec is English and a test suite is like a converging upper and lower bound to an unknown value. Neither are good enough.
Also, the staff engineers who review code all day typically do not really understand the program either. They understand the spec and they have a model of how things should work such that they can answer "should" questions, but they cannot tell you what exactly is going on in the depths of the program; that's not their job. The tools are not capable right now of creating a quality program that the operator only understands at a conceptual level. Again, someone has to actually know, still.
TDD is just one of many options. Personally I rapidly have LLMs rewrite code over and over until it is super easy for me to understand and exactly what I want, and then I generate tests to prevent regressions.
Regardless, I run a security auditing company where we constantly find severe bugs in human written code proving the engineers writing it had major gaps in their understanding of their own code. And, others have found flaws like that in my own hand written code! We humans are often very blind at seeing the flaws in our own logic and AIs learned from us.
Also, as code reviewers that can spot bugs authors and AIs miss, we are often paid a lot more than the original authors for our time. Also it almost never takes as much time as writing the code in the first place which likely required many round trips with customers to establish needs and fix bugs etc.
Your claims imply that only someone that hand types every semicolon is capable of understanding the code does not hold up even in the pre AI world.
Code review was the most important job in software engineering before AI and that is still true now.