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

311–320 of 464 posts

Re: Claude Code Unpacked : A visual guide

#311

Post by batshit_beaver »

tracyhenry wrote: post #304
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;…

> they break at large enterprise repos. I don't know where you get this. you should ask folks at Meta. They are probably the biggest and happiest users of CC

You mean the company where engineers ask chat bots to write chess games in their spare time in order to hit their AI usage requirements? That Meta?

Re: Claude Code Unpacked : A visual guide

#312

Post by amangsingh »

mywacaday wrote: post #228
amangsingh wrote: post #189

Earlier quoted context omitted.

Herding cats is treating the LLM's context window as your state machine. You're constantly prompt-engineering it to remember the rules, hoping it doesn't hallucinate or silently drop constraints over a long session. System-level governance means the LLM is completely stripped of orchestration rights. It becomes a stateless, untrusted function. The state lives in a rigid, external database (like SQLite). The database…

I started that very personal project on Monday, waiting with baited breath, make sure to add a sponsor me a coffee link.

Just posted it here: https://news.ycombinator.com/item?id=47601608 Thank you so much for the coffee offer, that genuinely made my day! I don't have a sponsor link set up. Honestly, the best support is just hearing if this actually helps you ship your personal project faster without losing your mind to prompt engineering. I really hope it gives you your sanity back. Let me know how it goes!

Re: Claude Code Unpacked : A visual guide

#313

Post by jayd16 »

ttcbj wrote: post #232
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;…

I find it really strange that there is so much negative commentary on the _code_, but so little commentary on the core architecture. My takeaway from looking at the tool list is that they got the fundamental architecture right - try to create a very simple and general set of tools on the client-side (e.g. read file, output rich text, etc) so that the server can innovate rapidly without revving the client (and also so…

Why are "tools" for local IO interesting and not just the only way to do it? I can't really imagine a server architecture that gets to read your local files and present them without a fat client of some kind.

What is the naive implementation you're comparing against? Ssh access to the client machine?

Re: Claude Code Unpacked : A visual guide

#314

Post by amangsingh »

fallinditch wrote: post #199
amangsingh wrote: post #189

Earlier quoted context omitted.

Herding cats is treating the LLM's context window as your state machine. You're constantly prompt-engineering it to remember the rules, hoping it doesn't hallucinate or silently drop constraints over a long session. System-level governance means the LLM is completely stripped of orchestration rights. It becomes a stateless, untrusted function. The state lives in a rigid, external database (like SQLite). The database…

Sounds good, I'll keep an eye out.

Just dropped the Show HN here: https://news.ycombinator.com/item?id=47601608. Would love to hear your thoughts on the architecture!

Re: Claude Code Unpacked : A visual guide

#317

Post by marcellus23 »

FartyMcFarter wrote: post #96
rzmmm wrote: post #62

Earlier quoted context omitted.

For the animations specifically, it's using Motion (fka Framer Motion) Javascript library. If you describe some animations from the site to an LLM and ask it to use Framer motion, you get very similar results. The creator likely just prompted for a while until they were happy with the outcome.

Is there a reason to think it was done by an LLM?

AI-generated UIs, at least ones aimed at an engineering audience, have a very distinct appearance. They seem to always have the following attributes:

- Dark mode design with lots of colors

- Buttons that have vibrant, bright borders and duller backgrounds

- Excessive (IMO) usage of monospace fonts for stylistic reasons

None of this proves that it's AI (the other comments have covered that) but in my experience it's always correct.

Re: Claude Code Unpacked : A visual guide

#318

Post by troupo »

spiderfarmer wrote: post #290
troupo wrote: post #172

Earlier quoted context omitted.

> 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…

"Even I would have scored that goal" == "I would never ever have created a bloated mess like Anthropic" You just repeat the same statement. That bloated mess is what got them to the Champions League. They did what was necessary to get them here. And they succeeded so far. But hey, according to some it can be replicated in 50k lines of wrapper code around a terminal command, so for Anthropic it's just one afternoon of…

> Even I would have scored that goal" == "I would never ever have created a bloated mess like Anthropic"

Since you keep putting words in my mouth that I never said, and keep being deliberately obtuse, this particular branch is over.

Go enjoy Win11 written by same level of champions or something.

Adieu.

Re: Claude Code Unpacked : A visual guide

#319

Post by jayd16 »

chrismarlow9 wrote: post #265
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;…

We propped the entire economy up on it. Just look at the s&p top 10. Actually even top 50 holdings. If it doesn't deliver on the promise we have bigger problems than "oh no the code is insecure". We went from "I think this will work" to "this has to work because if it doesn't we have one of those 'you owe the bank a billion dollars' situations"

It's weird to look at the world like this. If they deliver doesn't that invalidate thousands of other business plans? What about paying for that?

If they fail, doesn't software and the giant companies that make it go back to owning the world?

Re: Claude Code Unpacked : A visual guide

#320

Post by blanched »

mikkupikku wrote: post #213
blanched wrote: post #203

Earlier quoted context omitted.

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.

Good points, I've also found that comments are really hit or miss. Especially because the agents tend not to update them (sounds familiar!).
Post reply on HN