Claude Code at Scale: The Harness Is the Product

There's a version of the AI coding story that goes: better model → better code. More parameters, more training data, smarter completions. Ship faster. Everyone wins.

That story has a wall, and the wall appears right around the time your codebase stops fitting in one person's head.

A recent walkthrough by the AI LABS channel digs into exactly what happens at that wall — and why the solution isn't waiting for a smarter model. The argument they're making, drawing on both their own experience and Anthropic's guidance, is a subtle one: the harness around the model matters more than the model itself. That's worth sitting with, because it runs against how most people think about these tools.

The Navigation Problem Comes First

Before any of the harness stuff, there's a more fundamental question: how does a coding agent actually find what it needs inside a large codebase?

The older approach — RAG-based (Retrieval-Augmented Generation) — embedded the entire codebase into a database and ran semantic search at query time. Ask about a function, get back the chunks that seem most relevant. Clean in theory. Messy in practice, because as the codebase grows, the central database gets stale. Modules get deprecated. Files move. The semantic search doesn't know that, so the agent confidently references code that hasn't existed in six months. Hallucinated imports. Phantom functions. The kind of bugs that take an afternoon to trace.

The shift that's happened across almost all major coding agents — Claude Code, Codex, Gemini CLI — is toward file system-based navigation. The agent uses bash tools: ls to find files, grep to narrow down to the right snippet, then loads only that into context. It's mimicking how a developer actually moves through a codebase rather than pretending the whole thing fits in a searchable bag of embeddings. Less elegant architecturally, but it works — because it doesn't pollute the context window with irrelevant chunks.

This is table stakes now. The interesting question is what you build on top of it.

The Harness: Five Moving Parts

The AI LABS breakdown identifies five components of a proper agent harness. I find this taxonomy useful because it maps onto a real failure mode I keep hearing about from developers: Claude starts strong on a project, then gradually loses coherence as the codebase grows. That's not a model problem. That's a harness problem.

The claude.md file is where most teams start and most teams go wrong. It loads at session start and stays in memory the whole time — it's the agent's working understanding of your codebase conventions, dos, don'ts, architecture decisions. The instinct is to make it comprehensive. The counterintuitive advice here: keep it around 300 lines, and if you're running a monorepo, give each subdirectory its own claude.md that loads progressively. As the video puts it: "stuffing every aspect of the code into one file is highly inefficient. It distracts the agent with information it does not need at the moment."

There's a deeper point here that often gets missed: your claude.md needs to evolve with the model, not just the codebase. Instructions that compensated for Sonnet 3.5's weaknesses might actively confuse Opus. Outdated config files don't just fail to help — they can actively degrade output by flooding the agent with irrelevant constraints.

Hooks are where the setup gets interesting. These are scripts that trigger on specific events — session start, pre-tool use, session end. The session-start hook controls what context loads. Pre-tool-use hooks can prevent the agent from touching files you've declared off-limits. But the one that caught my attention is the stop hook: it runs after a session ends and pushes Claude to reflect on what just happened, then update claude.md with what it learned. "This pushes Claude to reflect on what has been done so far. From that it can update the claude.md with the learnings from the session so the same issues do not happen again." That's not just useful — it's the agent essentially maintaining its own knowledge base over time, which is a different model of how this tooling works.

Skills solve a different problem: context bloat. Instead of stuffing specialized instructions into the main claude.md, skills are .md files that load on demand when the agent enters a relevant task or directory. Working in the deployment folder? The deployment skill loads. Working elsewhere? It doesn't exist as far as the context window is concerned. Progressive disclosure applied to agent context — which is a genuinely clever piece of structural thinking that I don't see enough teams using.

Plugins package skills, hooks, and MCPs (Model Context Protocol integrations) into a distributable unit. For solo developers this is optional. For teams, it's how you avoid the scenario where everyone's Claude has slightly different context, conventions, and configs — which produces subtly inconsistent code that looks fine individually but creates integration chaos. One plugin install, everyone's on the same page.

LSP (Language Server Protocol) is the piece that gets the least attention and matters most for non-standard languages. LSP is what gives your IDE intelligent navigation — go to definition, find all references, that kind of thing. Without it, Claude is basically doing text pattern matching on file names, which works fine for React or Next.js (heavily represented in training data) and falls apart for C++, Rust, or anything niche. The recommendation is to configure LSP before writing a single line of code, not as a fix when things go sideways.

The Subagent Architecture

The last major piece is subagents, and this is where the framing shifts from "configure your tools better" to something closer to system design.

Subagents have isolated context windows. The main orchestrator delegates specific tasks to them, they do the work, and they return only the final output — not the entire intermediate reasoning and file exploration that led to it. The main agent's context window stays clean. You can also run subagents in parallel, which changes the performance profile considerably for large tasks.

What's interesting here is the override capability: you can replace Claude's default subagents (like its built-in "explore" agent) with custom ones that understand your specific directory structure. The default explore agent is generalized for all codebases. A custom one knows where your files actually live, which means fewer bash commands spent re-learning the map on every session.

This is the orchestration layer that most "beginner" Claude Code tutorials completely skip past, which is part of why people hit walls they don't know how to diagnose.

What This Framework Assumes

It's worth naming what this approach requires, because it's not nothing. The setup described here — claude.md maintained actively, hooks written as shell scripts, LSP configured per language, custom subagents, team plugins — is engineering work. It's not configuration-on-a-Sunday-afternoon work.

The implicit claim is that this upfront investment pays off in projects that don't fall apart at scale. That's probably true. But it raises a question the video doesn't fully answer: at what project size does this scaffolding make sense? A solo developer building a side project in TypeScript is probably fine with Claude Code defaults. A team of ten shipping a C++ data pipeline is probably not. The threshold in between is fuzzy, and the video skips past it in favor of covering the full setup.

There's also a maintenance burden that gets acknowledged but underweighted. "Review your setup every few months as the model evolves. Remove the instructions, hooks, or anything else that the newer model no longer needs." That's good advice. It's also an ongoing time commitment that compounds as the harness grows more elaborate. Whether that trade-off makes sense depends heavily on context.

The Model-as-Commodity Argument

Underneath all of this is a quietly significant claim: if everyone is using the same foundation models, and those models are improving on roughly the same trajectory, the differentiator isn't who has access to the smartest model. It's who built the better harness around it.

"If the harness is weak and the model is strong, there is no point in the model being strong on its own."

That framing has real implications for how teams approach AI-assisted development. It means the engineering investment that matters isn't in prompt engineering or model selection — it's in infrastructure that shapes how the agent operates within your specific environment. Which is, somewhat ironically, just software engineering.

The model is becoming table stakes. What you wrap around it is the actual product.

---

Yuki Okonkwo is Buzzrag's AI & Machine Learning Correspondent.