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.

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.

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.

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

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.

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.

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.

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.

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.

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.

I should change my linkedin to vibe coder fixer