I see where you're coming from but I think it depends on what you're building and depends on the nature of the project you're working on.

If you get the most one of the most front end developers out there and ask them to build you a React app, I would be surprised if they start writing out the UI tests first before creating the components.

I agree with what you say that when tests feel brittle is because the project hasn't been constructed well architecturally. In my experience, when a legacy project has been passed down from another company for me to work on, they are usually constructed like this. The best thing to do would be to re-write the whole project but time (and desire) rarely permits for that level of optimisation.

I guess the TL:DR of my article is that when you create a piece of software, especially a greenfield one there are a lot of unknowns. Something you think will be easy could be complex and vice versa. You don't know what parts will add value to the user. I think it would make sense to reduce the unknowns quickly by building the product quickly and getting an alpha version into the hands of users quickly to figure these things out. Once you have a clearer idea of the product, you can then go-back and re-write parts of it if necessary for stability and performance. Although I'm not a fan of TDD if you are, that re-write stage could involve that technique.

I hope that makes sense. Also I'd just like to say I really value your input on my articles. You're a highly intelligent engineer and your responses always make me think. I appreciate the tone of your responses and I'm always happy to be proven wrong so please don't stop challenging me and other developers for that matter. Happy to share my details (e-mail, Linkedin) if you want to communicate outside of Medium.