The first client site took an afternoon. Three or four hours, one agent, one task at a time, me watching. For the second site I tried something else. Five agents working at the same time on the same project. It was done in about thirty minutes.
Why the naive version fails
Two agents in the same folder is a disaster. They overwrite each other's files, fight over the same git state, and you spend more time untangling the wreckage than you ever saved. "Just run five at once" does not work. I have the scars to prove it.
What made it work
Isolation. Each agent gets its own git worktree, a separate checkout of the same repository. They never share a working directory, so they physically cannot step on each other. Each one also gets a scope contract: the files it is allowed to touch, the files it must not, and a rule of one component per agent. They build in parallel, blind to what the others are doing.
Then I merge them back in one at a time. The first merge is always clean. The later ones occasionally conflict, which is fine, because merging is fast and sequential is exactly where a conflict belongs.
The honest part
These were two comparable sites, not a controlled experiment. The afternoon build and the thirty minute build were different projects, so the exact ratio is not science. But the pattern held on the builds after it, and the difference is not subtle.
The real cost is upfront. The work has to be genuinely divisible, isolatable, and mergeable. If it is not all three, parallel makes things worse, not better. I keep a short rule for that. Three yeses, or do it sequentially.
What it taught me
The speed did not come from faster agents. It came from giving each one a wall around its work so they could not collide. Same lesson as nearly everything else I build. The advantage lives in the boundaries.