often when i'm fleshing out ideas or trying a new approach, i don't need everything to be consistent---just the bit i'm working on, even then i don't care too much.
What I do is I simply compile/run unit tests for a piece of the program rather than the whole thing. Then, if I decide to keep the changes, compiler errors tell me every single thing I need to fix.
In python I need to hope everything that will fail fails in unit tests.
The compiler will make sure you are returning an Int, but it has no ability to make sure it is the right Int.
Or, in more practical terms, the type system has the ability to make sure I'm returning a Reader MyConfig Int. This guarantees that a) all configuration parameters come from a single known location, b) no side effects and c) the output is an Int. But I still need unit tests to make sure the result is correct.
Ints and strings are a poor example because they have a very large domain. These features are much more useful when you're talking about more complex data structures, like the intermediate representation in a compiler. I think typechecking is most useful with complex data structures, anyway - their invariants can be built into the type.
There are other languages with the ability to constrain types to specific ranges, etc. (without having to define e.g. RInt of One | Two | Three | Four | ...), but they're still pretty obscure.
Haskell's type system only guarantees things that the type system guarantees. One thing which it does not guarantee is "does my program do what it's supposed to do". That, you need unit tests and a good design in order to feel confident about.
What I do is I simply compile/run unit tests for a piece of the program rather than the whole thing. Then, if I decide to keep the changes, compiler errors tell me every single thing I need to fix.
In python I need to hope everything that will fail fails in unit tests.