I think the biggest problems are with untested code. If you have tests for all your code paths then its less of an issue. If you have code paths that are not tested then it's quite easy to have typing issues in those code paths. In my experience this is a big problem with error handling and also with `with` statements since when you are using a `with` statement there is an implicit branch for every statement in the `with` block. People are probably not going to be writing a test for every single statement short-circuiting a `with` block and its likely to be the `error` path so it's quite easy for something with the wrong type to escape the `with` block.

I also think there is this trap of using unnamed tuples and unnamed maps in the code instead of Structs. I suspect this is fine for a small team and a small code base but if you have a large codebase then it makes it harder to familiarise yourself with the code quickly. Having functions where you can't easily see the types of the inputs and the outputs is not ideal, but once you work out what they are its worse when they don't have names. Of course there are `specs` for this but if you are writing `specs` then what is the point of a dynamic language. I don't really see the advantage of writing specs and not having the compiler do any checking vs writing type definitions and having the compiler check everything is sound.