How to Run Parallel Coding Agents Without Losing Control

How to Run Parallel Coding Agents Without Losing Control

Run parallel coding agents only across bounded tasks with stable contracts. Isolate execution, minimize permissions, queue integration, protect the target branch, and limit concurrency to the number of changes the team can independently review and safely combine.

More agents increase execution. They do not automatically increase accepted software.

The morning-after problem

The fantasy is a team of agents coding all night. The morning reality can be twenty branches, overlapping assumptions, green self-written tests, new dependencies, and a review queue no one understands.

Dalton describes that tension in Venture Step episode 107. Google Jules made it easy to imagine many repository tasks running at once. He also asked how one person could review hundreds of commits.

That question should set the concurrency limit.

flowchart LR
    A["Bounded task queue"] --> B["Contract and risk review"]
    B --> C["Isolated agent execution"]
    C --> D["Independent pull-request review"]
    D --> E["Integration queue"]
    E --> F["Protected branch checks"]
    F --> G["Release and observation"]
    G --> H["Correction and task learning"]

Starting work is near the beginning. Useful throughput appears after integration and release.

Set capacity before concurrency

Estimate how many changes the team can review, integrate, and observe during the period.

If one engineer can deeply review two medium-risk pull requests in a day, starting twenty does not create ten times the throughput. It creates delay, stale branches, context switching, and pressure to lower the review standard.

Reserve capacity for failed tasks, revisions, conflicts, security escalation, and ordinary human work. Agent output is variable, so a queue that operates at theoretical maximum will become unstable.

Track time to accepted change, revision count, conflict rate, escaped defects, rollback, and reviewer comprehension. Do not optimize only for tasks completed or lines generated.

Select work with stable boundaries

Parallel tasks should share as little mutable meaning as possible.

A documentation correction, missing unit test, contained adapter, independent migration rehearsal, and separate static-analysis fix may run safely at the same time. Two tasks that redesign the same authentication flow, schema, dependency graph, or public interface probably should not.

Create a dependency graph before dispatch. Mark shared files, generated artifacts, configuration, schemas, APIs, and libraries. Serialize tasks that depend on an unresolved upstream decision.

Different files do not guarantee independence. Semantic conflict often crosses file boundaries.

Define a contract for each task

Each task needs an outcome, scope, non-goals, starting commit, owned interface, acceptance criteria, required tests, permission set, and stop conditions.

Name which files or directories may change where practical. Name interfaces that must remain stable. Tell the agent to stop when the requirement conflicts with the repository, needs a migration, requires a new credential, or expands beyond the approved area.

Repository-level instructions such as AGENTS.md should hold durable conventions. The task prompt should hold the specific contract.

A plan review should compare the proposed work with that contract. Jules supports plan feedback, but the current web documentation says plans may eventually auto-approve. Its API requires an explicit setting when manual approval is mandatory.

Pin the starting state

Record the exact base commit for every task.

As other changes merge, the task's assumptions can become stale. The returned change should identify its original base and be tested again after rebasing or entering the merge queue.

Current Jules task documentation says each task has its own VM, logs, environment, and code changes. That protects task execution from sharing one working directory.

It does not make the result current. A clean task branch can still conflict with the product state that exists when review begins.

Isolate execution and credentials

Use a separate branch or worktree and a separate ephemeral environment for each task. Prevent direct pushes to the protected target branch.

Grant only the repository, package registry, test service, and environment values required for that task. Prefer synthetic data and dedicated test accounts.

Jules VMs have internet access according to the current FAQ. Setup scripts and dependencies can therefore create network and supply-chain effects.

Do not share one broad production credential among agents. A compromised or confused task should have a small blast radius and a clear revocation path.

NIST's Secure Software Development Framework treats protected development environments, software integrity, code review, testing, provenance, and vulnerability response as related practices.

Make interface changes explicit

Parallel agents need contracts between their tasks.

If one task changes an API, schema, event, file format, dependency version, or shared library, publish that decision before dependent tasks begin. Use a small design record or interface fixture that every task references.

Consider a two-stage sequence. First merge the backward-compatible interface. Then run consumers in parallel. Remove the old behavior only after migration evidence exists.

Agents should not independently invent different versions of the same future contract.

Queue integration

Do not merge every successful branch as soon as it appears.

Order changes by dependency and risk. Rebase or update against the current target. Run required checks on the exact commit or merge result that will enter the protected branch.

GitHub's protected-branch guidance supports required reviews, current approval after new commits, status checks, code owners, conversation resolution, merge queues, and restrictions on bypass.

The merge-queue documentation explains that queued changes can be tested with the latest target and earlier queued changes.

Automation should make the accepted order explicit rather than race to main.

Review risk, not agent identity

Do not apply one review standard to every generated change.

A text correction may need a quick source check. An authentication change, migration, external API integration, workflow permission, or claims-related decision needs deeper domain and security review.

Agent-on-agent review can identify obvious defects, summarize scope, compare patterns, or route a change to a specialist. It does not provide independent authority when the reviewing agent shares the same context, model, assumptions, or incentives.

The human reviewer remains accountable for accepting the behavior into the system.

Use the full procedure in [[How to Review an AI-Generated Pull Request]].

Observe the active fleet

Maintain a view of queued, planning, awaiting approval, running, paused, failed, completed, under review, conflicted, integrated, released, and rolled-back work.

Record the repository, base commit, task owner, agent or service identity, prompt, plan, permissions, environment, start time, current state, changed interfaces, pull request, reviewer, and release.

Jules exposes task histories and states in its repository view and API. The current sessions reference defines queued, planning, awaiting approval, awaiting feedback, in progress, paused, completed, and failed states.

Your operating system needs the later states too. Agent completion is not integration completion.

Define stop conditions

Pause or terminate a task when it needs an unapproved secret, reaches outside its repository boundary, adds a consequential dependency, changes a public interface, encounters conflicting instructions, produces unusual volume, retries repeatedly, or cannot reproduce the required test.

Stop the fleet when conflict or review backlog crosses the team's threshold. Continuing to generate more code while the acceptance system is failing makes recovery harder.

Deleted tasks can remove the task record in some products. Preserve the evidence needed for incident or audit review before destructive cleanup.

Release in small groups

Even independently reviewed changes can interact in production.

Use feature flags, staged rollout, backward-compatible migrations, monitoring, and rollback. Release a small group, observe the system, then expand.

Connect operational signals to the originating pull requests and tasks. When a defect appears, the team should be able to identify which change, requirement, agent session, review, and deployment introduced it.

A responsible concurrency rule

The safe number of parallel agents is the smaller of execution capacity and acceptance capacity.

Acceptance capacity includes task design, plan review, independent code review, integration, security and domain review, deployment, observation, and recovery.

Start with two independent low-risk tasks. Measure the full path to accepted work. Increase concurrency only when the queue remains understandable and the review standard holds.

The goal is not to keep every agent busy. It is to keep the software coherent.

Read [[Asynchronous Coding Agents vs IDE Assistants]] and [[What Is Google Jules|What Is Google Jules?]], then continue to the E107 episode story, What Happened When Jules Built a Go Backend. The publishing agent should activate the episode-story link only after its stable public route exists.

AI assisted with research organization and drafting. Dalton Anderson remains responsible for the analysis and publication decision.