How Anthropic's Product Engineers Use Claude

1. The context-switching tax every engineer pays

Ask any software engineer to account for their day and the math rarely adds up. Cal Newport and deep-work researchers consistently find that knowledge workers get fewer than three hours of uninterrupted, focused work per day — the rest evaporates in transitions. For engineers the transitions are particularly fragmented: you open a GitHub PR to understand a function, that sends you to Slack to ask the original author, the author’s reply mentions a doc, you open Confluence, by the time you are back in your editor you have forgotten why you were there.

This is the context-switching tax. Each switch costs not just the travel time but the reloading time — the minutes it takes to rebuild the mental model of what you were doing before the interruption. Studies on developer productivity estimate the reload cost at anywhere from five to twenty minutes per switch, and a typical engineering session can involve dozens of them. The compounding effect is severe: a four-hour morning can yield less than ninety minutes of actual code production.

The tax is especially high when exploring unfamiliar territory. Onboarding to a new codebase, picking up a ticket in a service you rarely touch, or debugging a system owned by another team all require rapid accumulation of context from many sources simultaneously. Without tooling designed for that task, you are perpetually halfway through the map.

2. Codebase onboarding with Claude Code

Chuma Kabaghe, a software engineer at Anthropic, describes onboarding to a new codebase as the clearest demonstration of Claude Code’s leverage. The traditional approach involves reading READMEs (which are often stale), tracing function calls manually, asking colleagues (who are busy), and slowly building a map of the system over days or weeks. With Claude Code, that timeline collapses.

The technique is conversational archaeology. You start with the questions every engineer needs answered before they can contribute: How does authentication work? Where are payments processed? What does the data model look like and how do the tables relate? You ask these questions directly to Claude Code inside your editor, and Claude reads the actual source — not documentation, not a wiki, not a colleague’s faded memory, but the live code. The answers are grounded, current, and come with citations to the exact files and line numbers worth reading.

This matters beyond speed. When you understand a system from its code, you understand what it actually does, not what someone hoped it would do when they wrote the docs. Claude Code can trace a request from the API endpoint through middleware, into a service layer, down to the database query, and surface the pattern in a single explanation that would otherwise require an hour of cmd+click navigation in an IDE.

Once the basic map is in place, Chuma uses Claude Code to go deeper: understanding why a design decision was made by examining git history (“what was the original intent of this module?”), identifying the ripple effects of a proposed change (“what else might break if I change this interface?”), and spotting the conventions used throughout the codebase (“what’s the pattern for error handling here?”). These are questions that previously required interrupting senior engineers — now they have answers in seconds.

3. Staying in flow during development

Once you understand a codebase, the context-switching tax continues throughout active development. You hit an unfamiliar API, you want to know the idiomatic way to write a certain type of test, you need to remember the exact signature of a utility function your team wrote six months ago. The instinct is to open a browser and search Stack Overflow or the library’s documentation site. Each search pulls you out of the editor, out of the mental model of what you are building.

Claude Code, running inside your editor, changes this completely. Instead of opening a browser, you ask. The answer comes back in the context of your current file, your current task, and your current codebase. Claude Code does not just quote documentation — it understands the code you are already working with and gives you answers that fit your specific situation. “How do I paginate this query?” becomes an answer that uses your existing ORM, your existing model names, and your existing conventions rather than a generic example you have to translate.

Chuma describes this as “staying in the zone.” The key is that Claude Code is not a separate application requiring a context switch — it is integrated into the development environment. The cognitive cost of asking a question drops from “interrupt my flow, open a new context, search, read, translate, come back” to essentially zero. You think a question and ask it.

This creates a virtuous cycle: because asking is cheap, you ask more questions. Because you ask more questions, you understand more before writing code. Because you understand more, the code you write is better. The leverage compounds across every session.

4. Multi-tasking with parallel agents

The most advanced technique Chuma discusses is running multiple Claude Code sessions in parallel across separate git worktrees. This is a genuine multiplier rather than just a convenience feature, and it changes how you think about task sequencing.

The traditional approach to multi-tasking in software development is sequential: finish feature A, switch to bug B, come back to feature A. You cannot safely work on both simultaneously in the same working directory because your uncommitted changes would conflict. Git worktrees solve this by creating separate directory checkouts of the same repository on different branches — you can have feature-A and bug-B open in separate terminal windows, each with their own Claude Code session, each making independent progress.

In practice, Chuma describes starting a larger task — say, implementing a new feature — in one Claude Code session, and then while Claude is executing, opening a second worktree to handle an unrelated bug fix or review a PR. When Claude finishes, you review the diff, course-correct if needed, and let it continue. Your throughput is no longer bounded by Claude’s generation speed; it is bounded by how fast you can review and guide.

This parallelism also makes experimentation cheaper. Instead of being nervous about trying a different architectural approach because it will clobber your current work, you create a new worktree, try the approach there, and compare. The cost of “let’s just see what happens” drops dramatically, and with it, the quality of the decisions you make.

5. The compounding effect of AI-assisted engineering

The headline benefit of Claude Code is “you write code faster” but the deeper benefit is harder to measure and more significant: you defer fewer decisions. Every developer knows the experience of leaving a comment that says // TODO: handle edge case or // this could be refactored because the cost of stopping to do it now feels too high. With Claude Code, the cost of many of those decisions drops enough that you just do them.

Chuma describes this as “fewer sins of omission.” When adding tests is low-cost, you add tests. When writing a docstring is just asking Claude to do it, you write docstrings. When refactoring a messy function takes a quick instruction instead of twenty minutes of careful edits, you refactor it. The quality of the codebase improves not because Claude writes better code than a human, but because the human engineer has more budget to spend on quality.

The compounding effect is real. A codebase that is consistently documented, consistently tested, and consistently refactored is easier to navigate, which makes onboarding faster, which makes adding features cheaper, which makes the team more responsive to users. Claude Code enters this feedback loop at every stage.

npm install -g @anthropic-ai/claude-code

/init

How does authentication work in this codebase? Show me the key files.

Where is the core business logic processed? Walk me through a typical request lifecycle.

Explain the data model — what are the main entities and how do they relate?

mkdir -p .claude/commands
cat > .claude/commands/explain-module.md << 'EOF'
Explain the module or file at $ARGUMENTS. Cover:
1. What problem it solves
2. Its public interface (exported functions, classes, or types)
3. Key dependencies it relies on
4. Anything a developer should know before modifying it
EOF

git worktree add ../project-experiment experiment/new-approach