It can still feel that way. Take C++ for instance:
Foo f = fooFromElsewhere; // explicit typing (old)
auto f = fooFromElsewhere; // type inference (new)
Now what happens if we change the type of `fooFromElsewhere` from `Foo` to `Bar`? With the old way, we need to change the code to:
Bar f = fooFromElsewhere;
With type inference however, you won't need to change that line at all. And if the new type has enough in common with the old type, you may not change the code at all. It's just as strict as explicit typing, but it's arguably more flexible, and thus feels looser.
In cases where Foo and Bar are stricly incompatible, auto is fine here. In cases where Foo and Bar are similar and might cause trouble, auto shouldn't be used here.
Yeah, I was omitting a bias I have: I tend not to write class hierarchies, so my types are generally strictly incompatible. Things would be different if the code involved some big class hierarchy (as is sometimes the case, for instance in widget toolkits).