Managers have a literal orgwide leaderboard now of how many LOCs were committed by each IC. As expected, right after they started doing this, there were a lot of frivolous refactoring projects where people moved code from one repo to another repo or consolidated stuff into a common repo, just to boost their LOCs.
Even if the customer tells you they bought your product because you added widget x you can't really be sure.
So much of this stuff is emotional rather than rational.
To make personnel decisions who to fire or give bonuses it doesn’t work. Just as lines of code don’t. If any of those indicators is lacking you have to dig deeper.
What lazy managers want is a single number they don’t have to dig into to make decisions. Lines of code, story points, bug counts.
To plan work for next sprint having last 6 months of stats gives quite good idea what can be achieved. But story points or stats are not useful for telling if specific features will be developed in specific timeframe.
You definitely can measure team output over time and have some idea. Compare team to what they did in last 6 months and you have your measure for having idea how much can be achieved next month. But you cannot not plan like what can be achieved in longer period just next sprint or two.
This said you cannot compare teams like that.
I think a descent answer is a cross-factor one.
We have agile teams, that have a velocity measured in story points. This gives a first good idea but it is not the all truth. It is a very relative measurment.
but if you add informations about pure productions : Number of PR's Number of commits in PR's Number of code lines Number of comments on PR's
Then you got something more interesting.
Also, we are looking for a way to add quality indicators to understand if it is just rush, or full vibe coded code that will make project los t in few months ..
But I agree with other comments saying that it is a struggle, and AI coding just make more painful ..