Scaling Loop Engineering: Running Parallel AI Clones on Trunk Without git worktree

In Part 1, I covered how wrapping a living specification in a quantifiable /goal loop lets an AI agent plan, implement, and verify a feature without human babysitting.

Once a single /goal loop works reliably, you hit the next bottleneck: serial checkout throughput.

One checkout is a single queue: one working tree, one Git index, one set of local ports, and one database container. If you have 15 specs in your backlog, running them one by one leaves your machine and your multi-harness token quotas idle while you step away.

Most engineers reach for git worktree to run parallel agents. If you only use a single AI harness and use feature branches, git worktree is often enough.

However, because I run three harnesses interchangeably (Antigravity CLI, Claude Code, and Codex) and practice strict trunk-based development (committing straight to main with no branches), git worktree broke down immediately. Instead, I use 8 separate full clones (Clone A through Clone H) committing straight to main.

Here is when git worktree is fine, why it fails across multiple harnesses on trunk, and how to review eight lanes of work in one place.

Why Full Clones Beat git worktree When You Run 3 Harnesses on Trunk

Every design in an agent-driven repo must minimize what it costs to keep correct across future prompts:

Because my agent rules, specialist prompts, and skills are generated from a single vendor-neutral source into all three harnesses, a clone is completely harness-agnostic. I can run Antigravity CLI in Clone B, Claude Code in Clone C, and Codex in Clone D simultaneously. If one harness hits its 5-hour usage cap mid-task, I open a different harness in that exact same clone and it resumes from the task handoff file and git diff without losing a step.

I also rejected domain-owned lanes (assigning one clone to planning and another to account). In an audit of 16 backend commits, 9 touched two to four domains, 12 changed the OpenAPI contract, and 7 added a database migration. Real features cut across domains, so every clone acts as a general-purpose worker pulling from one shared queue.

Coordinating 8 Clones Without a Central Server

When you broadcast /goal across eight tmux panes at once, how do you stop clones from grabbing the same spec or overwriting each other’s files? Git itself is the coordinator:

1. Atomic Git Push Is the Lock: Task plans live in tracked markdown files on main. To claim a task, a clone writes its ID into the task file and pushes to main. If Clone B and Clone C race within 50 milliseconds, Git accepts one push and rejects the other; the losing clone rebases and claims the next ready task. If a clone goes idle for 20 minutes (rate limit or crash), its lock releases automatically.
2. File-Disjoint Concurrency (2x Faster): Every planned task explicitly lists the files it will touch (.java, .tsx, .py). Two clones run in parallel whenever their file lists do not overlap (taskA.files & taskB.files == empty), cutting multi-task build times in half.
3. Auto-Healing Shared Seams on Land: Full-stack tasks inevitably meet at two shared seams: generated OpenAPI clients and numbered database migrations (V{n}__*.sql). A local landing lock serializes pushes one at a time: it rebases onto main, regenerates OpenAPI clients from source instead of hand-merging them, auto-renumbers colliding migrations (V22 to V23), and runs pre-push test gates before pushing.

Solving the Human Review Bottleneck

When eight clones land multiple specs an hour, the human engineer is the bottleneck. Two rules keep you out of review hell:

• Park Tasks, Never Clones: Human gates are reserved strictly for actions that cost money, touch production, or require an irreversible product trade-off. When a clone hits a human gate, it lands its commits, parks that task, and immediately claims the next ready spec.
• Verify Once in Clone A: You never inspect eight terminals. When the queue is empty, Clone A is the only checkout you open. Its agent pulls main and generates one Unified Customer Journey Walkthrough grouping every autonomous design decision and step-by-step browser test script by spec.

# Broadcast across Clones A..H via tmux, then review once in Clone A:
/goal Work through the approved spec queue, claiming and landing ready tasks until the queue check reports zero ready specs and zero active lanes.

The Takeaway

1. If you use one harness and feature branches, git worktree is fine; if you use multiple harnesses (Antigravity CLI, Claude Code, Codex) or commit straight to main, use full clones so any tool can take over any folder without branch lock-in.
2. Shift ports and database volumes by folder name (a through h) so 8 checkouts can run tests simultaneously on the same machine without colliding.
3. Lock with git push and file lists instead of building complex external orchestrators.
4. Auto-regenerate contracts and renumber migrations on rebase so shared seams never block parallel lanes.
5. Build in N clones, verify in 1 (Clone A).

Once you can run up to eight clones in parallel, the next question is knowing how long a plan will take and whether a specific spec actually benefits from 2 lanes or 7. In Part 3, I cover how I use git log and the plan’s dependency graph (DAG) to forecast agent build time and pick the exact number of lanes to run.

(If you want to try what I’m building with this workflow, you can start 7 days free on Max, no card needed.)