Live data from Hacker News

Claude Code Unpacked : A visual guide

ccunpacked.dev

321–330 of 464 posts

Re: Claude Code Unpacked : A visual guide

#321

Earlier quoted context omitted.

It screams vibe coding. This is the anthropic look. Just ask Claude and give it a screenshot.

Of course I expect it is vibe coding. It would be insane to code anything by hand these days. But that doesn't mean there is no creative input by the author here.

>> It would be insane to code anything by hand these days.

I strongly disagree, but it made me chuckle a bit, thinking about labeling software as "handmade" or marketing software house as "artisanal".

Re: Claude Code Unpacked : A visual guide

#323
post #232

Earlier quoted context omitted.

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…

The tools was mostly already known, no? (I wish they had a "present" tool which allowed to model to copy-paste from files/context/etc. showing the user some content without forcing it through the model)

Yeah in fact one thing claude is freaking great at is decompilation.

If you can download it client side you can likely place a copy in a folder and ask claude

‘decompile the app in this folder to answer further questions on how it works. As an an example first question explain what happens when a user does X’.

I do this with obscure video games where i want to a guide on how some mechanics work. Eg. https://pastes.io/jagged-all-69136 as a result of a session.

It can ruin some games but despite the possibility of hallucinations i find it waaay more reliable than random internet answers.

Works for apps too. Obfuscation doesn’t seem to stop it.

Re: Claude Code Unpacked : A visual guide

#324
post #178

Earlier quoted context omitted.

[flagged]

If writing concise architectural analysis without the fluff makes me an AI, I'll take the complement. But no - just a tired Architect who has spent way too many hours staring at broken agent state loops haha.

This reply is quite literally AI as well, and so was your initial comment. It's so so obvious after spending enough time on Twitter and seeing the pattern used by all the AI reply bots. Absolutely insane that the HN crowd isn't able to see this.

Re: Claude Code Unpacked : A visual guide

#325
post #313
post #232

Earlier quoted context omitted.

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?

It's early days and we don't fully understand LLM behavior to the extent that we can assume questions like this about agent design are resolved. For instance, is an agent smarter with Claude Code's tools or `exec_command` like Codex? And does that remain true for each subsequent model release?

Re: Claude Code Unpacked : A visual guide

#326

I know it seems counter-intuitive but are there any agent harnesses that aren’t written with AI? All these half a million LoC codebases seem insane to me when I run my business on a full-stack web application that’s like 50k lines of code and my MvP was like 10k. These are just TUIs that call a model endpoint with some shell-out commands. These things have only been around in time measured in months, half a million L…

Who cares about LoC? Its a metric that hasn't mattered since we measured productivity in it in the 1980s. For all we know they made these design choices so they could more easily reuse the code in other codebases. Ideally you'd build the library to do that at the same time, but this is start up time constraints to repay loans and shit.

"Who cares how much concrete we used in this bridge?"

Re: Claude Code Unpacked : A visual guide

#328

Earlier quoted context omitted.

I’m using pi and cc locally in a docker container connected to a local llama.cpp so the whole agentic loop is 100% offline. I had used pi and cc to analyze the unpacked cc to compare their design, architecture and implementation. I guess your site was also coded with pi and it is very impressive. Wonderful if you can do a visualization for pi vs cc as well. My local models might not be powerful enough. Thanks for the…

what level of success are you getting with a 100% offline loop (and on what hardware if you dont mind sharing)?

https://gistpreview.github.io/?30a4e491eb2df7523ecc120b86feb... (pi)

https://gist.github.com/ontouchstart/d7e3b7ec6e568164edfd482... (cc)

M5 (24G)

Re: Claude Code Unpacked : A visual guide

#329

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

Thousands of developers are using Claude Code successfully (I think?).

So what specifically is the gripe? If it works, it works right?

Re: Claude Code Unpacked : A visual guide

#330

Earlier quoted context omitted.

Who cares about LoC? Its a metric that hasn't mattered since we measured productivity in it in the 1980s. For all we know they made these design choices so they could more easily reuse the code in other codebases. Ideally you'd build the library to do that at the same time, but this is start up time constraints to repay loans and shit.

"Who cares how much concrete we used in this bridge?"

That would be a sensible comparison if concrete was free
Post reply on HN