For more than twenty years the objection to TDD was always some version of the same thing. No time. Too much typing. We will add the tests later. The assistant removes that objection. It types the test for you in seconds and it does not get bored doing it. On top of that, the path of least resistance with an assistant now runs straight through the test. I made that case in Fitness Functions for an AI Coding Assistant. To get useful work out of the assistant you have to tell it what done looks like, and a description of done that a machine can check is a test. TDD stops being the disciplined choice and becomes the efficient one.

Other developers are different. They care less about how the language works under the hood. What gets them going is the customer's problem. They want to understand what hurts and build something that makes the pain go away. The programming language is a tool. A means to an end.

You might wonder why you should still bother with tests. If the assistant can produce code that fast, surely it gets it right. That misses the point entirely. Tests were never about catching typos. They are about defining what the software should do and making sure it keeps doing it.