Advanced Claude Code Patterns

Once the fundamentals are habits, the next gains come from running more work in parallel and separating roles across sessions. None of these patterns is exotic. Each takes a small change in how you think about a session.

Parallel sessions with git worktrees

A git worktree is a second working directory attached to the same repository, on its own branch. Each worktree can host its own Claude Code session with its own clean context.

git worktree add ../app-auth-refactor -b refactor/auth
git worktree add ../app-docs -b chore/docs-update

# Terminal 1
cd ../app-auth-refactor && claude

# Terminal 2
cd ../app-docs && claude

# When done
git worktree remove ../app-docs

The mental model changes from "I work with Claude" to "I supervise two or three Claudes." Your job becomes checking in, unblocking, and reviewing. Three parallel sessions is a practical ceiling for most people; beyond that, review becomes the bottleneck.

Pick parallel tasks that do not touch the same files. Merge conflicts between agents are just merge conflicts, but they erase the time you saved.

Writer and reviewer

The author of a change is the worst person to review it, and that is as true for agents as for people. Run two sessions:

1. Session A implements the feature.
2. Session B, with a fresh context, reviews the diff as a staff engineer: correctness, edge cases, tests, design.
3. Paste B's findings into A, or have A read B's review file, and fix.

A reviewer subagent achieves the same effect within one session. Separate sessions work better for large changes because the reviewer can run tests and explore freely.

Tests and implementation from different sessions

A stronger variant of the above. One session writes tests from the spec without seeing any implementation. A different session implements until those tests pass, with instructions not to modify them. The implementer cannot quietly weaken the tests, and the test writer cannot unconsciously test only what the implementation already does.

Adversarial prompts

Ask Claude to argue against its own work:

• "Grill me on this change. Ask the five questions a skeptical staff engineer would ask, and do not accept vague answers."
• "Assume this design fails in production within a month. Write the postmortem. What failed?"
• "Find the input that breaks this function."

These prompts are cheap and frequently find the issue that a polite review misses.

Headless mode for batch work

claude -p runs a single prompt non-interactively and exits, which makes Claude scriptable.

# Structured output for pipelines
claude -p "List every TODO in src/ with file, line, and a one-line summary" \
  --output-format json > todos.json

# Fan out with a bounded number of parallel jobs
cat files.txt | xargs -P 4 -I{} claude -p \
  "Add missing JSDoc to exported functions in {}. Do not change behavior." \
  --allowedTools "Read,Edit"

Always pass a narrow --allowedTools list in headless runs, and run large batches on a branch you can discard. Spot-check a sample of results before trusting the rest.

Claude in CI

The same headless mode powers CI integration. The official GitHub Actions integration lets teammates mention Claude on issues and pull requests to request fixes or reviews, and lets you run scheduled jobs such as weekly dependency upgrade attempts or nightly flaky-test triage. Give CI runs their own scoped API key and the minimum repository permissions.

Living plans

For work that spans days, keep a plan file Claude owns:

# Plan: migrate sessions to Redis

## Decisions
- Use existing Redis cluster; new key prefix `sess:v2:`
- Dual-write for one week, then cut reads over

## Status
- [x] Session store interface extracted
- [x] Redis implementation with tests
- [ ] Dual-write behind flag `SESSIONS_V2_WRITE`
- [ ] Read cutover

## Open questions
- Session TTL: keep 14 days or align with token expiry?

End every session with "update the plan file." Start every session with "read the plan file." This replaces fragile conversation memory with a reviewable artifact your teammates can read too.

Iterative refinement loops

Some teams run Claude in a loop against an objective check: implement, run the checks, feed failures back, repeat until green or a step limit is hit. The pattern works when the check is trustworthy, such as a thorough test suite, a type checker, or a visual diff against a mockup. It fails badly when the check is weak, because the agent will satisfy the check rather than the intent. Always cap iterations and review the final diff.

Cross-model review

For high-stakes changes, a second opinion from a different model family catches different blind spots. Export the diff and ask another model to review it, or vice versa. Treat disagreement between reviewers as the signal: that is where a human should look.

Very large codebases

On repositories with millions of lines:

• Rely on subagents and the Explore agent for search, so the main context sees conclusions, not file dumps.
• Keep package-level CLAUDE.md files so local rules load only where they apply.
• Maintain an architecture document with a map of services and their owners, and import it from the root CLAUDE.md.
• Scope each session to one package or service. Cross-cutting changes become a plan file plus several scoped sessions.

Key takeaways

• Run parallel sessions in separate worktrees, but no more than you can review.
• Separate the author from the reviewer, and the test writer from the implementer.
• Use claude -p with a narrow --allowedTools list for batch and CI work.
• Replace conversation memory with a plan file Claude updates every session.