The Goodhart's law effect there seems obvious - rather than code getting better, you might just become less rigorous in your reviews and stop commenting as much. You may not even realize your standards are dropping.

I’m glad I’m not the only one that noticed this is madness.

I find it crazy to build a complex system to juggle 10 different threads in your brain, including the complexity of the tool itself.

Using AI we can make 1000s of commits per day. This metric becomes even more pointless in the days of AI. If we increase sales, New subscription count, reduced bug count, reduced incidents etc., those can be real metrics. I'm sure I am preaching to the choir.

What about number of working features or system completeness? Current state vs desired state is fairly visible.

No one has any idea how to estimate software value, so the idea that some courts in the US have used a wildly inaccurate system that considers LOC is so far away from evidence that LOC is useful for anything that I can’t believe you bothered including that.

LOC is essentially only useful to give a ballpark estimate it complexity and even then only if you compare orders of magnitude and only between similar program languages and ecosystems.

It’s certainly not useful for AI generated projects. Just look at OpenClaw. Last I heard it was something close to half a million lines of code.

When I was in college we had a professor senior year who was obsessed with COCOMO. He required our final group project to be 50k LOC (He also required that we print out every line and turn it in). We made it, but only because we build a generator for the UI and made sure the generator was as verbose as possible.

I think that's a "looking under the lamp post because that's where the light is" metric.

I'm not sure most developers, managers, or owners care about the calculated dollar value of their codebase. They're not trading code on an exchange. By condensing all software into a scalar, you're losing almost all important information.

I can see why it's important in court, obviously, since civil court is built around condensing everything into a scalar.

> Lines of code are meaningful when taken in aggregate

The linked article does not demonstrate this. It establishes no causal link. One can obviously bloat LOC to an arbitrary degree while maintaining feature parity. Very generously, assuming good faith participants, it might reflect a kind average human efficiency within the fixed environment of the time.

Carrying the conclusions of this study from the 80s into the LLM age is not justified scientifically.

COCOMO estimates the cost of the software, not the value. The cost is only weakly correlated with value.

> Lines of code are meaningful when taken in aggregate and useless as a metric for an individual’s contributions.

Yes, and in fact a lot of the studies that show the impact of AI on coding productivity get dismissed because they use LoC or PRs as a metric and "everyone knows LoC/PR counts is a BS metric." But the better designed of these studies specifically call this out and explicitly design their experiments to use these as aggregate metrics.

I am writing a book! I used AI to write 1 billion words this morning!

> at least as far as how courts (in the US) are concerned.

That's an anti-signal if we're being honest.

The only time metrics have been useful to me in the past is when they are kept private to each team, which is to say that I do think they are useful for measuring yourself, but not for others to measure you. Taken over time, they can eventual give you a really good idea of what you can deliver. Sandbag a bit (ie, undershoot that number), communicate that to ye olde stakeholders, and everybody's happy that you can actually do what you say you'll do without being stressed out (obviously this doesn't work in startups).

Yes. Your brain, your clear thinking and your focus are the ultimate scarce resource. Writing code is easy, but I review one large PR from a coworker, and I need a nap.

Claiming that you have "ten agents writing code at night" is not the flex you think it is. That's just a recipe for burnout and bad design decisions.

Stop running your agents and go touch grass.

Can you define what “all else” means here?

PRs or closed jira tickets can be a metric of productivity only if they add or improve the existing feature set of the product.

If a PR introduces a feature with 10 bugs in other features and I have my agent swarm fix those in 10-20 PRs in a week, my productivity and delivery have both taken a hit. If any of these features went to prod, I have lost revenue as well.

Shipping is not same as shipping correctly with minimal introduction of bugs.

Number of integration tests might be a good metric (until you announce that it is the metric then like every other metric, inc. profit, it becomes useless!)

For profit failing as a metric, see: Enron.

> All else being equal, yes, more PRs is a signal of productivity.

Yeah but all else isn’t equal, so unless you’re measuring a whole lot more than PRs it’s completely meaningless.

Even on a solo project, something as simple as I’m working with a new technology that I’m excited about is enough to drastically ramp up number of PRs.

The problem is that these caveats, while tolerable in some contexts, make the metric impossible to interpret for something like Claude Code which is (I agree!) a huge change in how most software is developed.

If you mostly get around on your feet, distance traveled in a day is a reasonable metric for how much exercise you got. It's true that it also matters how you walk and where you walk, but it would be pretty tedious to tell someone that a "3 mile run" is meaningless and they must track cardiovascular health directly. It's fine, it works OK for most purposes, not every metric has to be perfect.

But once you buy a car, the metric completely decouples, and no longer points towards your original fitness goals even a tiny bit. It's not that cars are useless, or that driving has a magic slowdown factor that just so happens to compensate for your increased distance travelled. The distance just doesn't have anything to do with the exercise except by a contingent link that's been broken.