I do agree that jumping into a new code base can be slightly more trickier if type inference is used, but it's a minor point compared to the benefits in my opinion.
If you cherry pick something like Vec2i, type inference doesn't look that good, but the benefits are clearer from more complex code.
The example posted is a horrible use of autocomplete.
>const int calculated = [&] { auto l = lock(); auto first = stage1(); auto second = stage2(); return combine(first, second); }()
No idea what that does. It takes 2 variables of some type and does something too them. There is some sort of lock there too. I guess.
Clearly that was an example created to demonstrate the lambda idiom, it wasnt real code
return combine( stage1(), stage2() )
The problem here is poorly written code. I shouldn't need an IDE to tell me what is going on, the code should do it.
Why don't I use an IDE to read it? No, how about why doesn't the original coder write the code for other people to read, instead of forcing me to use an entire IDE just to piece together what they're doing, like I'm some kind of code archaeologist.
I'm debugging this thing across a flaky modem line through which I'm getting an echoed terminal, I've managed to get gdb running and narrowed it down to a handful of suspicious lines of code, and the gimboid who wrote it assumed that everyone who ever looked at it would actually be using Visual Studio 20-whatever with all the plug-ins, rather than plain text a line at a time. Brilliant.