Amount of code can be an indicator, however as soon as developers know it is being used as metric it is easy to manipulate.
It's just like shift times for workers in manual labor jobs. You can't tell which of the people who are meeting up 8 hours a day is most productive based on if they where there for 8 hours and 12 minutes or 8 hours and 25 minutes. But you sure as hell can easily see that if someone is showing up 4-5 hours on a nine-to-five job, then something is wrong. And if that person tries to "fake it" but showing up for 8 hours but spends half the time slacking off, but coworkers and managers will call him on the bullshit.
And when I then do actual work in between I lean towards the solution giving me more lines. Longer variable names, more line breaks, ...
There are so many ways to manipulate that, one I know it's a key metric. Sure, it's hard to go from weakest to top contributor that way, but good enough to get away from last spot who is being fired. At least till all play that game. By then the project goes towards a wall.
So yes, for a one off case to identify engineers one should talk to it is a somewhat useful metric, but I would look at more business relevant metrics like amount of closed bugs or similar first (while of course they can be manipulated easily as well ...)
You just need to create a shitload of bloated bullshit that somehow "works" (at least more or less).
That doesn't make you productive.
Actually that's even counterproductive as it creates technical debt. But by the bogus metric that would be positive.
I'm still to find the place where this is true in software development.
The idea the manager would call out individuals is laughable too. Most managers barely know how to code themselves. Give it another few decades before your manager looking through commits is a standard, you're more likely to see alert tools be prevalent before that.