[lysecret]

Because we are incapable of measuring developer productivity.

[arzke]

We're incapable of putting an accurate, standardized value on developer productivity, yet there often seems to be consensus between senior engineers on who are the high performers and the low performers. I certainly can tell this about the people I work with.

[kqr]

We are definitely not. Point at a problem, and measure the cost of solving it. That's developer productivity.

We only avoid doing it at scale because it's expensive. In particular if we want the measurement to generalise out of sample.

(In particular in this case, where once we're done, proponents will claim our data is too old to be a useful guide to tomorrow.)

[xigoi]

> Point at a problem, and measure the cost of solving it.

The problem with this is that AI will create worse code that is going to cause more problems in the future, but the measurements won’t take that into account.

[kqr]

The measurements should take that into account, yes. (There are ways to estimate this.)

[Thunderer]

Measure or estimate? What ways? Honest question, because virtually all AI discussions _convieniently_ become vague a few steps short of actually answering the question.

[actionfromafar]

Yes.

If we could even measure teams, against themselves, others and some kind of baseline, but we don't AFAIK.

[blitzar]

Lines of code pushed ... obviously /s

Unironically, ai evaluating the impact of those lines might be getting close to a metric that would measure output better than having everyone print out their last 6 months of work for the new boss to look at.

[PunchyHamster]

Or it might be horribly bad at it, as near every other problem people claim "AI might be good at it"