Parallel Doesn't Mean Sequential Will Work Too
A 14-task security hardening sprint via parallel subagents, and the CI failure that only surfaces at scale.
The project needed security hardening: input validation, rate limiting, error wrapping, CI setup, pre-commit hooks, dependency automation, XML security. Standard checklist. The question was execution.
Fourteen distinct tasks. Each one had a clear scope, known dependencies, and enough context to hand off. That’s the profile for subagent-driven development: write the plan, dispatch agents in parallel waves, review results.
What I Tried
Wrote a 14-task implementation plan with code for each task. Grouped tasks by dependency—shared utilities went first, package-specific changes could run in parallel. Dispatched implementation agents in waves, using lighter models for configuration files and heavier ones for logic-heavy code. Reviewed each wave’s output before moving to the next.
Starting point: 29 tests.
What Actually Happened
Two hours later: 75 tests, CI passing on both Node 20 and Node 22.
One failure that didn’t show up locally: build ordering. When you run tasks locally, they run sequentially in the order you call them. GitHub Actions runs them in parallel across a matrix. A package was trying to build before its dependency had compiled—because locally, the dependency always ran first, and in CI, it could run in any order.
The fix was one line in the build config: “before you build this package, build everything it depends on.” But it only fails if you’ve never run it with actual parallelism.
The Part Worth Keeping
Parallel agents reveal the same class of problems as parallel CI jobs: ordering assumptions that local sequential execution hides. If your plan assumes “A finishes before B starts” because that’s how you’d run it manually, you need to make that dependency explicit—in the code, not just the plan.
The other observation: 14 independent tasks, handed off correctly, take roughly the same elapsed time as 3–4 sequential ones. The coordination overhead is real. It’s smaller than the parallelism gain.