← Back to context

Comment by fragmede

15 days ago

How many LoC should it be, for that kind of program?

Other notable agents' LOC: Codex (Rust) ~519K, Gemini (TS) ~445K, OpenCode (TS) ~254K, Pi (TS) ~113K LOC. Pi's modular structure makes it simple to see where most of code is. Respectively core, unified API, coding agent CLI, TUI have ~3K, ~35K, ~60K, ~15K LOC. Interestingly, the just uploaded claw-code's Rust version is currently at only 28K.

edit: Claude is actually (TS) 395K. So Gemini is more bloat. Codex is arguable since is written in lower-level language.

Well FFmpeg is roughly 1500k, but it's C+Asm and it's dozens of codecs and pretty complex features. SBCL is around 500k I guess.

I'm not saying that this is necessarily too much, I'm genuinely asking if this is a bloat or if it's justified.

It's a TUI API wrapper with a few commands bolted on.

I doubt it needs to be more than 20-50kloc.

You can create a full 3D game with a custom 3D engine in 500k lines. What the hell is Claude Code doing?

  • Just check the leaked code yourself. Two biggest areas seem to be the `utils` module, which is a kitchen sink that covers a lot of functionality from sandboxing, git support, sessions, etc, and `components` module, which contains the react ui. You could certainly build a cli agent with much smaller codebase, with leaner ui code without react, but probably not with this truckload of functionality.

  • Software doesn’t end at the 20k loc proof of concept though.

    What every developer learns during their “psh i could build that” weekendware attempt is that there is infinite polish to be had, and that their 20k loc PoC was <1% of the work.

    That said, doesn't TFA show you what they use their loc for?

  • Comments like these remind me of the football spectators that shout "Even I could have scored that one" when they see a failed attempt.

    Sure. You could have. But you're not the one playing football in the Champions League.

    There were many roads that could have gotten you to the Champions League. But now you're in no position to judge the people who got there in the end and how they did it.

    Or you can, but whatever.

    • I don't think this is warranted given that the comment you're criticising is simply expressing an opinion explicitly solicited by the comment it's responding to.

    • It’s more like “Player A is better than Player B” coming from a professional player in a smaller league who is certainly qualified to have that opinion.

    • > Sure. You could have. But you're not the one playing football in the Champions League.

      The only reason people are using Claude Code is because it's the only way to use their (heavily subsidized) subscription plans. People who are okay with using and paying for their APIs often opt out for other, better, tools.

      Also, analogies don't work. As we know for a fact that Claude Code is a bloated mess that these "champions league-level engineers" can't fix. They literally talk about it themselves: https://news.ycombinator.com/item?id=47598488 (they had to bring in actual Champions League engineers from bun to fix some of their mess).

      4 replies →

    • Yes, exactly. I like this analogy. I am surprised the level of pearl clutching in these discussions on Hacker News. Everybody wants to be an attention sharecropper, lol.

  • 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.

    • 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.

      5 replies →

    • 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.

    • 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.

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