[criley2]

Honest question: Why does it matter? They got the product shipped and got millions of paying customers and totally revolutionized their business and our industry.

Engineers using LOC as a measure of quality is the inverse of managers using LOC as a measure of productivity.

[dandellion]

More code means more entropy, more room for bugs, harder to find issues, more time to fix, more attack surface, more memory used, more duplication, more inconsistencies... I bet you at some point we'll get someone reporting how AI performance deteriorates as the code base grows, and some blog post about how their team improved the success of their AI by trimming the code base down to less than 100k LOC or something like that.

The principles of good software don't suddenly vanish just because now it's a machine writing the code instead of a human, they still have to deal with the issues humans have for more than half a century. The history of programming is new developers coming up with a new paradigm, then rediscovering all the issues that the previous generation had figured out before them.

[criley2]

The history of programming is also each generation writing far less performant code than the one before it. The history of programming is each generation bemoaning the abstractions, waste and lack of performance of the code of the next generation.

It turns out that there is a tradeoff in code between velocity and quality that smart businesses consider relative to hardware cost/quality. The businesses that are outcompeting others are rarely those who have the highest quality code, but rather those that are shipping quickly at a quality level that is satisfactory for current hardware.

[sarchertech]

> far less performant code than the one before it.

That worked because of rapid advancements in CPU performance. We’ve left that era.

It’s about more than performance. Code is and always has been a liability. Even with agents, you start seeing massive slowdowns with code base size.

It’s why I can nearly one shot a simple game for my kid in 20 minutes with Claude, but using it at work on our massive legacy codebase is only marginally faster than doing it by hand.

[dandellion]

You asked why the size of the code matters, I gave you the answer. If you want to ramble about the non technical aspects of software development talk to someone else, I'm not interested.

[criley2]

I asked a rhetorical question to get the reader to think about a topic. I was not looking for a rote recitation of a well-known textbook answer. Maybe you should not be on the comment section of an engineering website if you find discussion so offensive.

[dandellion]

I'm pretty sure I can post however I want, so I'll be ignoring your suggestion. Also I didn't say I find it offensive, just that I'm not interested.

[raincole]

It doesn't. LoC is only meaningful when you use it to belittle others' code.

[ulbu]

hehe, belittle (to make smaller)

[sarchertech]

The reason it’s not useful as a measure of productivity is because it’s measure of complexity (not directly, but it’s correlated). But it tells you nothing about whether that complexity was necessary for the functionality it provides.

But given that we know the functionality of Claude Code, we can guess how much complexity should be required. We could also be wrong.

>Why does it matter?

If there’s massively more code than there needs to be that does matter to the end user because it’s harder to maintain and has more surface area for bugs and security problems. Even with agents.

[GuB-42]

Among the hundreds of thousands of lines of code that Anthropic produced was one that leaked the source code. It is likely to be a config file, not part of the Claude Code software itself, but it still something to track.

The more lines of code you have the more likely there is for one of them to be wrong and go unnoticed. It results in bugs, vulnerabilities,... and leaks.

[viktorcode]

More bugs. More costly maintenance.

[blantonl]

Exactly. Imagine if Claude Code was a PHP script. Some folks would lose their damn minds

[troupo]

> Honest question: Why does it matter?

Because it's unmaintainable slop that they themselves don't know how to fix when something happens? https://news.ycombinator.com/item?id=47598488

[sumtechguy]

It will be exactly that. But that is a 'them' problem. I can look at it a go 'that looks like a bad idea' but they are the ones who have to live with it.

At some point someone will probably take their LLM code and repoint it at the LLM and say 'hey lets refactor this so it uses less code is easier to read but does the same thing' and let it chrun.

One project I worked on I saw one engineer delete 20k lines of code one day. He replaced it with a few lines of stored procedure. That 20k lines of code was in production for years. No one wanted to do anything with it but it was a crucial part of the way the thing worked. It just takes someone going 'hey this isnt right' and sit down and fix it.

[troupo]

> But that is a 'them' problem. I

When a TUI requires 68 GB of RAM to run, or when they spend a week not being able to find a bug that causes multiple people to immediately run out of tokens, it's not a "them" problem.