I've been working on my own coding agent setup for a while. I mostly use pi [0] because it's minimal and easy to extend. When the leak happened, I wanted to study how Anthropic structured things: the tool system, how the agent loop flows, A 500K line codebase is a lot to navigate, so I mapped it visually to give myself a quick reference I could come back to while adapting ideas into my own harness and workflow.

I'm actively updating the site based on feedback from this thread. If anything looks off, or you find something I missed, lmk.

[0] https://pi.dev/

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

Claude is actually a crazy good vuln researcher. If you use it that way, your code might just be more secure than written purely by hand.

But egos are involved.

The only suggestion/nit I have is that you could add some kind of asterisk or hover helper to the part when you talk about 'Anthropic's message format', as it did make me want to come here and point out how it's ackchually OpenAI's format and is very common.

Only because I figure if this was my first time learning about all this stuff I think I'd appreciate a deep dive into the format or the v1 api as one of the optional next steps.

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 hard work!

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

M5 (24G)

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; frustration regexes, context sanitizers, tool-retry loops, and state rollbacks just to stop the agent from drifting or silently breaking things.

The visual map is great, but from an architectural perspective, we're still herding cats with massive code volume instead of actually governing the agents at the system level.

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 that if, say, the source code leaks, none of the secret sauce does).

Overall, when I see this I think they are focused on the right issues, and I think their tool list looks pretty simple/elegant/general. I picture the server team constantly thinking - we have these client-side tools/APIs, how can we use them optimally? How can we get more out of them. That is where the secret sauce lives.

The core architecture is not interesting? its an LLM tui, theres not much there to discuss architecturally. The code itself is the actual fascinating train wreck to look at.

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.

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

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"

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

As I’m reading this, I’m thinking about how in 1980. It was imagined that everyone needed to learn how to program in BASIC or COBOL, and that the way computers would become ubiquitous would be that everybody would be writing program programs for them. That turned out to be a quaint and optimistic idea.

It seems like the pitch today is that every company that has a software-like need will be able to use AI to manifest that software into existence, or more generally, to manifest some kind of custom solution into existence. I don’t buy it. Coding the software has never been the true bottleneck, anyone who’s done a hackathon project knows that part can be done quickly. It’s the specifying and the maintenance that is the hard part.

To me, the only way this will actually bear the fruit it’s promising is if they can deliver essentially AGI in a box. A company will pay to rent some units of compute that they can speak to like a person and describe the needs, and it will do anything - solve any problem - a remote worker could do. IF this is delivered, indeed it does invalidate virtually all business models overnight, as whoever hits AGI will price this rental X%[1] below what it would cost to hire humans for similar work, breaking capitalism entirely.

[1] X = 80% below on day 1 as they’ll be so flush with VC cash, and they’d plan to raise the price later. Of course, society will collapse before then because of said breaking of capitalism itself.

It seems non sequitur. This hypothetical scenario sounds like entrenching capitalism, because it would concentrate capital even more.

It would probably weaken democracy and weaken free market (esp. the job market), yes.

> society will collapse before then because of said breaking of capitalism itself

Or, maybe the society would continue to exist with even more inequality? And, of course, much changed from what it is today.

You could argue that capitalism was very not broken in 1960, when you could get a job at 18 selling shoes, driving a cab, or delivering milk or whatever, and support a family of five on your salary, save for retirement, and go on yearly vacations.

It's arguably somewhat broken today, when gestures around things are like this.

I'd say it would be entirely broken if AGI means a few hundred billionaires who have ownership stakes in an AI company simply capture all the wealth in the world while most of the rest starve, but the robots help you put down the peasant uprisings and farm and raise crops for you.

I agree with you though that technically, capitalism will still be 'going strong' unless the peasants are able to overpower the AI robot billionaire industrial complex and burn it all down.

Their demo even says:

   `Paste any code or text below. Our model will produce an AI-generated, byte-for-byte identical output.`

Token echoing isn't even to the lexeme/pattern level, and not even close to WSD, Ogden's Lemma, symbol-grounding etc...

The intentionally 'Probably approximately complete' statistical learning model work, fundamentally limits reproducibility for PAC/Stastical methods like transformers.

CFG inherently ambiguity == post correspondence problem == halt == open domain frame-problem == system identification problem == symbol-grounding problem == entscheidungsproblem

The only way to get around that is to construct a grammar that isn't. It will never exist for CFGs, programs, types, etc... with arbitrary input.

I just don't see why placing a `14-billion parameter identity transformer` that just basically echos tokens is a step forward on what makes the problem hard.

Please help me understand.

edit: or click 'Start Pro Trial'

Can you expand on this?

My experience is they require excessive steering but do not “break”

Like that drunk uncle that takes half an hour and 20 000 words to tell you a 500 word story.

When we use an agent that lacks a native way to consolidate its own context, we essentially force it to generate these 10-year-old hack-filled codebases by design. We’re over-engineering the "container" (the CLI logic) to babysit a "leaky" context.

If the architecture doesn't start treating long-term memory as a first-class citizen, we’re just going to see more of these 500k-line "safety nets" masking the underlying fragility of the agents.

It's one thing to give Claude a narrow task with clear parameters, and another to watch errors or incorrect assumptions snowball as you have a more complex conversation or open-ended task.

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

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 dictates the workflow, hands the LLM a highly constrained task, and runs external validation on the output before the state is ever allowed to advance. The LLM cannot unilaterally decide a task is done.

I got so frustrated with the former while working on a complex project that I paused it to build a CLI to enforce the latter. Planning to drop a Show HN for it later today, actually.

This sounds like where lat.md[0] is headed. Only thing is it doesn't do task constraint. Generally I find the path these tools are taking interesting.

[0] https://github.com/1st1/lat.md

The key difference is the state mechanism. They use markdown; I use an AES-encrypted SQLite database.

Markdown is still just text an LLM can hallucinate over or ignore. A database behind a compiled binary acts as a physical constraint; the agent literally cannot advance a task without satisfying the cryptographic gates.

I just dropped the Show HN for it here if you want to check out the architecture: https://news.ycombinator.com/item?id=47601608

edit: Also seems like peoples replies are getting downvoted to hell and getting marked as dead and dissapear. Someone must not like your idea :-)

The filter instantly shadowbanned the Show HN post when I submitted it, which is why the link was dead for a while. Thankfully, human mods reviewed it and restored it. The link is fully live for a while now!

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

Considering what the entire system ends up being capable of, 500k lines is about 0.001% of what I would have expected something like that to require 10 years ago.

You can combine that with all the training and inference code, and at the end of the day, a system that literally writes code ends up being smaller than the LibreOffice codebase.

It boggles the mind, really.

https://github.com/badlogic/pi-mono/tree/main/packages/codin...

You really need to compare it to the model weights though. That’s the “code”.

Then you'd need to compare the education of any developer in relation to how many LOC their IDE is. That's the "code".

So yea, the analogy doesn't make a whole lot of sense.

By "just" wrapping a browser engine.

I know xkcd 1053, but come on.

Is that the case? I'm pretty sure Claude Code is one of the most massively successful pieces of software made in the last decade. I don't know how that proves your point. Will this codebase become unmanageable eventually? Maybe, but literally every agent harness out there is just copying their lead at this point.

The fact that the industry is copying a 500k-line harness is the problem. We're automating security vulnerabilities at scale because people are trying to put the guardrails inside the probabilistic code instead of strictly above it.

Standardizing on half a million lines of defensive spaghetti is a huge liability.

Again, maybe it will be. Or maybe the way we make software and what is considered good practice will completely change with this new technology. I'm betting on the latter at this point.

For starters, CC's TUI is React-based.

" Most people's mental model of Claude Code is that "it's just a TUI" but it should really be closer to "a small game engine".

For each frame our pipeline constructs a scene graph with React then -> layouts elements -> rasterizes them to a 2d screen -> diffs that against the previous screen -> finally uses the diff to generate ANSI sequences to draw

We have a ~16ms frame budget so we have roughly ~5ms to go from the React scene graph to ANSI written. "

Claude Code CLI is actually horrible: it's a full headless browser rendering that's then converted in real-time to text to show in the terminal. And that fact leaks to the user: when the model outputs ASCII, the converter shall happily convert it to Unicode (no latter than yesterday there was a TFA complaining about Unicode characters breaking Unix pipes / parsers expecting ASCII commands).

It's ultra annoying during debugging sessions (that is not when in a full agentic loop where it YOLOs a solution): you can't easily cut/paste from the CLI because the output you get is not what the model did output.

Mega, mega, mega annoying.

What should be something simple becomes a rube-goldberg machinery that, of course, fucks up something fundamental: converting the model's characters to something else is just pathetically bad.

Anyone from Anthropic reading? Get your shit together: if you keep this "headless browser rendering converted to text", at least do not fucking modify the characters.*

No tooling, no animation, no hidden features, no explanation of how things work upon clicking them.

But I'm glad to be proven wrong if you know a static analysis tool I can point to the repo and come up with comparable result.

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

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?

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

Aren't all the other products also vibe-coded? "All vibe-coded products look like this" doesn't really seem to answer the question "Why is it so damn large?"

It's a repl, that calls out to a blackbox/endpoint for data, and does basic parsing and matching of state with specific actions.

I feel the bulk of those lines should be actions that are performed. Either this is correct or this is not:

1. If the bulk of those lines implement specific and simple actions, why is it so large compared to other software that implements single actions (coreutils, etc)

2. If the actions constitute only a small part of the codebase, wtf is the rest of it doing?

> You're complaining about vibe coding while also complaining about how you "feel" about the code. Do you see the irony in that?

Where did I complain about how I feel about the actual code? I have feelings, negative ones, about the size of the code given the simple functionality it has, but I have no feelings on the code because I did not look at the code.

For comparison, it takes me less time to load Chrome and go to gemini.google.com.

Yeahhh strong disagree there, I find Codex and CC to be buggy as hell. Desktop CC is very bad and web version is nigh unusable.

I think a lot of the people prasing Claude & co are on Macs.

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

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

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?

For example, I found an implementation of a PRNG, mulberry32 [1], in one of the files. That's pretty strange considering TS and Javascript have decent PRNGs built into the language and this thing is being used as literally just a shuffle.

[1] https://github.com/AprilNEA/claude-code-source/blob/main/src...

If you search mulberry32 in the code, you'll see they use it for a deterministic random. They use your user ID to always pick the same random buddy. Just like you might use someone's user ID to always generate the same random avatar.

So that's 10 lines of code accounted for. Any other examples?

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?

This file is exactly what I'm talking about.

Take the loadInitialMessage function: It's encumbered with real world incremental requirements. You can see exactly the bolted-on conditionals where they added features like --teleport, --fork-session, etc.

The runHeadlessStreaming function is a more extreme version of that where a bunch of incremental, lateral subsystems are wired together, not an example of superfluous loc.

You don't have to explain why there might be better ways to write some code because the claim is about lines of code. It could be the case that perfectly organizing and abstracting the code would result in even more 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 "that sounds like too many loc".

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.

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

Claude Code is quite literally a wrapper around a few APIs. At one point it needed 68GB of RAM to run and requires 11ms to "lay a scene graph" to display a few hundred characters on screen. All links here: https://news.ycombinator.com/item?id=47598488

> while a 3D game just lets you shoot some bad guys, so surely the 3D game must be done in fewer loc.

Yes, most games should be done in fewer loc

As the ZMachine interpreter (V3 games at least, enough for the mentioned example), even a Game Boy used to play Pokemon Red/Blue -and Crystal/Sylver/Blue, just slightly better specs than the OG GB- can run Tristam Island with keypad based input picking both selected words from the text or letter by letter as when you name a character in an RPG. A damn Game Boy, a pocket console from 1989. Not straightly running a game, again. Emulating a simple text computer -the virtual machine- to play it. No slowdowns, no-nothing, and you can save the game (the interpreter status) in a battery backed cartridge, such as the Everdrive. Everything under... 128k.

Claude Code and the rest of 'examples' it's what happens when trade programmers call themselves 'engineers' without even a CS degree.

A cursory glance at the codebase shows that it's not just a wrapper around a few APIs.

Shouldn't interfaces be smaller than the implementation?

A GUI/client can be arbitrarily more or less complex than the things it's GUI'ing.

If it's an interface to ffmpeg, then sure, the GUI could be extremely complicated code.

But that's not what we are talking about, is it? We are talking about an interface to a chatbot that can accept and return chats, accept and return files, and run a selection of internal commands (which include invoking itself recursively).

The interface to this chatbot that has a settings entry for "personality" is still only going to map that to one of a small number of chatbot inputs. Same with basically anything else (read the skills file, etc).

I dunno... maybe 500kSloC for a fancy IRC client is the going rate, but the last time I wrote an interface to a chat client, it was barely 10k lines, not counting the lib*.so that the the program called to interact with the chatbot, with said chatbot supporting file uploads and '/' commands.

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.

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

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 vibe coding to get rid of this mess. So what's the problem? /s

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.

Not what you were referring to.

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.

It turns out that there is a tradeoff in code between velocity and quality that smart businesses consider relative to hardware cost/quality. The businesses that are outcompeting others are rarely those who have the highest quality code, but rather those that are shipping quickly at a quality level that is satisfactory for current hardware.

That worked because of rapid advancements in CPU performance. We’ve left that era.

It’s about more than performance. Code is and always has been a liability. Even with agents, you start seeing massive slowdowns with code base size.

It’s why I can nearly one shot a simple game for my kid in 20 minutes with Claude, but using it at work on our massive legacy codebase is only marginally faster than doing it by hand.

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.

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.

Because it's unmaintainable slop that they themselves don't know how to fix when something happens? https://news.ycombinator.com/item?id=47598488

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.

When a TUI requires 68 GB of RAM to run, or when they spend a week not being able to find a bug that causes multiple people to immediately run out of tokens, it's not a "them" problem.

I guess I just find it weird because all the signals are messed up so whenever I see these sorts of layouts, I feel like I'm looking at the average where I don't think "gorgeous and interesting" at all. Instead, I'm forced to think "I should be skeptical of this based on the presentation because it presents as high quality but this may be hiding someone who is not actually aware of what they're presenting in any depth" as the author may have just shoved in a prompt and let it spin.

There's actually a similarly designed website (font weights, font styles etc) here in New Zealand (https://nzoilwatch.com/) where at a glance, it might seem like some overloaded professional-backed thing but instead it's just some guy who may or may not know anything about oil at all, yet people are linking it around the place like some sort of authoritative resource.

I would have way less of an issue if people just put their names by things and disclosed their LLM usage (which again, is fine) rather than giving the potentially false impression to unequipped people that the information presented is actually as accurate and trustworthy as the polish would suggest.

I'm serious. The hype chasing clearly clearly matters. .

things like this: https://github.com/instructkr/claw-code I mean ok, serious people put in years of effort for 100 of those stars ...

it's continually wild how extremely irrelevant hard effortful careful work is.

I think that's the game. Get up, look at the headlines, figure out how you can exploit them with vibe coding, do some hyphy project and repeat.

Maybe some lobster themed bullshit between openclaw and the claudecode leak.

I'm not being a cynic here, I'm just telling you what I'm going to do tomorrow.

It's sloppy work

Does not matter. Sloppiness is unimportant

My shit's always too complicated. let's see

Personally, I don't think I will be putting any such disclaimers or disclosures on my work, unless I deem it relevant to the functionality.

Last week we I was struggling to go from vague prompt to a OMG-it's-so-nice-looking web app, I remembered that example above and then decided to create my own component library, which I did in a couple days: https://www.substrateui.dev/. I was actually super happy that I was able to accomplish that, and then I realized I wanted to better understand the content that I had vibe coded into existence. So now I'm recreating that design system step by step w/ Claude code, filling in gaps in my knowledge & learning a bit about colors, typography, CSS, blah blah blah. It's actually a lot of fun because I'm able to explore all of the concepts and learn enough to build a front end that doesn't suck & is good enough for my use case without getting stuck for days on trying to center a stupid div by hand or play whack-mole-fix-something-and-break-something-else when trying to clean up AI slop.

Content resizing, needing to juggle a speed knob to read, and the overall presentation makes it feel like Edward Tufte flavored nightmare fuel.

It's basically a slideshow which advances and presents several content areas which are intended to be read, all while advancing and resizing themselves.

Pausing and clicking through manually stepwise is also pretty obnoxious.

Would much rather just see the content all laid out at once

That just seems to be human nature unfortunately - the complainers are always louder.