Skip to main content

Parallel Implementation & Integration: Proving Decomposition Works

The Critical Test: From Plans to Working Code​

Can you actually build all three features in parallel, integrate them cleanly, and ship a working system?

This lesson proves whether your decomposition was actually good. Here's the profound insight: Clean merges mean excellent decomposition. Many merge conflicts mean your system design needs rethinking. You're not struggling with git—you're learning about system architecture.

This is where everything changes. Most teams decompose poorly, then waste weeks in integration hell. You're going to see why, experience it firsthand, and learn the patterns to avoid it. And here's what's remarkable: The patterns you learn with 3 features and 3 sessions scale directly to 5-7 agents running in parallel on production systems. Same principles. Different scale.

Let's build it.

Merge Strategy: Dependency Order​

Before implementing, identify your merge order based on dependencies.

Key principle: You must merge features in dependency order. If Feature B depends on Feature A, Feature A must merge first. If they're truly independent, order doesn't matter, but the act of merging in a deliberate order forces you to think about hidden dependencies.

Let's say you decomposed an Assignment Grader into:

  • Feature 001: Upload feature (students upload assignments, file validation)
  • Feature 002: Grade feature (apply rubric, calculate scores, store grades)
  • Feature 003: Feedback feature (generate feedback based on grades, display to students)

What's the dependency order?

  • Feature 001 (Upload) has no dependencies—merge it first
  • Feature 002 (Grade) needs Upload (to grade uploaded assignments)—merge second
  • Feature 003 (Feedback) needs both Upload and Grade (to generate feedback based on assignment grades)—merge last

Your merge order: Feature 001 → Feature 002 → Feature 003

Running Parallel Implementation​

This is where the 2.5x speed advantage manifests.

The Setup: Three Worktrees, Three Sessions​

Instead of this sequential approach:

Start Feature 001 → 45 min → Finish Feature 001
Start Feature 002 →         45 min → Finish Feature 002
Start Feature 003 →                  45 min → Finish Feature 003
Total: ~2 hours

You do this in parallel:

Session 1: Start Feature 001 → 45 min → Finish Feature 001 ┐
Session 2: Start Feature 002 → 45 min → Finish Feature 002 ├→ Total: ~50 min
Session 3: Start Feature 003 → 45 min → Finish Feature 003 ┘

The clock time is ~50 minutes (dominated by the longest feature), not 2+ hours.

Execute in 3 Terminals​

You already have 3 worktrees from Lessons 1-2. Now run implementations in parallel:

Terminal 1 (Feature 001 - Upload):

cd worktree-001-upload
claude
# Then: /sp.implement

Terminal 2 (Feature 002 - Grade):

cd worktree-002-grade
claude
# Then: /sp.implement

Terminal 3 (Feature 003 - Feedback):

cd worktree-003-feedback
claude
# Then: /sp.implement

Timeline (~90 minutes total for all 3):

  • T+0: All 3 sessions running
  • T+60-75 min: Features completing
  • T+90 min: All complete

vs Sequential: 270 minutes (3x speedup)

Integration: Merge in Dependency Order​

All 3 features are complete. Merge them into main:

Merge Sequence​

Step 1: Merge Feature 001

git checkout main
git merge feature-001-upload
pytest tests/  # Verify

Step 2: Merge Feature 002

git merge feature-002-grade
pytest tests/  # Verify

Step 3: Merge Feature 003

git merge feature-003-feedback
pytest tests/  # Verify all features work together

Expected: Clean merges if decomposition was good.

Handling Merge Conflicts​

If git says "CONFLICT", two features modified the same file section.

Example:

<<<<<<< HEAD
def validate(amount):
    return amount > 0
=======
def validate(amount):
    if amount <= 0:
        raise ValueError("Invalid")
    return True
>>>>>>> feature-002

Resolution:

  1. Decide which to keep (or combine both)
  2. Edit the file to resolve conflict
  3. Mark resolved: 
    git add filename.py
    git commit -m "Merge feature-002, resolved validation conflict"

Time Tracking & Reflection​

Record your results:

Sequential baseline: 270 min (90 min × 3 features) Your parallel execution: _____ min Speedup: _____x

Reflection:

  1. What enabled parallel work? (Clear specs? Independent files?)
  2. Did you have merge conflicts? (What did they reveal?)
  3. What would you decompose differently next time?

Try With AI​

Use Claude Code to analyze your merge experience:

I merged 3 feature branches and had [N] conflicts in these files:
- [list files]

What does this tell me about my decomposition quality?
What should I decompose differently next time?

Expected: AI identifies decomposition issues and suggests improvements.