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.

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.

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.

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.

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

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.

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

> Am I using it wrong?

I stopped using `/init` and having CLAUDE|AGENTS.md files that explained the codebase. The only thing I kept was how it should explore the codebase and use `git log` when researching, which is probably redundant too. I can't figure it out either.

The codebase I work on is roughly 100k LOC so idk if it is considered large. Personally it's the largest repo I have worked on.

What seems to work in some cases are hooks with scripts that feed into the context window (I've had to strip out some of the unnecessary linter messaging to limit context). Linters and/or other language specific checkers that can be installed via OS package repository and called via script. Also, the model + skill context together could make a difference. Skills that "worked" on 4.6 may not work as well on 4.7, which seems to require more explicit direction, but is more reliable by comparison to 4.6. Updating skills might help too. Test and run before/after to check. CC also injects unnecessary tool calls into context, so you may need to suppress tasks if you're a beads fan for example.

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 you realise that something in the file you're thinking about is relevant to what I'm working on or might change the direction of what I'm doing.

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.

And Claude Code can use Jetbrain's MCP to use that index.

It's an odd statement. AI slop? GitHub Copilot has pretty good local indexing too. It's not a super hard problem to put code into a vector DB..

> Didn’t delete production database?

I still say if this happens to you with AI tooling, that's both a failure on you and your org for giving a developer prod credentials that could nuke production resources. I don't think I've worked in a place that gave me this level of blind access.

the fish: you can read about that here: https://code.claude.com/docs/en/best-practices#write-an-effe...

the fishing: 1) install the official `skill-creator`; 2) use that with the above link to create `claude-md-improver`; 3) improve the skill by tasking claude with researching the topic of `progressive-disclosure`, in the official docs; 4) point the new skill at you CLAUDE.md file and accept the changes

Disagree, but also what do you classify as local storage? Does the repo “size” include all projects or just one? What about multiple branches? How much capacity is local storage?

A stock Unreal Engine project is several hundred gigs, consists of multiple solutions, multiple languages, and I would classify as large personally.

Without some kind of indexing it’s very awkward to work with and very slow. To work with LLMs and Unreal projects we create a local index, that index file alone is 46GB.

Without distributed compilers and caches it can take multiple hours to compile the main solution per platform (usually PC, Linux, Xbox, PlayStation, Switch, and sometimes mobile).

So the codebase easily fits on local storage so long as you don’t count assets (those are several TB) and extra so for source assets (10s of TB), and that’s per stream per large project.

Anyways, point is I disagree and think Unreal Engine is an example of large codebase that fits locally.

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

If you can't clone it it's not a repo

I think that's correct. Which is kinda funny, I remember 10y ago that I was heavily relying on IntelliJ features to understand new codebases (jump to definition, find all usages of a function, navigate from SQL to the table in database tab etc.).

It turns out, that for a machine, find and grep is all that's required.

You can easily inspect the full requests it makes to the API which contains the full system prompt, tools, tool calls, etc.

Codex is open source if you’re interested https://github.com/openai/codex

Right. There are plenty of codebases with huge CLAUDE.md files in them, for example

Never make assumptions about what "everyone knows", you'd be surprised.

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.

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.

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

I think about this a lot. So far I think we are mostly just being gaslit. That we can influence the AI to be better with a few encouraging words and role playing, actually seems absurd. Maybe there is some element of randomness introduced there or something. All these extra MD files don't seem to do nearly as much for results as people believe they do.

The influencer economy trades on hype, on frenzy, and ultimately, eyeballs. The more the better.

They want you feel like you’re missing out. They want you to switch. Being boring is far more productive. Pin your versions. Stick to stable releases and avoid the nightlies.

Significant noise created from 4.6 to 4.7 Opus transition has caused some to interpret this as signal. Excluding certain genuine and real bugs, the noise about perceived quality falling dramatically was noise. Influencers doing influencing turned it into “signal”. The reality was that if you had strong planning and spec driven development it ranged from manageable to non-existent.

The vast majority of the people I know and work with have not switched off CC or their Max sub.

I have a choice and have not moved to codex (100/mo personal + my employer pays for a subscription). I try codex here and there and it seems to go off the rails every time. I have had some good experiences with codex, but generally trying to get something big accomplished it doesn't work out.

But I may not have paid enough to get the full real experience with codex

> stop bleeding on fixed cost subscription plans

What bleeding? Anthropic wants as much of that "bleeding" as possible. The interaction data gathered from genuine human CC subscription usage of their models goes directly into their RL training, it's invaluable and they are more than happy to lose money on the inference to get it. That data is what xAI was recently willing to pay $10b to cursor to get.

They want you to use Claude Code. They hate other UI surfaces like OpenCode etc purely because they lose control over that data, so they're subsidizing the inference without getting what they actually want, the data (they still get some of it of course, but it's much less ergonomic for them. Those tools often abstract away the subagent calls, for example). OpenCode can collect that data themselves, so by allowing subscription there, Anthropic sees itself as subsidizing another org getting that data. Hard no.

And tools like OpenClaw are useless because they're mechanical and don't represent actual users interacting with the service - again, subsidizing but not getting the reward.

It's all very simple once you understand their motivations.

> Everyone with a choice has mostly moved on to codex

Ha!

You must be using a different CC. Or what they’re writing here is correct, and it’s all due to the CLAUDE.md file that I only occassionally yell at claude.

I think it's a good rule of thumb that if you find yourself saying everyone prefers this model or that model you're in a bubble. I've made this mistake before, I used to go around saying everyone knew Claude was the only model for serious professional use, but I was wrong.

> Everyone with a choice has mostly moved on to codex

You are deep in an information bubble, mostly driven by hype-train influencers with magpie attention spans.

what if this magical harness is just: experienced operator† + claude code + official plugins + opus 4.7 + max effort ?

† swe with practical experience, a code wrangler if you will

There you have a verifier though. As in you have test cases (which are written in JS and thus do not need to be translated). The moment you have a verifier signal LLMs become extremely reliable. Now of course they can reward hack your test cases but in a large codebase with many tests it becomes the only small thing you have to worry about.

Really? I thought it explained the point that harnessing for agentic search of a large code base is more beneficial than RAG-indexing a monorepo.

This is already the case for many startups. In fact, the figure might be closer to 100%. The work shifts to requirements analysis, high-level specifications, and final review instead (after AI code review).

He would be right if claude code was written by a team of humans. The AI written blob is slowing progress.

I mean, since Opus 4.6 came out, that rings more and more true. You still have to babysit the output, do some planning and be proactive about ways to do things better… but 80-90% isn’t out of the question if you’re in the domains that are well represented in the training data, e.g. if you’re writing a lot of CRUD functionality as a web dev.

Companies will definitely expect devs to ship more with the same headcount, oftentimes either won’t hire juniors to train them up or will straight up do layoffs, sometimes the AI just being a convenient scapegoat. We kind of can’t ignore that either, sure a lot of those companies will be shooting themselves in the foot, but livelihoods will be impacted a bunch.