A solo developer with Claude Code is a productivity story. A team with Claude Code is an operating-model question.

Most of the wins (and most of the failures) I see at the team level have nothing to do with the model. They are about shared vocabulary, shared constraints, and shared review rituals.

Here is what works, what doesn't, and the patterns I would steal.

The shared .claude/ folder is the unlock

Commit .claude/ to the repo. All of it.

• CLAUDE.md — project context, conventions, never-modify list.
• .claude/settings.json — tool allowlist / denylist.
• .claude/agents/*.md — your sub-agent crew.
• .claude/commands/*.md — your slash commands.

Everyone on the team gets the same operating model on git pull. Onboarding goes from "let me show you my prompts" to "read .claude/, you'll get it."

Agent ownership — pick a maintainer

Each sub-agent should have an owner in the team. Not because agents are complex (they're a .md file), but because agents drift.

A code-reviewer written for a 5-engineer team in month one will be wrong by month six. Someone needs to:

• Read review feedback the agent surfaces.
• Notice when it misses a class of bug.
• Update the system prompt.

Treat sub-agents like infrastructure. Owned, versioned, reviewed in PRs.

PR rituals that change with Claude Code

Three rituals I've seen work:

1. AI-authored PRs declare it

Add a label or a section in the PR template:

## AI-assisted

- Implementer: yes / no
- Test author: human / AI
- Code reviewer (pre-PR): n/a / `code-reviewer` agent

This is not bureaucracy. It is signal. When something breaks, you want to know which class of authorship to investigate.

2. Two-tier review

For PRs > 200 lines or touching critical paths:

• Tier 1: code-reviewer agent (pre-push).
• Tier 2: human reviewer (post-push).

For everything else, the agent's pass + the author's diff review is enough. Stop pretending you read every line of every sub-50-line PR.

3. "Diff-first" code review

Reviewers stop opening files. They read the diff in gh pr diff and trust the test suite. This sounds reckless until you realise it has been the right behaviour for years — humans were just bad at it.

Claude Code's review-as-an-agent makes the diff-first model honest: a separate agent already vetted it for the obvious stuff before a human touched it.

What does NOT work

A short list of patterns that look like wins but aren't:

• One Claude Code license, shared across the team. Defeats personalisation, defeats audit trails, creates a permission nightmare. Per-user licenses, period.
• "AI sprint demos" where managers cherry-pick the best PRs. Survivorship bias. Track aggregate metrics, not highlight reels.
• Banning Claude Code from "critical" services. The opposite of the right move. Critical services need the most disciplined sub-agents and tightest allowlists, but they benefit from the workflow most.
• Forcing everyone to use the same prompts. Encourage shared .claude/commands/; resist mandating personal style. People prompt differently and that is fine.

What changes for engineering managers

Three things genuinely shift:

1. Velocity becomes more legible

You can pull stats from ~/.claude/sessions/ (or your equivalent log shipping). Mean time per feature, mean number of agent rounds before green, fraction of PRs that pass review on first try.

This data is good. Use it for diagnostics ("the team is struggling with feature X") not for performance reviews ("you used the agent less").

2. Onboarding bends to the codebase

A new hire becomes productive faster — not because they are smarter, but because .claude/CLAUDE.md and the sub-agents pre-load all the codebase tribal knowledge.

I have onboarded engineers in 2 days who would have taken 2 weeks pre-Claude-Code. The codebase is now self-documenting under instruction.

3. Senior time re-allocates

Senior engineers stop typing the boilerplate. They review more diffs, write more CLAUDE.md, design more ADRs. The agent handles the typing; the senior handles the architecture.

This is a real shift. Some seniors love it. Some miss the typing. Both are legitimate. Just acknowledge the change is happening.

The single-most-common team mistake

Letting Claude Code into the codebase without a shared .claude/ first.

Every engineer ends up with their own settings, their own CLAUDE.md, their own crew. The team's output looks inconsistent because, well, it is.

Spend two days writing the shared .claude/. Run it past the team. Commit it. Then roll out Claude Code.

A 30-day rollout plan that works

• Week 1: 2-3 senior engineers use Claude Code on opt-in tickets. They write the first version of .claude/.
• Week 2: Open it to the rest of the team. Ban it on prod migrations and infra PRs. Daily 15-min "what worked / what didn't" stand-up dedicated to the agent workflow.
• Week 3: Sub-agents codified. Review rituals adopted. Metrics in place.
• Week 4: Lift the prod ban for engineers who have shipped 3+ AI-assisted PRs. Keep the infra ban for now.

By month two, Claude Code is just "how we work." Nobody talks about it specifically anymore. That is the goal.

---

Next article: Advanced Patterns — hooks, MCP servers, custom tools, and system prompts. The things you build once you've outgrown the defaults.