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

161–170 of 191 posts

Re: How Claude Code works in large codebases

#161

Post by maccard »

frio wrote: post #154
maccard wrote: post #105

Earlier quoted context omitted.

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

One of the problems with tools is the permissions for them. I can either grant Claude access to this one specific python command, or free run with python to do whatever it wants, but not “you can execute the python scripts in this directory structure”.

Claude’s “api access required” approach means that I can’t even experiment with customising the harness without doubling up…

Re: How Claude Code works in large codebases

#162

Post by j_w »

nfg wrote: post #62
digitaltrees wrote: post #37

Earlier quoted context omitted.

If your codebase can’t fit on a single developer dev machine it’s too big.

Ever work on a AAA game?

Even a large AAA game should be able to be cloned to a machine. You don't need to clone history, just use --depth to specify the number of commits you want.

Obviously a 20 year git repo with all commits is going to be massive, but you don't need that locally.

Also, it seems like it would be reasonable for a AAA game to version control assets separately from code.

Re: How Claude Code works in large codebases

#165

Post by vntok »

wg0 wrote: post #144
vntok wrote: post #141

Earlier quoted context omitted.

> Are LLMs that super reliable in their output already with all the guardrails around? Well, what is your definition of "super reliable in the output", and is it a quantifiable/measurable target or just a feeling? Is it "more than humans", "more than senior developers", "almost perfect", "perfect"? > It might behave differently than specified and a human is required to validate every output carefully or else. Sure, j…

It is quantifiable thing not a feeling. Between ten thousand runs of: ``` const int MAX_COUNT = 10000; printf("I'll count up to %d", MAX_COUNT); for(int i=1; And of the following prompt: ``` You'll count to 10,000. At the start say "I'll count up to 10,000" and then for each number say "I'm now counting " and do not say anything else. Do not miss numbers in between. ``` Which one is going to produce 100% correct resu…

Well, for starters the program you wrote is wrong (very unreliable) 100% of the time (very predictable)... so you just got your answer I guess.

In any case, most -if not nearly all- of the top-100 LLM will answer your prompt with some code that does what you intended the first program to do. Only they'll actually code it properly of course.

Re: How Claude Code works in large codebases

#166

Post by [deleted] »

sumitkumar wrote: post #71
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…

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…

[deleted]

Re: How Claude Code works in large codebases

#167

Post by bicepjai »

All my stress these days comes from Claude Code not following instructions, and it’s gotten worse as my codebase has grown. Don’t get me wrong, Claude is awesome and I love it. But there’s no way I’d hire Claude Code alone to maintain or add features to my codebase. They keep adding memory entries about past mistakes, but the same issue of ignoring important instructions still happens about 90% of the time. The only way to avoid it is to babysit every job and review the hell out of the output. Claude Code is great at documentation and helping you understand a large codebase, but not at making changes that require understanding the whole thing. Example: I have a registry pattern used for different entities across the codebase — around 10 of them. Claude Code went and implemented 4 separate, independent registries for those entities, even with an explicit rule saying “use this one registry pattern.” It took half a day of shouting at Claude Code to get this simple task right, and I ended up editing it myself to save the stress and time.

Re: How Claude Code works in large codebases

#168

Post by troupo »

coldtea wrote: post #156
troupo wrote: post #126

Earlier quoted context omitted.

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

grep with regexp misses any and all context. Especially in large codebases (and if terms are somewhat generic like "account", which can find hundreds of functions).

So, on small codebases it misses "small" things like "I've tried to re-implement the same frigging component 15 times already" or "just because it says account doesn't mean it is any way shape or form related to account billing".

On larger codebases it becomes worse and worse, since there's more functionality, more code, and agent's context window gets polluted very quickly.

Re: How Claude Code works in large codebases

#169

Post by zzet »

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…

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

So many great tweaks in the small paragraph, and I found it to be wishful thinking:

> way a software engineer would

This is partially true. Yes, I'm using search for symbol, but the symbol I _remember_ in the context of a specific task. The way now CC _bruteforce_ symbols is not the same way the engineer will do. One typo and the agent may decide they have to reimplement something, and when by lack the read a file, they can easily fall into hallucinations. And it's not the way to work with a big codebase.

> uses grep to find exactly what it needs

This part I love the most. When you grep, you have to know what to grep. And when you get thousands of results, you have to check every one. When I get such an outcome, instead of brute-forcing every result, I start thinking about narrowing the output. The approach mentioned in the article sounds more like a justification of the general approach rather than a solid recommendation.

> doesn’t require a codebase index to be built

Yes, it doesn't require that, and it can work via many grep-read-grep-context-bloat, and it will, at some point, end up with the answer to the question. It's the same as a _software engineer who wasn't required to use the Claude code for implementation_, since they can implement on their own. This "doesn't require" - a wrong message to the community, explaining their decision as a ground truth, which is not.

--

Overall, their guide is honest about the organizational cost:

> An emerging role in several organizations is an agent manager: a hybrid PM/engineer function dedicated to managing the Claude Code ecosystem.

and

> Teams should expect to do a meaningful configuration review every three to six months.

And this is an accurate picture of _Claude Code at scale_ without a pre-built code intelligence layer.

They described the right direction, but the article left an aftertaste on 'We didn't manage to solve the problem, and this is our boundary.'

Re: How Claude Code works in large codebases

#170

Post by djeastm »

maccard wrote: post #112
Mashimo wrote: post #95

Earlier quoted context omitted.

That probably mostly assets, no?

My last project was about 400Gb, and probably 2M lines of C++. The days size is mostly assets but there’s still a lot of code.

>2M lines of C++

Even with a git history, wouldn't that only be maybe a few hundred MB?

Post reply on HN