Claude Code is running in production across multi-million-line monorepos, decades-old legacy systems, and distributed service architectures at engineering organisations from Sydney fintechs to Melbourne infrastructure firms. The patterns that make it work at scale, and the ones that quietly undermine it, are now well documented from real deployments. This post covers both.
How Claude Code navigates a large codebase
Most AI coding tools rely on retrieval-augmented generation: they embed the codebase, build an index, and retrieve relevant chunks at query time. At scale, those pipelines struggle to keep up with active engineering teams. By the time a developer queries the index, it may reflect the codebase from weeks earlier, before a function was renamed or a module was deleted in the last sprint. Retrieval returns outdated context with no indication that it is stale.
Claude Code works differently. It navigates a codebase the way a software engineer would: traversing the file system, reading files, running grep to find exactly what it needs, and following references across packages. There is no embedding pipeline or centralised index. Each developer's instance works from the live codebase on their own machine.
The trade-off is that this approach works best when Claude has enough starting context to know where to look. The quality of its navigation is shaped directly by how well the codebase is prepared. Teams that invest in that setup consistently see better results; teams that skip it run into context-window limits on complex queries.
The harness determines performance
One of the most common misconceptions about Claude Code at enterprise scale is that its performance is determined by the underlying model. Teams benchmark the model, evaluate it on sample tasks, and form expectations from those results. In practice, the ecosystem built around the model determines how it performs in production more than benchmarks do.
Anthropic calls this ecosystem the harness. It is built from layered extension points, each serving a distinct function, and the order in which teams build them matters because each layer builds on what came before:
CLAUDE.md files load automatically at the start of every session and give Claude the codebase knowledge it needs before any task begins. A root file covers big-picture conventions; subdirectory files handle local patterns. Keeping them lean and focused is the difference between fast, useful context and a wall of noise that degrades performance.
Hooks run at defined moments in the session. Their highest-value use is not gatekeeping but continuous improvement: a stop hook can reflect on what just happened and propose CLAUDE.md updates while the session context is still fresh. A start hook can load team-specific context dynamically so every developer gets the right setup for their part of the codebase without manual configuration.
Skills package specific expertise and load on demand rather than occupying context in every session. In a large codebase with dozens of task types, a security review skill loads when Claude is assessing vulnerabilities; a documentation skill loads when a code change needs updating. Skills can be scoped to specific paths so they only activate in the relevant directory.
Plugins bundle skills, hooks, and MCP configurations into a single installable package. For an Australian engineering organisation, the practical effect is that a new hire on day one has the same context and tooling as the team that has been running Claude Code for six months. Plugin updates can be distributed organisation-wide through managed marketplaces.
Language server protocol (LSP) integrations give Claude the same symbol-level navigation that developers have in their IDEs. In large codebases using C, C++, Java, or C# (common in Australian financial services and infrastructure firms), this is one of the highest-value investments. Without it, Claude pattern-matches on text and can land on the wrong symbol in code with common naming conventions.
MCP servers connect Claude to internal tools, data sources, and APIs it otherwise cannot reach. Teams have built MCP servers that expose structured codebase search as a direct tool call. Others connect to ticketing systems, internal documentation, or compliance databases relevant to APRA-supervised development environments.
Subagents spin up isolated Claude instances with their own context windows. A read-only subagent maps a subsystem and writes findings to a file; the main agent then edits with the full picture. This separation of exploration from editing is particularly useful in legacy systems where blast radius matters.
Three configuration patterns from successful deployments
Across the deployments Anthropic has observed, three patterns appear consistently in organisations that made Claude Code work at scale.
Make the codebase legible to Claude
Claude's ability to help is bounded by its ability to find the right context without burning its context window on irrelevant output. Effective teams scope initialisation to subdirectories rather than the repo root, specify test and lint commands at the subdirectory level, and commit .ignore rules to version control so every developer gets the same noise reduction automatically. For codebases where the directory structure does not do the orientating work, a lightweight markdown file at the root listing each top-level folder with a one-line description gives Claude a table of contents it can scan before opening files.
Treat CLAUDE.md files as living documentation
As Claude models evolve, instructions written for an earlier model can become constraints for a newer one. A rule telling Claude to break every refactor into single-file changes may have helped an earlier model stay on track but prevents a newer model from making coordinated cross-file edits it handles well. Similarly, hooks and skills built to compensate for model limitations that no longer exist become overhead once those limitations are addressed.
Effective teams review their CLAUDE.md files every three to six months, and always after a major model release. The goal is not just to keep the instructions current but to remove instructions that are no longer needed. A leaner harness performs better than a complete one.
Assign ownership before the broad rollout
The rollouts that spread fastest had infrastructure built before broad access opened. A small team built the plugins, hooks, and MCP connections so that when developers first touched Claude Code their first experience was productive rather than frustrating. An emerging role in several organisations is what Anthropic calls an agent manager: a hybrid PM/engineer function responsible for the Claude Code configuration, permissions policy, the plugin marketplace, and CLAUDE.md conventions.
For AU mid-market engineering organisations with $100M to $500M revenue, the minimum viable version is a single designated owner. Without clear ownership, knowledge stays tribal and adoption plateaus after the initial early adopters. Cross-functional working groups that bring together engineering, information security, and governance from the beginning avoid having to retrofit compliance requirements onto a rollout that has already started.
Where Australian engineering teams should start
Australian engineering organisations, particularly those in financial services, utilities, and logistics where codebases span decades of accumulated logic, face exactly the large-codebase challenges this framework addresses. The $150,000 to $250,000 AUD investment in tooling, configuration, and dedicated ownership that a mature Claude Code setup typically requires is recoverable in the first year for a 50-person engineering team, based on productivity benchmarks from comparable deployments.
For APRA-supervised institutions and ASX-listed companies with audit obligations, starting with a defined set of approved skills, required code review processes, and limited initial access gives compliance stakeholders the visibility they need without blocking engineering momentum. The Privacy Act obligations that apply to AU engineering teams also shape how MCP servers connecting to customer data stores should be scoped and permissioned from day one.
If your team is evaluating Claude Code for a large codebase or planning a multi-team rollout, we work with AU engineering leaders on exactly this kind of deployment. Book a session with us to discuss your specific codebase and team structure.
