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

How Claude Code works in large codebases

claude.com

Post reply on HN
Print view View original

151–160 of 191 posts

Re: How Claude Code works in large codebases

#151

Post by Terretta »

mikepurvis wrote: post #102
sinsudo wrote: post #80

Just an anecdote: I was designing a project for LLMs onboarding and orchestration. Claude chose to read only the first 40 lines of each file. Later, in another session, looking for causes of low quality result, Claude detected the fault and changed the code to perform an AST analysis, so now the analyzer takes documentation lines and functions signature (input/output) as input. Claude's initial approach was really po…

I think it's taught to look at source code through a peephole for the sake of context preservation, but I feel like this could be a good use-case for some sub-logic or even a full sub-agent. Like, here sub-agent, you skim that file and tell me a summary, and highlight any areas related to X and Y so that I can look at them in my main context. You can also periodically observe the main work stream and interrupt me if…

> I think it's taught to look at source code through a peephole for the sake of context preservation

Yes, to a (real) fault. Less than one in fifty times it ignores an instruction or piece of data in a file has it seen the instruction or data before ignoring it. The other times, it's done this sampling nonsense.

Results are night and day using the 1M token models and reading the full files.

Re: How Claude Code works in large codebases

#152

Post by z0ltan »

bluGill wrote: post #145
sumitkumar wrote: post #71

Earlier quoted context omitted.

But the general use case is not the most efficient for a greenfield to-be fully managed by an agentic system code-base. It is built to be good around the scaffold(programming like humans) and not the actual problem space. Anthropic's target should be a codebase designed for agentic comprehension from the first commit. Here the codebase adapts to the agent. You can enforce conventions, structured metadata, semantic in…

The large majority of coding is maintenance work, not greenfield development. Even if you are doing greenfield development, it won't be long before it is maintenance.

[dead]

Re: How Claude Code works in large codebases

#153

Post by z0ltan »

DanielHB wrote: post #150
JohnMakin wrote: post #138

Earlier quoted context omitted.

The article listed explains how to avoid this. If you naively turn it loose on a big code base, yes, you’ll burn a lot of tokens while it tries to find stuff.

This is such a shame, finding where stuff is in a large codebase is my number 1 use for LLM. I hate it that it relies on grep so much, I can do grep better and faster myself.

[dead]

Re: How Claude Code works in large codebases

#154

Post by frio »

maccard wrote: post #105
MaxikCZ wrote: post #82

Earlier quoted context omitted.

This is the pain point that existed for years now and its still not solved at all. "If A, do X. Do B,C,D. Do A" - and it just never uses X because "it forgot". You just cant trust that the time you spend building rules will actually pay off, in fact you can trust that it will fail you sooner or later. RAG, Harness, Skills... all was supposed to fix this, but in reality it never had.

Harnesses do fix it IMO - it’s why Claude code and Codex had a massive jump in alleged productivity on release and then seems to have flatlined. But a custom harness _would_ allow you to do things like “on every message, run lint validation and tests”. That in and of itself would be wildly useful.

The harnesses we have are almost stunningly incomplete IMHO. I've been trying `pi` recently, and quite like that it comes with a minimal set of tools by default -- and that I can easily override or replace the ones that it ships.

I've only just started working with it, but clamping `read/write/edit` to only allow editing files in the current directory, banning `bash` and mandating I write tools for the specific commands I want it to execute, has made me much happier. Running Claude inside a VM or similar to sandbox it is nuclear overkill; I've always been surprised that that's seemed like the state of the art.

With a better harness, the model can't choose to rename things with search and replace; if it wants to rename things, it _must_ call the LSP to do it. If it's going to write code, as you suggest, the harness _forces_ linting/formatting to run.

(Reading my own comment back, I am worried that the fucking AI writing style is infecting me :()

Re: How Claude Code works in large codebases

#156

Post by coldtea »

troupo wrote: post #126
marhee wrote: post #39

Earlier quoted context omitted.

The answer is in the introduction: > Claude Code is running in production across multi-million-line monorepos, decades-old legacy systems, distributed architectures spanning dozens of repositories (…) So it is optimized for the general case, using robust tooling that works everywhere, especially when large & messy. That being said, your remark is right and for well organised smaller repo’s there’s better tooing it ca…

> So it is optimized for the general case, using robust tooling that works everywhere Where "robust tooling" is "grep with various regexes while completely missing the big picture even in small codebases"

Nothing wrong with "grep with various regexes".

And in my experience it hardly ever "misses the big picture". When it misses is small stuff I'd miss myself quite often anyway.

Re: How Claude Code works in large codebases

#157

Post by ryanschaefer »

jwilliams wrote: post #26

> Claude Code navigates a codebase the way a software engineer would: it traverses the file system, reads files, uses grep to find exactly what it needs, and follows references across the codebase. It operates locally on the developer’s machine and doesn’t require a codebase index to be built, maintained, or uploaded to a server.... > Agentic search avoids those failure modes. There's no embedding pipeline or central…

In really large codebases grep and find timeout. If you operate at that scale you quickly come to realize Claude will not use the tools you built to make searching feasible.

Re: How Claude Code works in large codebases

#158

Post by 1718627440 »

mrweasel wrote: post #129
ramraj07 wrote: post #49

Earlier quoted context omitted.

You mean like Teslas multi terabyte repo is not normal?

How did they even manage to generate a terabyte sized repo, that's crazy. Do they have something written up on how it's structured and why they'd even go that route?

A terabyte is ~220 thousand books (1000 pages, 50 rows, 100 columns) uncompressed. VCS generally store objects compressed.

Re: How Claude Code works in large codebases

#159

Post by luodaint »

As a result of shipping a working product for six months with Claude Code integrated into SaaS production, the only surviving constraints had all been less than 50 lines: migrations' generation vs execution conventions, authentication flow invariants, internationalization setup rules. Any longer constraints would get either selectively ignored or cause confusion when starting sessions.

The important distinction: CLAUDE.md will not explain how the model understands your architecture. Rather, it will prevent certain kinds of regression from happening. "Never create a user without calling the workspace provision step" is the right constraint. "This is how our entire system works" is not – the model learns it from the codebase.

The mistake is writing constraints based on an architecture constructed with slop. The sequence is important here.

Re: How Claude Code works in large codebases

#160

Post by [deleted] »

cdnsteve wrote: post #87

Small plug for what I built: You need a code dependency graph: https://github.com/roboticforce/remembrallmcp Ask "what breaks if I change this?" Saves 98% token usage. Saves 95% tools being called. Runs as an MCP server, works for 8 languages. It just works, you need to try it.

[deleted]
Post reply on HN