alt Hacker NewsThis is the "lines of code per week" metric from the 90s, repackaged. "I'm doing more PRs" is not evidence that AI is working, it's evidence that you are merging more. Whether thats good depends entirely on what you are merging. I use AI every day too. But treating throughput of code going to production as a success metric, without any mention of quality, bugs, or maintenance burden is exactly the kind of thinking developers used to push back on when management proposed it.
Turns out we weren't opposed to bad metrics! We were just opposed to being measured! Given the chance to pick our own, we jumped straight to the same nonsense.
Replies
And the author has a blog post about burnout and anxiety. Maybe all of those things are related.
Working to the point of making yourself sick should not be seen as a mark of pride, it is a sign that something is broken. Not necessarily the individual, maybe the system the individual is in.
Maybe author knows that too, but wants to talk about it nonetheless. First line of article: “Commits are a terrible metric for output, but they're the most visible signal I have.”
Lines of code are meaningful when taken in aggregate and useless as a metric for an individual’s contributions.
COCOMO, which considers lines of code, is generally accepted as being accurate (enough) at estimating the value of a software system, at least as far as how courts (in the US) are concerned.
> Turns out we weren't opposed to bad metrics! We were just opposed to being measured! Given the chance to pick our own, we jumped straight to the same nonsense.
This seems like a distinction without a difference, unless there actually are any good metrics (which also requires them to be objectively and reliably quantifiable). I think most developers don't really want to measure themselves, it's just that pro-AI people think measurement is necessary to put forward a convincing argument that they've improved anything.
To me commit volume and similar metrics are something that indicate ai adoption, nothing more. And for a lot of people right now that is the goal - however short or long sighted that it might be.
It’s not meaningless - it just shouldn’t be held up as the only thing. Sometimes having a couple proxies is Ok as long as you also look at value in other ways. /shrug
Multiple agents in parallel "working on different features" is where people lose me. I don't care how much friction you've eliminated from the loop, eventually that code has to be looked at. Trying to switch between 5 different feature branches and properly review the code, even with AI help, if done properly is going to eat up most of not all the productivity improvements. The only way around it is to start pencils whipping reviews.
I'm also trying everything to learn how to use Claude, everything is so new. And keep upgrading.
Of course lines of code is a meaningful metric. It's not like the author said it's the ONLY meaningful metric.
Here's the thing every discussion around this tries to weasel around: All else being equal, yes, more PRs is a signal of productivity.
It's not the only metric. But I'm more and more convinced that the people protesting any discussion of it are the ones who... don't ship a lot.
Of course it matters in what code base. What size PR. How many bugs. Maintenance burden. Complexity. All of that doesn't go away. But that doesn't disqualify the metric, it just points out it's not a one-dimensional problem.
And for a solo project, it's fairly easy to hold most of these variables relatively constant. Which means "volume went up" is a pretty meaningful signal in that context.
FWIW, I've been using AI, but instead of "max # of lines/commits", I'm optimising for "min # of pr comments/iterations/bugs". My goal is to end up with less/simpler code and more/bigger impact. The real goal is business value, and ultimately human value. Optimise for that, using AI where it fits.
Along those lines, some techniques I've been dabbling in: 1. Getting multiple agents to implement a requirement from scratch, them combining the best ideas from all of them with my own informed approach. 2. Gathering documentation (requirements, background info, glossaries, etc), targeting an Agent at it, and asking carefully selected questions for which the answers are likely useful. 3. Getting agents to review my code, abstracting review comments I agree with to a re-usable checklist of general guidelines, then using those guidelines to inform the agents in subsequent code reviews. Over time I hope this will make the code reviews increasingly well fitted to the code base and nature of the problems I work on.