Nice presentation. The reality is there is nothing really special about the claude code harness?
Claude Code Unpacked : A visual guide
121–130 of 464 posts
Re: Claude Code Unpacked : A visual guide
#122nice example: Find all TODO
spin the AI machine
i do shift ctrl F
Re: Claude Code Unpacked : A visual guide
#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?
Re: Claude Code Unpacked : A visual guide
#124This is AI slop. First command I looked at: /stickers: Displays earned achievement stickers for milestones like first commit, 100 tool calls, or marathon sessions. Stickers are stored in the user profile and rendered as ASCII art in the terminal. That is not what it does at all - it takes you to a stickermule website. What is the motivation for someone to put out junk like this?
Why is it that some people feel entitled to take this kind of tone as soon as AI is used?
It's inappropriate to label a free side project 'junk' or 'slop' even if it contains major errors.
Particularly when there's a disclaimer about possible inaccuracies on the page.
Re: Claude Code Unpacked : A visual guide
#125There's this weird thing about AI generated content where it has the perfect presentation but conveys very little. For example the whole animation on this website, what does it say beyond that you make a request to backend and get a response that may have some tool call?
[flagged]
Re: Claude Code Unpacked : A visual guide
#126why do people care so much? it's just an agentic loop
Many people seem to believe the Claude Code has some sort of secret sauce in the agent itself for some reason.
I have no idea why because in my experience Claude Code and the same models inside of Cursor behave almost identically. I think all the secret sauce is in the RLHF.
Re: Claude Code Unpacked : A visual guide
#127Earlier quoted context omitted.
I've heard somewhere that they have roughly 100% code churn every few months, so yes, they unfortunately don't care about code quality. It's a shame, because it's still the best coding agent, in my experience.
> they unfortunately don't care about code quality. > It's a shame, because it's still the best coding agent, in my experience. If it is the best, and if it delivers the value users are asking for, then why would they have an incentive to make further $$$ investments to make it of a "higher" quality if the value this difference could make is not substantial or hurts the ROI? On many projects I found this "higher qual…
Is this why they ran into a bug with people hitting usage limits even on very short sessions and had to cease all communications for over a day after a week of gaslighting users because they couldn't find the root cause in the "quality doesn't matter" code base?
Or that's why tgey had to buy bun with actual engineers to work on Claude Code to reduce memory peaks from 68 GB (yes, 68 gigabytes) to a "measely" 1.7? Because code quality doesn't matter?
Or that a year later they still cannot figure out how to render anything in the terminal without flickering?
The only reason people use Claude Code is because it's the only way to use Anthropic's heavily subsidized subscription. You get banned if you use it through other, better, tools.
Re: Claude Code Unpacked : A visual guide
#128I guess they really do eat their own dogfood and vibe code their way through it without care for technical debt? In a way, it’s a good challenge, but it’s fairly painful to watch the current state of the project (which is about a year old now, so it should be in prime shape).
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; it presumes that at some point I'll give up with the LLM and be left with a mess to clean up by hand, but that's not going to happen, future maintenance is to be left to LLMs and if that isn't possible for some reason then the project is as good as dead anyway. When you start a project with a LLM the plan should be to see it through with LLMs, planning to have unaided humans take over maintenance at some point is a mistake.
Re: Claude Code Unpacked : A visual guide
#129> 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?
How many LoC should it be, for that kind of program?
Re: Claude Code Unpacked : A visual guide
#130> 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 don't know if you're mindlessly repeating the HN trope that JS/typescript/Electron is bad and that all bloat can easily prevented, but if you're truly interested in answers to your questions: RTFA.