Shipping 4 Features in 54 Minutes — The Parallel Stress Test

What happens when you push a framework designed for sequential work to handle four features simultaneously?

Context

After proving that the PM framework could deliver single features at high velocity (2.1 min/CU for auth flow, 5.1 min/CU for AI engine), the natural question was: does it scale horizontally? Can four independent features advance through the full lifecycle in parallel without degrading quality, producing merge conflicts, or overwhelming the coordination layer? This experiment answers that question with 54 minutes of measured data.

The Setup

4 features, running simultaneously through 8 lifecycle phases:

The hypothesis: Framework optimizations (skill-on-demand loading, cache compression, batch dispatch) should enable 4 parallel workflows without significant quality degradation. Expected bottleneck: context window pressure at phase transitions.

The actual result: Context window was NOT a bottleneck. The single bottleneck was infrastructure (file write permissions for subagents), not architecture.

The Results

Zero Quality Degradation

Throughput Numbers

Phase Timing

How Same-File Parallel Writes Worked

The analytics phase proved that 3 agents can edit the same source files simultaneously. Three agents each added events to the same analytics provider and service files, using section markers for isolation. Git's sequential commit model meant each agent saw the previous agent's additions.

Why it worked: Additive-only changes at different positions, section-marker isolation, and sequential commits. Each agent wrote to its own marked section.

The honest caveat: This success is partially dependent on agents writing to different positions. If two agents modified the same function or the same line, conflicts would occur. A structural solution (region extraction and reconstruction) was identified as a research direction but not yet implemented.

What Broke Down

Critical: Subagent file permissions. Every dispatch that needed to write to feature state files was denied. 16 of 31 dispatches (52%) were affected. The controller had to batch all state updates manually, adding ~10 minutes of overhead. Without this, the experiment would have completed in ~44 minutes.

Low severity: Agent execution time variance. Agent execution ranged from 43 seconds to 987 seconds (23x spread) for similar-complexity tasks. More tool uses did not produce better quality -- the agent with 68 tool uses produced identical output to the agent with 7 tool uses.

Non-issue: Context window. The expected bottleneck never materialized. Agent results are summaries (not full file contents), state updates are formulaic, and skill-on-demand loading keeps irrelevant context out.

Why Parallel Execution is Super-Linear

Serial v5.1 produces ~22 CU/hour. Parallel v5.1 produces 48.8 CU/hour -- 2.2x the serial rate, not just 1x. The super-linear improvement comes from:

1. Amortized batch updates -- one script updates 4 state files in 2 seconds vs 4 separate operations
2. Controller learning -- after phase 1, the controller adapted prompts to avoid permission failures, reducing overhead in subsequent phases
3. Agent independence -- features don't share code paths early in the lifecycle, so coordination cost is zero

Decomposing the 12.4x headline:

• Serial framework improvement (v5.1 vs v2.0): ~4.2x
• Parallel execution speedup (4 features vs 1): ~2.9x
• Combined: 4.2 x 2.9 = 12.2x (consistent with the reported 12.4x)

Normalized Velocity

The combined 1.23 min/CU is 2.4x better than the power law prediction for the 13th iteration, suggesting parallelism provides super-linear improvement beyond framework learning effects.

Key Takeaways

• The framework crossed the threshold from "helpful tool" to "force multiplier." It doesn't just organize work -- it makes previously impossible workloads achievable. 4 features in 54 minutes with zero quality degradation was not possible at any prior framework version.
• The bottleneck was infrastructure, not architecture. File permissions, not context windows or coordination overhead, were the only blocking issue. This means the architecture has headroom.
• 12.4x throughput vs baseline decomposes cleanly into ~4x serial improvement and ~3x parallel speedup. Both are independently valuable and independently improvable.
• 35 tests, 0 failures, 0 merge conflicts across 4 simultaneous features is the quality story. Speed without quality is not a feature.