This has always been my experience with TDD, at least if you always leave yourself a failing test when you go. A lot more labor-intensive, since you are essentially writing the "compiler" as you go, but a similar effect.
You're still free to quickly sketch out ideas without worrying about type checking, but you can solidify things by just adding /* @flow */ to the top of a file and fixing the errors.
I haven't actually tried Elm though, so maybe a "middle-ground" isn't necessary.
(nit: dynamically typed != no types)
However, if not, you'll still have a list of compiler errors you have to fix to make the rest of the program work. This alone lets me refactor with confidence, much more so than every dynamic language I've ever used.
Agreed. I can prototype an idea almost entirely in types, and if the types make sense, then the implementation often follows naturally.
That's a terrible work flow though. Quickly sketching out ideas is so much easier with types. So much so that you do that with just types, you don't even need to write the code. Then once you've worked your intuition into something that could actually work, you fill in the code.