Static typing type checks are compile time, dynamic typing doesn't. I don't see how these two could be indistinguishable, in one you can't run the program with type errors, in the other you can.
That's not to say that there aren't quite reasonable questions about how effective the different approaches are or how easy it is to fix the error, how complete the checks are, how deep the checks go, etc. A lot of how you feel about that is going to be subjective based on the languages you use and the quality of the code you work with — Rust has an advanced type system and great developer ergonomics providing unusually helpful error messages, Python has weaker typing but also a culture about simplicity which discourages some classes of bugs, Java has a lot of mushy-typed code where people got tired of language / compiler drawbacks and came up with ways to improve ergonomics at the expense of defeating the type checker, etc.
In the second case, Python would allow the code to run but would potentially produce a runtime TypeError when it reached that point depending on exactly the code does. It might also run fine (e.g. I'm just passing that variable to json.dump()) or produce unexpected output (e.g. I'm passing that code to print() and that worked for int, and str, but then someone called it with None and I didn't want "None" in the output).
The point was that while those differ in how they're implemented, the experience can be fairly similar when you're in the middle of the code-test cycle. My example wasn't the most complicated dynamic typing scenario but it's an example of why this works pretty well: most Python code isn't highly dynamic or dynamic everywhere — typically there are a few places which might be challenging for analysis but there's also a LOT of code which only ever works with a single input type. If your IDE provides feedback on all of that code, you're going to avoid a fair number of other bugs and free up time for the hard parts.
var instance = new SomeClass();