The guidelines I follow for C# has "use var where it's obvious, but explicitly type when not".

So for example I'd write:

  var x = new List<Foo>();

  List<Foo> x = new List<Foo>();

Whereas I'd write:

  List<Foo> x = FooBarService.GetMyThings();

Although with newer language features you can also write:

  List<Foo> x = new();

I came to like auto over the years, although I also use it sparingly. Sometimes the concrete types only add visual noise and not much helpful information, e.g. iterators:

auto it = some_container.begin();

Not even once have I wished to know the actual type of the iterator.

It’s extremely convenient for certain things. For example, let’s say I’m referring to an enum constant field of a deeply-nested type. This can easily be expressed as “auto k = a.b.c.d.kind” instead of “Alpha::Bet::Charlie::Delta::Kinds k = a.b.c.d.kind”. It should be used sparingly in local contexts where the meaning cannot be confusing.

That is like saying that one rather make fire with sticks and stones than with a lighter, because otherwise one would be lost when going out camping.

IDEs are an invention from the late 1970's, early 1980's.

auto has a good perk, it prevents uninitialized values (Which is a source of bugs).

For example:

auto a;

will always fail to compile not matter what flags.

int a;

is valid.

Also it prevents implicit type conversions, what you get as type on auto is the type you put at the right.

That's good.

Maybe an in-between solution could be a tool that substitutes auto in your code.

Odd, it's not a problem in dynamically typed languages or languages like Kotlin, Swift, etc. I think it's more just what you're used to.