Part 4: Subagents, MCP and the architecture behind Code Review

The first three parts of this series covered what Claude Code is (Part 1), how to set up the environment (Part 2), and how to encode your judgment through configuration (Part 3). This part covers what happens when the tool operates at team scale — and why the architecture matters.

Subagents: parallel execution inside the loop

A single Claude Code session is a sequential loop: read, decide, act, observe, repeat. Subagents extend this with parallel execution.

When a task has independent workstreams — searching multiple sources, running multiple test suites, analyzing multiple files simultaneously — a parent agent can spawn subagents to handle each in parallel, then consolidate the results. The parent does not wait for one to finish before starting the next.

In practice: a task like "audit the entire codebase for missing error handling" can be decomposed into parallel subtasks (auth module, API layer, database layer, frontend) dispatched simultaneously, with results merged. What would take one sequential agent 20 minutes takes a subagent team a fraction of that calendar time.

Subagents are available in any Claude Code session. You do not need special configuration — describe a task that benefits from parallel workstreams and Claude will use them. The VS Code status bar and terminal show each agent's progress as it runs.

Git worktrees for parallel isolation

When multiple agents (or multiple engineers) need to work on the same repository simultaneously without interfering with each other, use git worktrees. Each worktree is an isolated copy of the repository files on a separate branch, sharing git history but maintaining independent file state.

In VS Code's integrated terminal:

claude --worktree feature-auth

This starts a Claude Code session in an isolated worktree on a new branch. Multiple worktree sessions can run in parallel without one's file changes affecting another.

MCP: extending what Claude can reach

Model Context Protocol (MCP) is the integration layer. Claude Code connects to external tools and services via MCP servers — databases, APIs, internal systems, search indexes, GitHub.

An MCP connection makes external data or capability available inside the agentic loop as a tool Claude can call, observe, and reason about. The distinction between a local file and an external API disappears from Claude's perspective — both are information it can act on.

To add an MCP server in VS Code's integrated terminal:

claude mcp add --transport http github https://api.githubcopilot.com/mcp/

Once configured, Claude can use the tool in conversation: "Review PR #456" — Claude calls the GitHub MCP, reads the PR, runs its analysis, responds.

Manage existing MCP servers without leaving VS Code by typing /mcp in the chat panel. The interface shows enabled/disabled state, connection status, and OAuth authentication for each server.

This is how Claude Code moves from being a personal coding assistant to being integrated into the team's actual infrastructure: CI systems, issue trackers, internal databases, knowledge bases.

The Code Review architecture

The Code Review feature is the clearest production example of this architecture at work.

When a PR is opened, Code Review dispatches a fleet of specialized agents in parallel — each targeting a different class of problem: security, logic correctness, test coverage, documentation alignment. The results are consolidated, filtered (less than 1% false positives), and delivered as actionable PR comments.

That fleet of parallel specialized agents is a subagent pattern. The integration with GitHub is MCP. The rules each agent follows are Skills.

Every pattern used in Code Review is available to you in a regular Claude Code session. The difference is not capability — it is that Code Review has operationalized the architecture into a production workflow.

Understanding this architecture changes how you think about Claude Code's ceiling. A solo developer using subagents and MCP is running the same class of system as Code Review, just at smaller scale.

What team-scale adoption looks like

As Claude Code spreads across an engineering team, configuration becomes a shared responsibility:

CLAUDE.md in the repository root applies to all engineers on all sessions — maintained like a README
Project-scoped Skills in .claude/ give every engineer access to the same /review, /deploy, and /debug workflows
Project-scoped Hooks in .claude/settings.json enforce policies (no writes outside safe directories, mandatory linting) for all engineers regardless of individual settings
MCP servers defined at project scope give the whole team access to the same external tools

Teams that invest here stop relying on individual engineers prompting correctly and start building infrastructure that makes correct behavior the default.

This is the capstone of the series — Code Review as a production deployment of everything covered in Parts 1–4.

Previous: Part 3 — CLAUDE.md, Skills and Hooks

Sources: How Claude Code works · Features overview · Use Claude Code in VS Code