How Claude Code works in large codebases

shenli3514 78 points 45 comments May 15, 2026
claude.com · View on Hacker News

Discussion Highlights (9 comments)

belZaah

How very interesting. In an industry, where things shift around in months if not weeks, there’s been not only enough time for clear patterns to emerge but also these patterns have proven successful on large codebases. What’s the success criteria? Didn’t delete production database? Team velocity has increased? Codebase TTL has increased? Operations guys are happier?

Tsarp

Wondering if enterprises have a modified version of CC that doesnt have to optimize to stop bleeding on fixed cost subscription plans. The article really does not align with the current sentiment. Everyone with a choice has mostly moved on to codex (ofc in this world all it takes is a model update/harness update to turn things around). CC is great at a lot of things, but repeatedly misses out reading on crucial parts of the code base, hallucinates on the work that was done and a bunch of other issues.

thinkindie

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

wood_spirit

I’m super interested to know what the back and forth between models and tools really looks like in practice. Are there any much more detailed walkthroughs of how it works and how it decides the tools to use and the grep to use etc and what the conversations actually look like? In the UI you see just enough to know it’s doing something but you don’t really see the jumps it’s making offscreen.

tex0

If the developer can have a local copy of the monorepo it's not a "large" codebase.

jwilliams

> 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 centralized index to maintain as thousands of engineers commit new code. Each developer's instance works from the live codebase. The frame of "the way a software engineer would" and the conclusion seem at odds. I'd love to be schooled otherwise? I use autocomplete/LSPs all the time and they're useful. That's an index? Why wouldn't Claude be able to use one? Also a "software engineer" remembers the codebase - that's definitely a RAG. I have a lot of muscle memory to find the file I need through an auto-completed CMD+P. It doesn't need to particularly be real-time across thousands of engineers -- just the branch I'm on. It's rare that I'd be navigating a codebase from first-principles traversal. It would usually be a new codebase and in those cases it's definitely not what I'd call an optimal experience.

ares623

Lots of concepts. Release the harness that made it possible to port Bun to Rust in 9 days. That's what everyone really wants. Then everyone can go "do that but for this other goal".

ufish235

How important are Claude.MD files when they don’t even describe (with concrete terms) what should even go into each one?

prodigycorp

This is really a zero information blog post. I want to know how they use the LSP to improve their understanding of the code base. Would be great if it was open source for us to review. A post like this should be providing people with some reassurance about Claude's ability to understand code at a large scale. It's mostly fluff.

Semantic search powered by Rivestack pgvector
8,303 stories · 78,303 chunks indexed