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

[lukaslalinsky]

It works exactly the way I'd work. I have learned to navigate large codebases before LSPs existed. I used vim for many years and would grep to find the relevant files. When I first tried Claude Code last year, I was like WTF, it's going exactly what I'd be doing.

[marhee]

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 can and should use. But I think it does, at least Codex does is my case so I guess Claude does it to. For example Codex use ‘go doc’ first before doing greps.

[troupo]

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

[coldtea]

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.

[troupo]

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.

[sumitkumar]

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 indexing, explicit dependency graphs. Whatever makes the agent's job trivial rather than heroic.

[bluGill]

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.

[ryanschaefer]

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.

[fragmede]

That's the question, innit? Dumped into a codebase and given a ticket, what's the fastest way to get your bearings and do the ticket? It's gonna depend on the codebase and the ticket, but it would be an interesting contest to see what tools people have. Some form of grep, sped up using an index, is going to get a skilled operator pretty far, but more complex tools for more complex tickets, eg fix something subtle, like a bug that only manifests on Tuesdays in 2% of requests from Poland, I imagine more advanced tools would help the programmer figure it out faster.

[zzet]

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

[hibikir]

Even if there is first principles traversal of some parts of the codebase, there are other bits that definitely not change, and where exploring every time is a massive waste of tokens. My arguments with claude often have to do with making it explore a lot less, because I know better, and faster, than its slow, expensive navigation of things that basically never change. And it just goes into the same kind of rabbit holes every time.

[lukaslalinsky]

I still think the best process with Claude Code is: 1) ask it to gather context that you know is relevant 2) only then ask it to do whatever you want it to do. If you do it the other way around, it will over research, over think and generally make more of a mess.

[khuey]

The article does have an entire paragraph about LSPs and how Claude can use them.