Five pages, five agents, one design file — zero merge conflicts
A parallel agent fleet implemented five production marketing pages 1:1 from design files in about five minutes of wall clock. The interesting part isn't the speed — it's the three rules that made the output shippable.
Five marketing pages needed to go from design file to production the same afternoon — a pricing page from scratch, a catalog rebuild, and fidelity passes on three more. One agent per page, run in parallel, done in roughly five minutes of wall clock. Every page shipped in the next deploy. The speed is the demo; the discipline is the product. Three rules did the work.
Rule 1 — partition by file ownership. Each agent owned its route's files and was explicitly forbidden from touching shared ones (layout, nav, middleware). Shared-file changes happened once, by the orchestrator, before the fleet launched. Merge conflicts didn't get resolved — they got made impossible.
Rule 2 — a shared rulebook beats clever prompts. Every agent got the same contract: the reference implementation to imitate, the design-to-route link map, and a hard honesty rule — never ship the mock's invented numbers; wire real data with honest fallbacks; label sample UI as sample. One agent's report came back listing seven places where it had replaced fabricated stats with real ones. That list is the deliverable a human reviewer actually wants.
Rule 3 — a gate they can't negotiate with. Each agent had to leave the TypeScript compiler exiting zero and report it honestly; the orchestrator re-ran the gate across the merged result before shipping. Agents report what they did; compilers report what is true. Only one of those goes in the release decision.
The same shape ships migrations, refactors, and audit sweeps: scout the shared surface first, partition the rest, contract the rules, gate the merge. If you've got a backlog that parallelizes and a team that doesn't scale, that's the system I build.