Following TDD is tedious. Of course there are some small, well-understood and often solved problems that just pit perfectly to the TDD way of writing code, but let's face it: There is a reason why TDD is past its prime. Barely anyone is doing it. Has anyone done it rigorously in the past? I doubt it.
There are several reasons for this. TDD forces you to think about the structure around your problem instead of focusing on your problem. As a result the original problem becomes harder, since we are not able to dedicate our full attention in finding a proper solution. Instead we have to think about test structuring and components that should probably not appear in a good solution.
A better method is "TDD as if you meant it". This could be thought of as "TDD 1.1" or "TDD revised". Here refactoring is not really optional. Instead of writing code in a separate place the test code base is (temporarily) also considered to be the "active" code base. We see patterns and we are able to decompose the problem much better. However, even that is tedious. And again, our partition is somewhat flawed only by focusing more on tests than solutions.
To arrive at a better version of TDD we need to drop some of its "rules". Instead we should place some "guidelines" that will ultimately result in better code, however, are not required to be followed. For instance starting coding directly in the tests is obviously not required, but is convenient and fast.