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)

💬 AI Colearning Prompt​

"Why must features be merged in dependency order? What breaks if Feature 003 (Feedback) merges before Feature 001 (Upload)?"

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.

🎓 Expert Insight​

In AI-native development, merge conflicts are feedback on your decomposition quality, not git skill. Clean merges = excellent decomposition. Many conflicts = rethink system boundaries. This insight scales: at 10 agents, poor decomposition becomes chaos; good decomposition enables autonomous parallel work.

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?

🤝 Practice Exercise​

Ask your AI: "I had [N] merge conflicts during integration (describe conflicts). Analyze what these conflicts reveal about my feature boundaries. Suggest how to redesign the decomposition to eliminate conflicts."

Expected Outcome: Understanding how to use merge conflicts as strategic feedback for improving system decomposition.

Try With AI​

Ready to validate your parallel implementation and analyze integration feedback? Test your decomposition thinking:

🔍 Explore Merge Conflict Analysis:

"I merged 3 feature branches and encountered [N] conflicts in these files: [list files with conflict details]. Analyze what these conflicts reveal about my decomposition quality: (1) Were these features truly independent? (2) What shared concerns caused conflicts (state, dependencies, interfaces)? (3) What decomposition patterns would have prevented these conflicts? (4) How should I decompose differently next time?"

🎯 Practice Non-Blocking Coordination:

"I'm running 3 parallel /sp.implement sessions across worktrees. Guide me through non-blocking coordination: (1) How do I prevent one agent from blocking others? (2) What signals indicate a dependency bottleneck? (3) How should I sequence merges to minimize integration risk? (4) If feature-001 takes longer than expected, how do I adjust feature-002 and feature-003 timelines? Create a coordination playbook."

🧪 Test Integration Strategy:

"I have 3 completed features ready to merge: feature-001 (base), feature-002 (depends on feature-001), feature-003 (independent). Walk me through the optimal integration strategy: (1) What's the merge order? (2) What tests do I run after each merge? (3) How do I validate that integration didn't break individual features? (4) If I discover a breaking change during integration, how do I isolate and fix it?"

🚀 Apply to Scale:

"I'm planning a system with 7-9 parallel features. Based on my 3-feature experience, help me scale my approach: (1) What decomposition principles prevent integration pain at scale? (2) How do I identify and sequence dependencies across 9 features? (3) What's my critical path for integration? (4) How many integration conflicts should I expect if decomposition is good vs bad? Design my scaled orchestration strategy."