Advanced Claude Code in Practice: Building a Top-Tier AI Development Workflow

The Core Proposition: Claude's Capability Boundaries Determine the Depth of Collaboration

Holman delivered the single most important line of the entire talk: "If Claude can't do everything you can do, it can't do your job with you."

Out of the box, Claude can only see one code repository and one shell. For small greenfield projects with no historical baggage and no team conventions, this is enough. But the moment you enter the realm of professional software engineering—especially a large monorepo where thousands of engineers collaborate—this "vanilla" Claude falls far short.

A monorepo (single repository) is an engineering practice that stores the code for multiple projects, services, or components together in a single version control repository. Tech giants like Google, Meta, and Microsoft all adopt this model; Google's monorepo reportedly exceeds 2 billion lines of code and encompasses the daily work of tens of thousands of engineers. The advantage of this architecture lies in the atomicity of cross-project refactoring and unified management of dependencies, but it comes at the cost of extreme complexity in build systems, code navigation, and permission management. For an AI Agent, a monorepo environment means you can't simply "read all the code"—just understanding the dependency graph, build rules, and team conventions requires a large amount of tacit knowledge that goes beyond the source code itself.

She pointed out a severely underestimated fact: most of the work in professional software engineering doesn't exist in the source code at all. Decisions happen in Slack discussions, designs are written in design docs, and motivations are buried in meeting notes and email threads. When you feel Claude has "gone in the wrong direction," it's often because there's information in your head that it cannot access. Give Claude access to that information, and its judgment will align closely with your own thinking.

She offered a highly actionable experiment: try to get your work done for an entire day without leaving the Claude Code terminal. Every time you need to switch to another tool, Alt+Tab to copy and paste something, write it down on paper. By the end of the day, figure out how to connect all those tools into Claude. "You'll find the gap is far bigger than you imagined."

Three Dimensions of Customization: Access, Knowledge, and Tooling

If there's one throughline for how to customize an Agent, it's these three dimensions: Access, Knowledge, and Tooling.

Access: Let Claude See the "Why"

The information sources you need to connect include: team chat (the decision-making process in Slack), CI/CD (Holman explicitly stated, "You shouldn't be manually fixing CI failures yourself anymore—Agents are extremely good at this"), production dashboards, and internal docs, design docs, runbooks, and more.

She shared a highly efficient habit: her team started recording and transcribing all meetings, and right after each meeting she'd immediately feed the meeting notes to Claude and ask, "Is there any low-hanging fruit here I can handle right away?"—netting two or three PRs from every meeting.

Knowledge: Why Fine-tuning Isn't the Answer

When faced with the common question of "can we train codebase conventions into the model," Holman gave a clear no. She cited relevant papers to point out that fine-tuning on professional information may actually lead to more hallucinations, and the cost-effectiveness is terrible—frontier models iterate so fast that by the time you finish fine-tuning, the model is already outdated.

Two known ML problems are at play here: "catastrophic forgetting" and "overfitting to a specialized domain." When a model is fine-tuned on a narrow specialized corpus, it may produce more fluent, more "proper-looking" output within that domain, but it actually increases the probability of confident hallucination—the model learns to express itself in the language style of that domain without necessarily truly understanding the domain's constraints. Furthermore, the iteration speed of frontier models far outpaces enterprise fine-tuning cycles, causing fine-tuned artifacts to quickly become a "slow model + specific style" combination that lags behind simply using the latest model plus ICL.

Based on "The Bitter Lesson," general-purpose AI will win out in the long run. This is the most influential assertion in the field of AI research, proposed by Richard Sutton in 2019: 70 years of AI history has repeatedly proven that relying on general methods (especially those that leverage large-scale computation and data) always ultimately beats specialized methods that rely on human prior knowledge. Every time researchers try to hard-code domain knowledge into a model, it seems effective in the short term, but as compute grows, general learning methods always catch up and overtake—deep learning replacing hand-crafted features in the ImageNet era, and AlphaGo Zero abandoning human game records for self-play, are both examples. Therefore, the only realistic path to customizing Claude's behavior is In-Context Learning (ICL).

ICL refers to the ability of large language models to perform new tasks without updating weights, simply by providing examples or instructions in the input prompt—a capability first systematically described in the GPT-3 paper. Holman defined ICL in a tongue-in-cheek way: "It's a fancy word that makes you sound smart, but plainly put it's just a text file." The benefit is—you don't need to understand model weights; all customization is just text files, extremely easy to get started, version-control friendly, and automatically benefits from base model upgrades.

Tooling: Build "Red Squigglies" for the Agent

This is one of the most brilliant analogies of the entire talk. Holman asked: What should the IDE for Claude look like? Humans writing code have syntax highlighting, LSP, and code completion, while Claude comes out of the box with just an edit tool—"this is more primitive than Vim, this is ED-level."

She focused on the philosophy of "red squigglies": when you mistype a variable name, that red line doesn't forcibly stop you—instead it gently reminds you to think again—you can choose to ignore it and keep writing. She advocated building the same mechanism for the Agent, and Post-tool-use hooks are precisely the Agent's red squigglies.

Post-tool-use hooks are an event hook mechanism in the Claude Code plugin system, triggered automatically after each tool call the Agent makes (such as file editing or command execution) completes, allowing developers to inject custom validation logic. This design draws on the Language Server Protocol (LSP) philosophy of modern IDEs—LSP decouples the editor from language analysis tools, enabling features like code completion and error hints through a standardized protocol, while hooks decouple the Agent's tool-calling behavior from external quality-check logic. Typical uses include: automatically running a type checker after the Agent modifies a file and feeding error messages back to the model as text; or running a linter before code is committed and injecting style warnings into the conversation as "ignorable reminders" rather than forcibly interrupting the flow.

This leads to a key tool classification framework:

• Tools that compensate for insufficient intelligence: for example, hard-prohibiting Claude from using undefined variables. This does reduce errors, but forces Claude to write code in a specific order and can't benefit as the model gets stronger.
• Tools that scale with intelligence: for example, overridable reminder-style nudges. The stronger the model, the more useful these tools become.

Holman emphasized: "The fastest way to make an Agent understand your codebase better isn't a smarter model, it's a tighter feedback loop." And these feedback scripts (linters, type checkers) you actually already have—because you once had to set up the environment for human developers.

Context Window Management: Running npm on an Arduino

All customization ultimately has to fit into the context window. Holman pointed out a counterintuitive fact: context windows are not getting bigger. Frontier models have long stayed at the million-token scale, but model capabilities have changed dramatically. This means context engineering faces a fixed, unchanging target.

She used a brilliant analogy: it's like running npm on an Arduino—memory is extremely limited, and you must figure out the most important things and put them in in the most streamlined form, leaving room for the actual work. Here she invoked the classic C++ principle "Don't pay for what you don't use," i.e., the zero-overhead abstraction principle.

The zero-overhead abstraction principle was proposed by C++ creator Bjarne Stroustrup, with the full statement comprising two complementary principles: "What you don't use, you don't pay for; and what you do use, you couldn't hand-code any better." C++'s std::sort matches or outperforms hand-written quicksort on most platforms, precisely embodying this principle. Migrating this idea to Agent system design means good Agent infrastructure should make developers pay context costs only for capabilities actually used—Hooks consume zero tokens when not triggered, and Skill descriptions occupy just a single line when not loaded, are both embodiments of this principle. Judged by this standard, any design that continues to occupy context even when unused violates the first clause of this principle.

Even more complex is the KV cache constraint. In the self-attention mechanism of the Transformer architecture, each token requires computing three vectors—Query, Key, and Value—when processed. The core idea of KV cache (Key-Value Cache) is: for prefixes that have already been processed, their Key and Value matrices don't need to be recomputed in subsequent inference and can be cached and reused directly, reducing the computational complexity of long-text inference from O(n²) to nearly O(n). However, the effectiveness of KV caching depends on byte-level exact matching of the prefix—even a single space change in the system prompt invalidates the cache for all subsequent tokens, requiring recomputation. Anthropic's Prompt Caching feature sets the cache-hit price at 10% of the uncached price, which is exactly the source of the 10x cost Holman referred to. This means the traditional LRU-cache-style thinking of "evicting infrequently used tools" no longer works—you cannot remove anything from a tool block without invalidating the entire cache.

Therefore the correct strategy is: place stable, shared content at the very front, and place volatile, task-relevant information toward the back, so it can be evicted at low cost.

The Four Plugin Primitives: Which Ones Truly Scale?

Holman examined four plugin primitives using the yardstick of "what happens if I had 100,000 of these." Some companies' monorepos already contain tens of thousands or even hundreds of thousands of skills, and are running into scalability ceilings.

MCP: Designed for the Chatbot Era

MCP (Model Context Protocol) is a standardized protocol open-sourced by Anthropic under the Apache 2.0 license in November 2024. Its design inspiration comes directly from the Language Server Protocol (LSP) released by Microsoft in 2016—LSP thoroughly solved the fragmentation problem where "M editors × N languages" required M×N integrations by defining a standard communication protocol between editors (clients) and language analysis tools (servers); MCP attempts to do the same for "AI models × external tools/data sources." The protocol uses the JSON-RPC 2.0 message format at its foundation, supports both stdio (local process communication) and SSE (Server-Sent Events, for remote services) transport methods, and provides three primitives: tool calling (Tools), resource reading (Resources), and prompt templates (Prompts).

MCP was born in an era when LLMs were still simple, primarily targeting chatbots that had no shell and couldn't run commands. Its advantages are being transport-protocol agnostic and automatically handling authentication, making it suitable for enterprises to release integrations to the public.

But in a professional engineering environment, if you already have a CLI, wrapping it into MCP often makes no sense—unless you're delivering to non-technical customers. A better approach is to write a skill telling Claude how to use that CLI. Of course, when connecting to external services like Slack or email, you still need someone else's MCP server.

The scalability problem: every tool's name, description, and schema has to go into the system prompt. Its main limitation is that the protocol's metadata must all be loaded into context in full when the connection is established, lacking any lazy-loading mechanism. With 20 servers, each with 15 tools, most of your context window gets filled with tool definitions. Anthropic's new solution, "tool search," uses lazy loading—putting only the names into the system prompt and letting Claude use a tool to search for tools. But the problem is that unless the user explicitly mentions it (e.g., "Slack"), Claude may not know it needs to go searching. This is a "slightly cheaper lunch," not a free lunch.

Skills: Lazy-Loaded System Prompts

Holman described a skill as a "lazy-loaded system prompt"—essentially a folder with a markdown file, where a one-line description in the front matter enters the system prompt and Claude can load the full skill.md on demand.

Its body is pay-per-use (a good thing), but the description is always loaded, so it's not entirely zero-overhead. Reliably triggering a skill sometimes requires a 300-400 token description. And currently skills have no hierarchical structure yet, so you can't lazy-load sub-skills (this feature is under development). "It kind of scales, but we'd originally hoped it would scale better."

Hooks: A True Zero-Overhead Abstraction

Hooks are the only true zero-overhead abstraction among the four. They call a script you provide when a specific event triggers, and the script runs outside the context window at zero token cost.

The key is: you can have 100,000 hooks, and as long as 99,995 of them don't trigger or don't return text, you pay no context cost at all. You've expanded an extremely constrained resource (context) into a far less constrained one (your computer). This is exactly the property to look for when designing such systems. The "red squigglies" mentioned earlier live here.

Subagents: Independent Context Spaces

Subagents have their own independent context—the main context only pays for the tool call and the returned results, and a subagent can read 50 files without occupying the main loop. But each subagent's one-line description still has to sit in the parent prompt, so it faces the same 100,000-description scalability problem.

On CLAUDE.md: Holman explained why she has consistently refused requests to "let plugins provide CLAUDE.md files"—if allowed, nearly every plugin would unconditionally stuff a block of text into the user's context, "which looks extremely cheap but simply doesn't scale." If you really need it, you can return text via a session-start hook, which at least makes it clear to the user that they're paying unconditionally.

Async and Parallelism: The New Way of Working for Engineers in the AI Era

Holman believes the two major themes of the future are asynchrony and parallelism, which means engineers must be good at context switching. As a "programmer's programmer" who once loved eight straight hours of flow state, she admitted this shift is uncomfortable, but it's the inevitable direction of efficient engineering. Practical tips she shared include:

• Git worktrees: A feature introduced in Git 2.5 (2015) that allows the same repository to maintain multiple working directories simultaneously in the filesystem, each checking out a different branch but sharing the same underlying object database and .git directory. In traditional human workflows, worktrees are mainly used when you need to work on multiple bug fixes or feature branches simultaneously, avoiding the context-switching cost of frequent stash/pop. In AI Agent scenarios, their value is amplified exponentially: assign an independent Claude Code instance to each worktree so they don't interfere with each other—you become the "tech lead for multiple Claudes," shifting your work mode from serial flow to parallel supervision. She herself maintains a batch of long-lived, persistent Agents each with its own directory.
• Rename sessions and change their colors (/color): color triggers human memory efficiently—it's "syntax highlighting for humans in the age of agents."
• Claudes communicating with each other: Agents can send messages to other Agents—because "one of the places you now work is inside another Claude."
• /loop (internally named crontool): run a prompt at fixed intervals to "babysit" a PR—even if CI takes two hours, it can automatically fix CI bugs.
• Auto permission mode: not the dangerous skip-permissions, but a safety mechanism with a classifier and an adversarial checking Agent, costing about 30-40% more tokens, but making Loop, Agent teams, and overnight work possible.
• Remote control: spend 30 seconds on your phone after dinner to check whether an Agent is stuck.

Three Core Principles

Holman wrapped up with three sentences (she joked that Claude helped her come up with "Mind the box"):

1. Give it access—let Claude reach every information source you work with.
2. Mind the box—always think about your context window.
3. Pick abstractions that scale—imagine what your plugin will look like when your monorepo has a hundred million lines of code and a hundred thousand skills.

The deeper value of this talk lies in elevating "writing code with AI" to the level of "doing software engineering with AI"—the real challenge isn't making the model smarter, but figuring out how, within a fixed context budget, to deliver the right information to the model at the right moment through carefully designed engineering abstractions.