Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Claude Code Unpacked : A visual guide

ccunpacked.dev

Post reply on HN
Print view View original

211–220 of 464 posts

Re: Claude Code Unpacked : A visual guide

#211

Post by 59nadir »

ariwilson wrote: post #52
59nadir wrote: post #42

Earlier quoted context omitted.

I think it's good that it's out there, and I wonder why Anthropic have been keeping it closed source; clearly they can't possibly think that the CC source code is a competitive advantage...? Agents in general are easy to make, and trivial to make for yourself especially, and the result will be much better than what any of the big providers can make for you. `pi` with whatever commands/extensions you want to make for…

why do you think agents you make yourself will be better for you? integration with tooling that you prefer? your local dev setup built in? curious as i haven't gotten around to writing my own agent yet

All of the above at exactly the token cost that it requires for you.

Anything general is always going to be worse for specific use cases, and agents from these big providers are very general. They'll spend tons of tokens doing things that you might not need, including spend extra tokens on supporting MCP, etc., when you might not even need that.

Re: Claude Code Unpacked : A visual guide

#212

Post by johnisgood »

samusiam wrote: post #197
ernst_klim wrote: post #123

> 500k lines of code Isn't it a simple REPL with some tools and integrations, written in a very high level language? How the hell is it so big? Is it because it's vibecoded and LLMs strive for bloat, or is it meaningful complexity?

I just checked competitors' codebases: - Opencode (anomalyco/opencode) is about 670k LOC - Codex (openai/codex) is about 720k LOC - Gemini (google-gemini/gemini-cli) is about 570k LOC Claude Code's 500k LOC doesn't seem out of the ordinary.

All of them are really, REALLY bad.

Re: Claude Code Unpacked : A visual guide

#213

Post by mikkupikku »

blanched wrote: post #203
mikkupikku wrote: post #128

Earlier quoted context omitted.

Put yourself in their shoes; either the quality of Claude's coding continues to improve or else their business is probably doomed if it stagnates, so for them it makes sense to punt technical debt to the future when more capable versions of their models will be able to better fix it. This is why I personally don't take technical debt arguments about how LLM maintained code bases deteriorate with size/age seriously; i…

Doesn't this contradict the popular wisdom that "what's good for a human engineer is good for an LLM"? e.g. documentation, separation of concerns, organized files, DRY. I find LLMs very useful and capable, but in my experience they definitely perform worse when things are unorganized. Maintenance isn't just aesthetics, it's a direct input to correctness.

Maybe a little. I don't hold fast to that popular wisdom, e.g. I think comments are not always a net positive for LLMs. With respect to technical debt, how much debt is too much debt before it gums up the works and arrests forward progress on the software? It probably depends on the individual programmer. LLMs do seem to have a higher tolerance for technical debt than myself personally at least.

Re: Claude Code Unpacked : A visual guide

#214

Post by [deleted] »

carterschonwald wrote: post #140
ernst_klim wrote: post #123

> 500k lines of code Isn't it a simple REPL with some tools and integrations, written in a very high level language? How the hell is it so big? Is it because it's vibecoded and LLMs strive for bloat, or is it meaningful complexity?

yeah its honestly full of vibe fixes to vibe hacks with no overarching desig. . some great little empirical observations though!i think the only clever bit relative to my own designs is just tracking time since last cache ht to check ttl. idk why i hadnt thought of that, but makes perfect sense

[deleted]

Re: Claude Code Unpacked : A visual guide

#215

Post by hombre_fatal »

sarchertech wrote: post #208
hombre_fatal wrote: post #206

Earlier quoted context omitted.

I guess because you see 3D stuff in a 3D game instead of text, people assume that it must be the most complex thing in software? Or because you solve hard math problems in 3D, those functions are gonna be the most loc? It's a completely different domain, e.g. very different integration surface area and abstractions. Claude Code's source is dumped online so there's probably a more concrete analysis to be had than "tha…

It is a different domain but that wasn’t your argument. Your argument was that someone was comparing it to a POC when in fact they were comparing to a finished product. Also a AAA game (with the engine) with physics, networking, and rendering code is up there in terms of the most complex pieces of software.

They just claimed that you can build a 3D game in 500k loc, thus Claude Code shouldn't use so many loc. They/you didn't render the argument for that.

For example, without looking at the code, the superstition also works in the opposite direction: Claude Code is an interface to using AI to do any computer task while a 3D game just lets you shoot some bad guys, so surely the 3D game must be done in fewer loc. That's equally unsatisfying.

You'd have to be more concrete than "sounds like a lot".

Re: Claude Code Unpacked : A visual guide

#216

Post by mpalmer »

hombre_fatal wrote: post #171
troupo wrote: post #135

Earlier quoted context omitted.

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?

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 That said, doesn't TFA show you what they use their loc for?

Check out `print.ts` to see how "more LOC" doesn't mean "more polished"

Re: Claude Code Unpacked : A visual guide

#218

Post by nicoburns »

amangsingh wrote: post #148

A 500k line codebase for an agent CLI proves one thing: making a probabilistic LLM behave deterministically is a massive state-management nightmare. Right now, they're great for prompting simple sites/platforms but they break at large enterprise repos. If you don't have a rigid, external state machine governing the workflow, you have to brute-force reliability. That codebase bloat is likely 90% defensive programming;…

Kinda depends how much of it is vibe coded. It could easily be 5x larger than it needs to be just because the LLM felt like it if they've not been careful.

Re: Claude Code Unpacked : A visual guide

#219

Post by sumtechguy »

troupo wrote: post #158
criley2 wrote: post #146

Earlier quoted context omitted.

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.

> 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

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.

Post reply on HN