HN

Comments (49)

• Menu

  Akranazon
  The author partially acknowledges this later on, but lines of code is actually quite of useful metric. The only mistake is that people have it flipped. Lines of code are bad, and you should target fewer lines of code (except at the expense of other considerations). I regularly track LoC, because if it goes up more than I predicted, I probably did something wrong.> Bill Gates compared measuring programming progress by lines of code to measuring aircraft building progress by weightAircraft weight is also a very useful metric - aircraft weight is also bad. But we do measure this!
• Menu

  crazygringo
  I think the author is missing a key distinction.Before, lines of code was (mis)used to try to measure individual developer productivity. And there was the collective realization that this fails, because good refactoring can reduce LoC, a better design may use less lines, etc.But LoC never went away, for example, for estimating the overall level of complexity of a project. There's generally a valid distinction between an app that has 1K, 10K, 100K, or 1M lines of code.Now, the author is describing LoC as a metric for determining the proportion of AI-generated code in a codebase. And just like estimating overall project complexity, there doesn't seem to be anything inherently problematic about this. It seems good to understand whether 5% or 50% of your code is written using AI, because that has gigantic implications for how the project is managed, particularly from a quality perspective.Yes, as the author explains, if the AI code is more repetitive and needs refactoring, then the AI proportion will seem overly high in terms of how much functionality the AI proportion contributes. But at the same time, it's entirely accurate in terms of how this is possibly a larger surface for bugs, exploits, etc.And when the author talks about big tech companies bragging about the high percentage of LoC being generated with AI... who cares? It's obviously just for press. I would assume (hope) that code review practices haven't changed inside of Microsoft or Google. The point is, I don't see these numbers as being "targets" in the way that LoC once were for individual developer productivity... there's more just a description of how useful these tools are becoming, and a vanity metric for companies signaling to investors that they're using new tools efficiently.
• Menu

  prepend
  This reminds me out the outsourcing craze of the 00s when my employer wanted 80% of code written by our Indian partner. And they measured it by lines of code.Quite a bit of my time was spend rewriting the massive amounts of garbage churned out by offshore partners.Management stuck to their goal, so the compromise was to not delete offshore lines, but to comment them out.Lines of code is a dumb metric and anyone touting them for anything meaningful is disconnected from reality. Bad that all these ceos are touting it, but they kind of always use these dumb metrics.
• Menu

  ziml77
  I've noticed that it's super easy to end up with tons of extra lines of code when using AI. It will write code that's already available (whether that's in external libraries, internal libraries, or code already the same project). I don't mind trying to keep dependencies down, but I also don't want every project to have its own poorly tested CSV parser.It also also often fails to clean up after itself. When you remove a feature (one that you may not have even explicitly asked for) it will sometimes just leave behind the unused code. This is really annoying when reviewing and you realize one of the files you read through is referenced nowhere.You have to keep a close eye out to prevent bloat from these issues.
• Menu

  countWSS
  The code written by AI in most cases is throwaway code to be improved/refined later. Its likely to be large, verbose and bloated. The design of some agents have "simplify/refactor" as final step to remedy this, but typically your average vibe coder will be satisfied that the code just compiles/passes the minimal tests. Lines of code are easy to grow. If you refine the AI code with iterative back-and-forth questions, the AI can be forced to write much more compact or elegant version in principle, but you can't apply this to most large systems without breaking something, as AI doesn't have context of what is actually changing: so e.g. an isolated function can be improved easily, but AI can't handle when complexity of abstraction stacks and interfacing multiple systems, typically because it confuses states where global context is altered.
• MyHonestOpinon
  It reminds me. When I had my consulting company 20 years ago, I defined these "metrics" to decide if a project was successful.- Is the client happy? - Are the team members growing(as in learning)? - Were we able to make a profit?Everything else was less relevant. For example: Why do I care that the project took bit longer, if at the end the client was happy with the result, and we can continue the relationship with new projects. It frees you from the cruelty of dates that are often set arbitrary.So perhaps we should evaluate AI coding tools the same. If we can deliver successful projects in a sustainable way, then we are good.
• monksy
  Even in AI based development this makes no sense. I can write an agent loop that will simiplify and enhance reusability that is more effective than having tons and tons of lines of code.The LOC as a KPI is useless and people should humiliate Elon over that. (Paraphrasing Linus on that comment and adding support).
• Menu

  viktorcode
  LoC is a good code quality metric, only it has to be inverted. Not "it wrote C compiler in 100 000 lines of code", but "in just 2000 lines of code". Now that is impressive and deserves praise.
• CuriouslyC
  Lines of code changed are a very bad measure for humans because they can be gamed. It's an ok measure for "work done" with AI if you're don't prompt the model to game it. It's useful because it's quick to calculate and concrete, but if you use it as more than a proxy it'll bite you.
• skeeter2020
  Forget about if LoC is (or ever was) a meaningful metric; in a world where humans - and now AI - essentially wires up massive amounts of existing functionality with relatively little glue code I don't even know how to measure it.
• Menu

  elischleifer
  Detection of copy-pasta is interesting - what it's calling out is not a deficiency in LLM's to code but in agentic rules in place that should just remind the agent to refactor into a common function when appropriate.
• layer8
  This is kind of an aside, but nowadays we could at least be counting (lexer) tokens of code instead of lines of code. Or even number of AST edges.
• Menu

  _dwt
  This (LOC is an anti-metric, Goodhart's Law, etc.) is true, but I'm reaching the point of "fuck nuance" when I see so many articles superficially critical of AI which contain things like this:> If AI-generated code introduces defects at a higher rate, you need more review, not less AI.I think that is very much up for debate despite being so frequently asserted without evidence! This strikes me as the same argument as we see about self-driving cars: they don't have to be perfect, because there is (or we can regulate that there must be) a human in the loop. However, we have research and (sometimes fatal) experience from other fields (aviation comes to mind) about "automation complacency" - the human mind just seems to resist thoroughly scrutinizing automation which is usually right.
• ptdorf
  I should change my linkedin to vibe coder fixer
• martythemaniak
  I do think that "yo, look at my pumping out 10kloc/day" brags are quite stupid, because it simply does not take that many lines of code to support a large, profitable product. I'd love to hear other people's experiences here, but I'd say that a product with 100K-500K LOC can support a profitable company of dozens of people and generate tens of millions of revenue.Now 100kloc is roughly 1M tokens, which cost a few dollars, so how could something that costs single digit dollars possibly be worth tens of millions in value? Clearly there's a substantial gap between how useful different pieces of code are, so bragging about how much of it you produce without telling me how valuable it is is useless. I guess it's a long-winded way of saying "show me the money"
• j45
  Lines of code not written to achieve result can be an important metric too.Focusing on capabilities instead of shipping code also can provide a better measure.
• anon
  undefined
• Menu

  dimgl
  I was enjoying the article, and then the author hit me with one of these:> AI didn't just repeat the mistake. It broke the mistake open.Come on bruh
• Menu

  kittikitti
  When I was just beginning, all of the productivity measures would be 0 and I felt like a failure. The most attainable was lines of code. Currently, it's not a great measure of productivity as I'm achieving more advanced tasks. I've heard so many opinions about how LOC isn't a great measure and then the same people get to trample on all of the work I've done out of spite because I've written more code than them. I think LOC is great because productivity measures are for beginners and people who don't understand code. The audience doesn't know the difference between writing a hundred or thousands of lines of code, both are trophies for them.These metrics for advanced roles are not applicable, no matter what you come up with. But even lines of code are good enough to see progress from a blank slate. Every developer or advanced AI agent must be judged on a case by case basis.