9f4bf8c452
Files added by PR #2008 that were not in main were dropped during the merge. Restore all src/, docs/, and scripts/ files from the pre-merge PR head. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
62 lines
2.2 KiB
Markdown
62 lines
2.2 KiB
Markdown
# Parallelization Strategy
|
||
|
||
### Core Principle
|
||
|
||
> Parallelize across boundaries, serialize within them.
|
||
|
||
The quality of parallelization is directly determined by the quality of interface definitions.
|
||
|
||
### The Diamond Pattern
|
||
|
||
```
|
||
Planning (narrow, serial)
|
||
↓
|
||
Fan Out (parallel execution)
|
||
↓
|
||
Convergence (integration verification)
|
||
↓
|
||
Fan Out (next parallel set)
|
||
```
|
||
|
||
### Phase-by-Phase Strategy
|
||
|
||
#### Planning: Mostly Serial, with Parallel Spikes
|
||
- High-level decomposition must be serial (one coherent act of reasoning)
|
||
- **Parallelize uncertainty resolution:** Multiple spikes investigating different risks simultaneously
|
||
- Output: A dependency graph that explicitly identifies what can be parallelized
|
||
|
||
#### Execution: Massive Parallelization with Right Topology
|
||
|
||
| Work Type | Strategy |
|
||
|-----------|----------|
|
||
| **Independent leaf tasks** | Embarrassingly parallel — one agent per module |
|
||
| **Dependent chains** | Serial within chain, but chains run in parallel |
|
||
| **Convergence points** | Strictly serial — integration verification |
|
||
|
||
**Critical insight:** The frontend doesn't need the real API — it needs the API *contract*. Once contracts exist, both sides build in parallel.
|
||
|
||
#### Testing: The Most Interesting Story
|
||
- **Unit tests:** Same agent, same context, atomic with code
|
||
- **Cross-task tests:** All parallel by definition
|
||
- **Integration tests:** Parallel across different boundaries
|
||
- **E2E tests:** Serial (exercises whole system)
|
||
|
||
#### Verification: Deliberate Redundancy
|
||
- **Adversarial verification:** Separate reviewer agent with fresh context evaluates against spec
|
||
- **Red-team parallelism:** Agent tries to break the implementation
|
||
|
||
### Coordination Rules
|
||
|
||
- Agents communicate through the **filesystem**, never directly
|
||
- Each agent works on a **branch** — merge on success, discard on failure
|
||
- One agent per file at a time (file locking)
|
||
- Optimal concurrency: **3–8 simultaneous agents** for most projects
|
||
|
||
### Anti-Patterns
|
||
|
||
- ❌ Don't parallelize tasks that modify the same files
|
||
- ❌ Don't parallelize interacting decisions
|
||
- ❌ Don't skip convergence/integration verification
|
||
- ❌ Don't over-parallelize (coordination tax eats gains above ~8 agents)
|
||
|
||
---
|