(A) management who wanted some sort of hard-number changed to line-diff sum (total lines meaningfully changed)
(B) this was still exactly as stupid "measuring how complete an airplane was by how heavy it was" and people gamed the systems until manglement stopped
(C) in some places, management still tries to do metrics like these to this day.
When your "thousands of junior devs that never sleep" also set their own prices and they make their own success metrics directly tied to how much they can charge you, are you at the bleeding edge of vibe coding or are you kind of being had?
IIRC, they focused on the programmers who had touched fewer than 10 lines of code in the past week. There’s definitely a smell that something is going wrong and should be investigated - possibly someone needs a different title (if they’re more of an architect or ops person than a programmer) or maybe a manager is wasting all their time or… maybe it’s a lazy person who needs to be exited.
That does feel like a totally reasonable thing to look at, but that also feels like a sanewashed compromise after reasonable people explained to the boss that his initial plan was very stupid
It’s like a Schrödinger's measurement, as it can provide some insight. There are lots of things you can evaluate from lines done. But they only work if you aren’t measuring lines done.
By far the best usage of AI for me has been pair programming. Go ahead and let it generate some feature but if you're not going through it and asking questions and making it second guess itself, how can you really be sure what the code does? Or you can write the tests or even functions on your own and just let it review your own code. Swap off whenever you feel like.
I rewrote a service at work this year in rust despite having zero rust experience because it was pretty easy to alternate between reading official documentation, Google searches, and asking the AI for compiler help and general idiomatic assistance. Took maybe a week longer than otherwise this way but I feel more enriched for making the effort to learn, and I think the code is pretty good too. At least it doesn't feel too different from what I'd usually write.
How do you know code is pretty good ? You have no idea about Rust in the first place!
That is exactly the trap. It might be "good" when AI is doing something similar to existing project and so it has a lot of reference, it might be total shit. But you don't know, so you can't be sure.
I tried something similar with different topics (ones I was already familiar with) and got anything from "this is great and saves a bunch of time writing stuff that's not hard but would require some research" to "the way it says it works is exact opposite and it also hallucinated a bunch.
I get where you're coming from and I don't fully disagree with the sentiment, but this isn't like I'm just asking AI to take the wheel and being happy with whatever it spits out. Like anybody learning a new language or framework for the first time, you never truly know anything for a long while of using it before you know the pitfalls and gotchas and such.
That said...
I have been doing functional programming for most of my entire career, with a lot of other strongly-typed languages on the side like TypeScript and Go. I've presented at some smaller conferences and meetups about using type systems to erase entire categories of problems from your code. I even helped lead the charge to converting one of my former teams all the way over to pure functional programming in production, which was pretty great to see and a huge paradigm shift for the team.
So, Rust borrows a lot from functional programming languages. Even if I'm learning the raw syntax, a lot of the core concepts are very familiar to me. In fact, a lot of the concepts in some ecosystem libraries in the language I work in nearly daily (Scala) are pulled directly from the rust ecosystem. Tokio is a huge influence on Cats Effect, and a lot of its core design shares similarities. While I'd never used Rust before, it did feel a bit like coming home except everybody has a weird accent.
Main thing that has been tripping me up so far is the concept of the borrow checker but that trips everyone up when they're starting. So, from the perspective of "does the code do what I want it to do", and "does the code read well to me", and "does the concurrent nature of it have the desired semantics influenced by the requirements of the service spec", I think, yeah it looks pretty good! :)
See I don't fully agree. Would you say writing a book is easier than reading a book? Similar with code. When you're writing code, you have to be fully sure of your intent and are constantly correcting mistakes, but other things can get internalized and you won't notice them until someone else points them out. When you're reading code, I find it's a lot easier to tell when something is wrong especially if I didn't write it.
Yeah it is nice to feel like I always have a rubber duck I can talk to that actually talks back. But I'm not letting that rubber duck write the code without serious and time consuming code review and edits.
For example - the quantity of (relatively low tech, MVP quality) 'Liberty Ships' the US was able to produce outpaced Germany's pace of sinking them. The details of the effects can be argued, but it was a significant impact on the German blockade strategy.
There are a number of military examples where sheer numbers (with all other tech and strategy being equal) was a pretty good indication of the outcome. There are also plenty of examples where tech or strategy (etc.) allowed a much smaller force to prevail.
Another way to look at that is the "code" in that example is actually the factories that created the ships. The extent that they evolved and optimize the manufacturing techniques went a long way towards improving production and winning the war.
What I love about your example is it really highlights how code is of culturally perceived to be the output of a replicative manufacturing process, but it is actually way closer to the work of creating a manufacturing process!
Yes. Writing is not like a building a bridge. It is like making the drawing. Actually building the bridge is what the compiler does. For free. Millions of times.
You can have poor management under any governance or economic structure. There's plenty of stories of bad metrics leading to poor outcomes from those noted arch-capitalists, the Soviets
I literally did this back in 2022 for a previous company I worked at. The "rockstar" engineer before me wrote an Android-only app using a cross platform toolkit. He had left the company during my first week there. About 6 months into the job I was assigned the task of "make it work on iOS". 8 weeks later that was done and the app was running on both platforms with 98% of the same codebase. I ended up deleting at least ~40% of what he wrote.
And then we have a line limit for PRs - no more than 1000 lines of code. So i end up chopping PRs into pieces, but then I have to comment why it's incomplete so the PR review agent doesn't complain. And turn around and take those comments out 10 minutes later when the next PR comes through. ¯\_(ツ)_/¯
Hard limits always cause trouble, but smaller PRs are much easier to review, and usually large PRs can be broken up into smaller pieces. Each should be able to compile and test on its own, but does not necessarily need to be a complete feature.
man, this is the absolute dream. there is literally no better feeling in dev work than deleting a massive, bloated class and replacing it with like five lines of clean logic that actually works better. i remember my first big refactor where i nuked about 800 lines of just in case code and the app actually sped up by like 30%. it’s such a flex to turn in a PR with a negative line count, haha. honestly, we should be rewarded more for the code we delete than the code we write, fr.
This is one of those stories that never gets old. The best part is that deleting 2000 lines of dead/redundant code is genuinely more valuable than writing 2000 new ones — you're reducing surface area for bugs, improving build times, and making the codebase more readable. The fact that management couldn't see that says more about how broken "lines of code" as a metric is than anything else. Velocity ≠ value.
admalledd@reddit
As oft pointed out even in the 90s:
VirtuteECanoscenza@reddit
Well actually AI has brought this up again: all the talk about how many lines of code AI produces...
MostCredibleDude@reddit
When your "thousands of junior devs that never sleep" also set their own prices and they make their own success metrics directly tied to how much they can charge you, are you at the bleeding edge of vibe coding or are you kind of being had?
spongeloaf@reddit
The answer is yes!
Familiar-Level-261@reddit
And the whole "well the slowest part after adding AI was reviewing code by humans so we just stopped that/peddled that to AI too"
"oh where those bugs came from?"
lichlark@reddit
The evangelist at my company (actually an engineer) started actively talking about 'who has the most usage at the company' like it's a metric to hit 🙄
SanityInAnarchy@reddit
Yeah, I'd be so much happier counting lines of code instead of tokens.
Kered13@reddit
Literally getting that right now. So frustrating.
HighRelevancy@reddit
I mean, it's a crude measure. Generating 10, 100, or 1000 lines of code are really different challenges.
creepy_doll@reddit
I just remember that dilbert strip where the punchline was something along the lines of “I’m going to go write myself a new car”
Familiar-Level-261@reddit
new minivan... this afternoon
Familiar-Level-261@reddit
I dunno, the airplane metric is probably more accurate than LoC still
ElectronRotoscope@reddit
Famously: Twitter right after Elon Musk took over
ArtOfWarfare@reddit
IIRC, they focused on the programmers who had touched fewer than 10 lines of code in the past week. There’s definitely a smell that something is going wrong and should be investigated - possibly someone needs a different title (if they’re more of an architect or ops person than a programmer) or maybe a manager is wasting all their time or… maybe it’s a lazy person who needs to be exited.
ElectronRotoscope@reddit
That does feel like a totally reasonable thing to look at, but that also feels like a sanewashed compromise after reasonable people explained to the boss that his initial plan was very stupid
jl2352@reddit
It’s like a Schrödinger's measurement, as it can provide some insight. There are lots of things you can evaluate from lines done. But they only work if you aren’t measuring lines done.
platoprime@reddit
It seems like they should be smart enough to not tell us which metrics they're tracking.
gummo89@reddit
It's a nice thought, but as soon as you need to justify your decisions they're exposed...
geon@reddit
Even more important in the era of vibe coding.
Somehow people seem to have forgotten that quantity can’t make up for quality.
Sloshy42@reddit
By far the best usage of AI for me has been pair programming. Go ahead and let it generate some feature but if you're not going through it and asking questions and making it second guess itself, how can you really be sure what the code does? Or you can write the tests or even functions on your own and just let it review your own code. Swap off whenever you feel like.
I rewrote a service at work this year in rust despite having zero rust experience because it was pretty easy to alternate between reading official documentation, Google searches, and asking the AI for compiler help and general idiomatic assistance. Took maybe a week longer than otherwise this way but I feel more enriched for making the effort to learn, and I think the code is pretty good too. At least it doesn't feel too different from what I'd usually write.
Familiar-Level-261@reddit
How do you know code is pretty good ? You have no idea about Rust in the first place!
That is exactly the trap. It might be "good" when AI is doing something similar to existing project and so it has a lot of reference, it might be total shit. But you don't know, so you can't be sure.
I tried something similar with different topics (ones I was already familiar with) and got anything from "this is great and saves a bunch of time writing stuff that's not hard but would require some research" to "the way it says it works is exact opposite and it also hallucinated a bunch.
Sloshy42@reddit
I get where you're coming from and I don't fully disagree with the sentiment, but this isn't like I'm just asking AI to take the wheel and being happy with whatever it spits out. Like anybody learning a new language or framework for the first time, you never truly know anything for a long while of using it before you know the pitfalls and gotchas and such.
That said...
I have been doing functional programming for most of my entire career, with a lot of other strongly-typed languages on the side like TypeScript and Go. I've presented at some smaller conferences and meetups about using type systems to erase entire categories of problems from your code. I even helped lead the charge to converting one of my former teams all the way over to pure functional programming in production, which was pretty great to see and a huge paradigm shift for the team.
So, Rust borrows a lot from functional programming languages. Even if I'm learning the raw syntax, a lot of the core concepts are very familiar to me. In fact, a lot of the concepts in some ecosystem libraries in the language I work in nearly daily (Scala) are pulled directly from the rust ecosystem. Tokio is a huge influence on Cats Effect, and a lot of its core design shares similarities. While I'd never used Rust before, it did feel a bit like coming home except everybody has a weird accent.
Main thing that has been tripping me up so far is the concept of the borrow checker but that trips everyone up when they're starting. So, from the perspective of "does the code do what I want it to do", and "does the code read well to me", and "does the concurrent nature of it have the desired semantics influenced by the requirements of the service spec", I think, yeah it looks pretty good! :)
fumei_tokumei@reddit
I still don't really understand the point. When reading code is generally harder than writing it, why wouldn't I just write it in the first place?
Sloshy42@reddit
See I don't fully agree. Would you say writing a book is easier than reading a book? Similar with code. When you're writing code, you have to be fully sure of your intent and are constantly correcting mistakes, but other things can get internalized and you won't notice them until someone else points them out. When you're reading code, I find it's a lot easier to tell when something is wrong especially if I didn't write it.
max123246@reddit
Yeah it is nice to feel like I always have a rubber duck I can talk to that actually talks back. But I'm not letting that rubber duck write the code without serious and time consuming code review and edits.
jimmoores@reddit
But as Joseph Stalin supposedly said: "Quantity has a quality all of its own"
MVRVSE@reddit
For example - the quantity of (relatively low tech, MVP quality) 'Liberty Ships' the US was able to produce outpaced Germany's pace of sinking them. The details of the effects can be argued, but it was a significant impact on the German blockade strategy.
There are a number of military examples where sheer numbers (with all other tech and strategy being equal) was a pretty good indication of the outcome. There are also plenty of examples where tech or strategy (etc.) allowed a much smaller force to prevail.
Quantity can be useful, but context matters.
teknikly-correct@reddit
Another way to look at that is the "code" in that example is actually the factories that created the ships. The extent that they evolved and optimize the manufacturing techniques went a long way towards improving production and winning the war.
What I love about your example is it really highlights how code is of culturally perceived to be the output of a replicative manufacturing process, but it is actually way closer to the work of creating a manufacturing process!
geon@reddit
Yes. Writing is not like a building a bridge. It is like making the drawing. Actually building the bridge is what the compiler does. For free. Millions of times.
geon@reddit
If your goal is to defeat the processor by throwing massive amounts of code on it, then sure.
DarthCaine@reddit
Capitalism doesn't give a shit about quality or care
Kalium@reddit
You can have poor management under any governance or economic structure. There's plenty of stories of bad metrics leading to poor outcomes from those noted arch-capitalists, the Soviets
geon@reddit
Capitalism doesn’t NOT care either. It is irrelevant.
The issue is bad management.
Personal_Offer1551@reddit
the best code is the code you can delete. peak productivity right there.
nostril_spiders@reddit
I get what you mean, but it's precisely the other way round. If you can delete it, it was unnecessary.
Best code is code you don't have to maintain?
Familiar-Level-261@reddit
We just tell AI to write it again from scratch when requirements change /s
def-pri-pub@reddit
I literally did this back in 2022 for a previous company I worked at. The "rockstar" engineer before me wrote an Android-only app using a cross platform toolkit. He had left the company during my first week there. About 6 months into the job I was assigned the task of "make it work on iOS". 8 weeks later that was done and the app was running on both platforms with 98% of the same codebase. I ended up deleting at least ~40% of what he wrote.
Ileana_llama@reddit
my mom says is my turn to post this
LookAtYourEyes@reddit
It's my first time seeing so it so I'm happy someone has reposted it.
LandscapeMaximum5214@reddit
Same lol, someone gotta repost these things once in a while for us casual redditors
Expensive_Special120@reddit
To be fair … this is the first time that I’m seeing this, so … useful.
darcstar62@reddit
And then we have a line limit for PRs - no more than 1000 lines of code. So i end up chopping PRs into pieces, but then I have to comment why it's incomplete so the PR review agent doesn't complain. And turn around and take those comments out 10 minutes later when the next PR comes through. ¯\_(ツ)_/¯
Kered13@reddit
Hard limits always cause trouble, but smaller PRs are much easier to review, and usually large PRs can be broken up into smaller pieces. Each should be able to compile and test on its own, but does not necessarily need to be a complete feature.
darcstar62@reddit
I agree with the concept in general, but I don't believe in hard, agent-enforced limits.
Ornery-Peanut-1737@reddit
man, this is the absolute dream. there is literally no better feeling in dev work than deleting a massive, bloated class and replacing it with like five lines of clean logic that actually works better. i remember my first big refactor where i nuked about 800 lines of just in case code and the app actually sped up by like 30%. it’s such a flex to turn in a PR with a negative line count, haha. honestly, we should be rewarded more for the code we delete than the code we write, fr.
Jumpy-Baseball-4983@reddit
This is one of those stories that never gets old. The best part is that deleting 2000 lines of dead/redundant code is genuinely more valuable than writing 2000 new ones — you're reducing surface area for bugs, improving build times, and making the codebase more readable. The fact that management couldn't see that says more about how broken "lines of code" as a metric is than anything else. Velocity ≠ value.
araujoms@reddit
I'm at -2774: https://github.com/JuliaMath/DoubleFloats.jl/graphs/contributors
VictoryMotel@reddit
Negative 2000 lines of code
NOT_EVEN_THAT_GUY@reddit
Negative 2000 lines of code
2FAVictim@reddit
+1342 -3342