> Everything you think you know will change in the exploratory phase of a new project as you code, and you’ll strain your sanity by rewriting tests over and ov

> Everything you think you know will change in the exploratory phase of a new project as you code, and you’ll strain your sanity by rewriting tests over and over again. This seems to assume that rewriting your tests is slower than rewriting your implementation which has no tests. But if you keep things bite sized, and the logging you collect from tests is good enough, it's often faster to change a test or a type and have an LLM rewrite the relevant part of the implementation. Also, I think we have this bias where we get so excited about the implementation that's blossoming in our mind that we forget to check really important stuff before writing that implementation. A bias towards rationalism and away from empiricism, or perhaps towards our own aesthetic leanings and away from those of our peers. I like writing a few tests first (even before the types or frameworks they're made of even exist) because it puts me in the caller's mindset. With those few tests to guide me, I can then let myself have a lot of fun building something with the callee's mindset, and tests will hold me back when I've gotten too creative for the caller's needs. If I try to just build it without those rails, I end up with something really interesting and not very useful.