Skip to content
Lesson 6 of 12

Parallel Execution — Multiple Agents, Maximum Speed

7 min read

The Biggest Productivity Unlock

Everything covered so far -- the mindset, the workflow, the prompting -- brings you to roughly 3x productivity. The leap from 3x to 5.7x comes from one technique: parallel execution. Instead of working on one task at a time, you run multiple AI agents simultaneously on independent tasks.

Think of it as the difference between having one skilled assistant and having four. With one assistant, tasks execute sequentially. With four, independent tasks run at the same time. Your job shifts from doing the work to dispatching and reviewing work.

Background Agents

Claude Code supports background agents that run independently while you continue working in your main session. This is the foundation of parallel execution:

# Start a background agent for an independent task
claude --background "Create all 12 lesson files for the RAG Engineering
       course with full content, proper frontmatter, and code examples"

# Continue working in your main session on something else
claude "Meanwhile, implement the course navigation component with
       previous/next lesson links and a progress indicator"

The background agent works independently, reading the project context, creating files, and completing its task. When it finishes, you review the output. Meanwhile, your main session handles a completely different task.

Launching Multiple Background Agents

For maximum parallelism, launch several agents at once:

# Agent 1: English content
claude --background "Create all English lesson files (.en.mdx) for the
       AI Productivity course with full content"

# Agent 2: Spanish content
claude --background "Create all Spanish lesson files (.es.mdx) for the
       AI Productivity course, translating from the English versions"

# Agent 3: Component work
claude --background "Build the CourseCard component with thumbnail,
       progress bar, lesson count, and difficulty badge"

# Main session: Infrastructure
claude "Set up the course routing and dynamic page generation for
       /courses/[slug]/[lesson]"

Four streams of work happening simultaneously. Each agent has full access to the project context and can read and write files independently.

Worktree Isolation

When parallel agents might modify the same files, use git worktrees to isolate their work:

# Create isolated worktrees for parallel work
claude --worktree "Refactor the authentication system to use JWT
       with refresh tokens"

# This creates a new git worktree in .claude/worktrees/
# with its own branch, so changes don't conflict with
# other agents or your main branch

Worktrees give each agent its own copy of the repository. When the work is done, you review the changes and merge them:

# Review what the worktree agent produced
git diff main..worktree-branch

# Merge if everything looks good
git merge worktree-branch

This is essential for tasks that touch shared files like configuration, layouts, or utility modules.

Real Example: Two Courses in Parallel

Here is how parallel execution played out for creating two complete courses simultaneously:

Session setup:
- Course 1: RAG Engineering (14 lessons, EN + ES = 28 files)
- Course 2: LLM Fine-Tuning (12 lessons, EN + ES = 24 files)
- Total: 52 content files + 4 meta files = 56 files

Execution plan:
- Agent 1: RAG Engineering English lessons (14 files)
- Agent 2: RAG Engineering Spanish lessons (14 files)
- Agent 3: LLM Fine-Tuning English lessons (12 files)
- Agent 4: LLM Fine-Tuning Spanish lessons (12 files)
- Main: Meta files and course infrastructure (4 files + routing)

Time: All agents completed within 35 minutes
Sequential estimate: 3-4 hours

Result: 56 production-ready content files created in parallel,
each with proper frontmatter, 800-1200 words of content,
code examples, and consistent formatting.

The parallel approach was approximately 5-6x faster than sequential creation. The main overhead was the 10 minutes spent reviewing the combined output.

When to Parallelize

Parallelization works best when tasks are truly independent. Here is a decision framework:

Good Candidates for Parallel Execution

Independent file creation:

  • Different lessons in a course
  • Separate components that do not import each other
  • Test files for different modules
  • Documentation pages

Research and implementation simultaneously:

# Agent 1: Research
claude --background "Research the best approach for implementing
       WebSocket reconnection with exponential backoff. Summarize
       options and recommend one."

# Agent 2: Implementation of known parts
claude "While that research is happening, implement the WebSocket
       connection setup and message handling using the pattern we
       already have in the chat module."

Testing and development in parallel:

# Agent 1: Write tests for existing code
claude --background "Write comprehensive tests for all API routes
       in src/app/api/. Cover success cases, error cases, and
       edge cases. Use the existing test patterns."

# Main: Develop new features
claude "Add the user preferences feature while tests are being
       written for the existing code."

When NOT to Parallelize

Dependent changes: If Agent B needs the output of Agent A, they must run sequentially. For example, creating a database migration (Agent A) and then building an API that uses the new schema (Agent B).

Shared state modifications: If two agents modify the same configuration file, one will overwrite the other. Use worktrees or run them sequentially.

Sequential logic: Steps that must happen in order -- like build, then test, then deploy -- cannot be parallelized.

The Dispatcher Pattern

For complex projects, use a dispatcher pattern: one main session coordinates the work while background agents execute it.

# Main session acts as dispatcher
claude "I need to add a notification system to the app.
       Break this into independent tasks that can run in parallel."

# Claude responds with a task breakdown:
# Task 1: Database schema and migration (independent)
# Task 2: API endpoints (depends on Task 1)
# Task 3: UI components (independent of Tasks 1-2)
# Task 4: Real-time connection setup (independent)
# Task 5: Integration and wiring (depends on all above)

# Execute independent tasks in parallel
claude --background "Task 1: Create the notifications table migration
       with fields: id, user_id, type, title, message, read, created_at"

claude --background "Task 3: Build the NotificationBell component with
       dropdown panel, unread badge, and notification list items.
       Use mock data for now."

claude --background "Task 4: Set up the WebSocket connection for
       real-time notification delivery. Create the hook and provider."

# After Tasks 1, 3, 4 complete:
claude "Task 2: Build the notification API endpoints using the
       migration from Task 1"

# After all tasks complete:
claude "Task 5: Wire everything together — connect the UI components
       to the API, hook up the WebSocket for real-time updates,
       and replace mock data with real API calls"

The dispatcher pattern is how you scale from parallel file creation to parallel feature development. You think about dependency graphs and execute independent branches simultaneously.

Managing Parallel Output

Running multiple agents creates a review bottleneck if you are not organized. Here are strategies for managing the output:

Review as agents complete: Do not wait for all agents to finish. Review each one as it completes. This staggers your review work and catches issues early.

Use git status to track changes:

# See what each agent has created or modified
git status

# Review changes by specific paths
git diff -- src/content/courses/rag-engineering/
git diff -- src/components/CourseCard.tsx

Commit in logical chunks:

# Commit each agent's work separately for clean history
git add src/content/courses/rag-engineering/*.en.mdx
git commit -m "feat: add RAG Engineering course English lessons"

git add src/content/courses/rag-engineering/*.es.mdx
git commit -m "feat: add RAG Engineering course Spanish lessons"

Handle conflicts immediately: If two agents accidentally modify the same file, resolve the conflict right away before it compounds with additional changes.

Scaling Your Parallelism

Start small and increase parallelism as you get comfortable:

  1. Week 1: Run one background agent while working in your main session. Get used to reviewing async output.
  2. Week 2: Run two background agents simultaneously. Practice the dispatcher pattern on small projects.
  3. Week 3: Use worktrees for parallel feature development. Coordinate agents on a larger task.
  4. Week 4: Full parallel execution -- multiple agents, worktrees, and the dispatcher pattern working together on a significant project.

The learning curve is not about the tools. It is about developing the mental model for thinking in parallel -- identifying independent work streams, managing dependencies, and reviewing output efficiently. Once you build that skill, you have access to the full 5.7x multiplier.