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

121–130 of 191 posts

Re: How Claude Code works in large codebases

#121

Post by sumitkumar »

njovin wrote: post #44
thinkindie wrote: post #8

I don’t agree with the statement about indexing codebase: it works pretty well for IDEs like PHPstorm or other jetbrains IDEs

PHPStorm's indexing is incredible. Aside from a scant few times it's been corrupted, which is easily corrected, I've never gotten stale results. Although if you've ever used Claude's search tool, you'll be unsurprised that the team knows nothing about indexing. How a company, whose primary product is text-based chat, doesn't allow users to easily perform text search on said chat is beyond comprehension.

[dead]

Re: How Claude Code works in large codebases

#122

Post by ubercore »

svara wrote: post #118

I use Claude Code quite a bit and quite enjoy it, so I'm a bit confused by how often it's mentioned that you should have CLAUDE.md. I mean: If there was something you could add to the prompt to consistently increase performance why isn't it in the system prompt already? If it's all about clarifying a couple of local idiosyncrasies, shouldn't it be able to quickly get them by looking through the repo? Does anyone have…

The tokens it uses up clarifying can be saved, and it's often good to write out intentions. For instance, you may be mid-process on cleaning up some architectural pattern, and giving it guidance about where to find docs to follow, etc, are very project-specific.

Re: How Claude Code works in large codebases

#123

Post by sampullman »

svara wrote: post #118

I use Claude Code quite a bit and quite enjoy it, so I'm a bit confused by how often it's mentioned that you should have CLAUDE.md. I mean: If there was something you could add to the prompt to consistently increase performance why isn't it in the system prompt already? If it's all about clarifying a couple of local idiosyncrasies, shouldn't it be able to quickly get them by looking through the repo? Does anyone have…

There's a bunch of stuff I include, depending on the project. Some general ones are commenting style and coding standards. In theory it should be able to do it without that by looking at the repo style, but I haven't found that to be the case (especially with overly verbose/repetitive comments).

A specific example in another project is the testing/verification procedure. It's a wasm/WebGPU and the test harness is fairly complex. There are scripts to handle it, but by default Claude will churn for a while to figure it out and sometimes just give up. It definitely saves a lot of tokens/speeds things up.

Re: How Claude Code works in large codebases

#124

Post by agos »

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.

a colleague using OpenCode was telling me it has linting/formatting configurable at harness level and I can't see why this is in every harness

Re: How Claude Code works in large codebases

#125

Post by maccard »

bigstrat2003 wrote: post #116
maccard wrote: post #109

Earlier quoted context omitted.

The problem with agents is they regularly sidestep the guardrails and do what they want with a script anyway. The number of times I’ve seen Claude try to escape the folder it’s working in, and then for it to write a python script that does exactly what I told it it’s not allowed do supports that. If you use SSO and have an AWS config that Claude is allowed to see to get the correct role in the first place, it will ju…

And this is why it is the height of irresponsibility to run LLMs on your system. We know they are unreliable and just make things up; it's extremely foolish to go "yeah I'm going to let that run commands".

It's not _really_ any different to running an undocumented third party binary. Is it the height of irresponsibility to run Windows, or VSCode, or Spotify?

I think the model we've got now is wrong, and the harnesses should be OS-level sandboxed, and the agents should be running in harness managed sandboxes.

Re: How Claude Code works in large codebases

#126

Post by troupo »

marhee wrote: post #39
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…

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"

Re: How Claude Code works in large codebases

#127

Post by lebski88 »

> That also includes codebases running on languages that teams don't always associate with AI coding tools, such as C, C++, C#, Java, PHP.

What a strange comment for them to make. Why wouldn't I expect CC to work well with those languages? What languages would I associated it with? Python and Javascript?

Re: How Claude Code works in large codebases

#128

Post by 0123456789ABCDE »

prodigycorp wrote: post #78
0123456789ABCDE wrote: post #77

Earlier quoted context omitted.

you shoouldn't expect a corpo blog to read like an engineering one try this instead: https://anthropic.com/engineering

Perhaps, but I'm commenting on a blog post called "How Claude Code works in large codebases". That's an interesting question to me. I had hoped there was a more interesting answer.

sure.

replying to the question introduced with your edit at the root: mcp servers tend to inject too many tokens into the context, that might not be relevant for the task at hand. ex: sentry's mcp is useful if you are collecting context for a bug in production, but is hardly useful later when fixing the bug, at that point you'd probably want treesitter, or if you are working on a new feature you might want to pull details from github issues, or jira tickets.

the consensus seems to land on making the right tools available to the agent, and let it pick which ones to use for the task, this typically means cli tools like git, gh, linters, a cli for your cloud/hosting provider, etc.

that is where skills come in: they bootstrap some context about a task the operator wants to complete. skills use progressive disclosure — each Read() adds more context, but the agent controls what to load-up and what to ignore, and skills can also come with scripts that facilitate actions relevant to the task.

Re: How Claude Code works in large codebases

#129

Post by mrweasel »

ramraj07 wrote: post #49
digitaltrees wrote: post #37

Earlier quoted context omitted.

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

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?

Re: How Claude Code works in large codebases

#130

Post by suchar »

digitaltrees wrote: post #113
giancarlostoro wrote: post #69

Earlier quoted context omitted.

Sounds like they're still giving the model the keys to the kingdom, which is my point, stop giving the model the avenue to do catastrophic mistakes, it makes no sense.

If you’re message is in response to me, which I think it is, I deliberately don’t give access to credentials and env variables. I’ve worked to create restrictions and seen AI models use very interesting methods to bypass them. Even now my prompt says the AI must verify the path of the files it intends to edit, and get permission before editing one file at a time and only after permission. I stop it from ignoring thos…

This is not privilege separation/sandboxing. Separate virtual machine for an agent with limited credentials is reasonably safe approach
Post reply on HN