AI Coding Agents and Merge-Queue Contention: Price the Rebase Loop

Coding agents can produce branches faster than a repository can validate and merge them. When arrival rate exceeds review and CI capacity, branches become stale, tests rerun, conflicts grow, and agents spend tokens repairing work that was correct when first generated. The useful metric is cost per landed change, not pull requests opened per hour.

Treat the merge queue as a shared constrained system. Measure pull-request arrival, service rate, time waiting, CI duration, review duration, rebase frequency, conflict rate, superseded work, and completion. Segment human and agent-authored changes without assuming either cohort is inherently better.

Find the Binding Stage

A queue can wait for reviewers, required checks, scarce test environments, deployment previews, security scans, or serial merge validation. Instrument each state transition. One total cycle-time metric cannot show whether another coding agent, faster runner, smaller change, or better review routing will help.

Report p50 and p95 wait time by repository and change class. Large generated migrations may occupy CI for hours while small fixes wait behind them. A monthly average makes the system look healthy until a release burst creates a costly backlog.

Calculate the Rebase Loop

For every synchronization attempt, add model input and output tokens, tool calls, sandbox runtime, CI, previews, security scans, and reviewer effort. If 400 monthly agent pull requests each rebase 1.5 extra times, and every cycle costs $0.80 in infrastructure plus six reviewer minutes at $100 per hour, the loop costs $10.80 per cycle or $6,480 monthly.

Count discarded branches too. Work closed because another change landed first still consumed generation, tests, and review. Attribute it to the feature or maintenance program that created the duplicate demand rather than hiding it outside the landed-change denominator.

Control Arrival Rate

Reserve queue capacity before launching agent batches. Limit active pull requests per repository, dependency area, and reviewer group. Use dependency graphs so changes touching the same core files run sequentially while independent work proceeds in parallel. More agents are useful only when downstream service capacity exists.

Prefer small coherent changes with stable acceptance tests. Large diffs take longer to review and conflict with more branches; extremely small dependent diffs can create stacking overhead. Measure the relationship between changed files, lines, queue time, rebase count, and accepted outcome to find the local optimum.

Avoid Paying the Model to Wait

• Use event-driven wakeups when review, CI, or queue state changes.
• Cancel obsolete runs when a newer commit or duplicate task supersedes them.
• Preserve task state so an agent resumes without rereading the repository.
• Cap repair cycles and escalate structural conflicts to an owner.

Polling burns tokens and API calls while contributing nothing to the change. The queue system should wake the agent with a concise structured event and relevant failure evidence. Keep CI logs outside context and retrieve targeted sections.

Increase Service Capacity Carefully

Buy faster runners or add reviewers only after confirming their stage is binding. Parallel CI may increase infrastructure spend without lowering cycle time if merge validation remains serial. Cross-train reviewers, automate deterministic checks, and schedule large migrations away from peak interactive work.

Use cost per landed, non-reverted change and queue-adjusted cost per accepted task. Track rebase cycles, conflict repair, wait time, CI duplication, and reviewer minutes as diagnostics. Include defects discovered after merge so speed does not win by transferring cost to incidents.

Review Capacity With Demand

Forecast arrival bursts from scheduled agents, dependency updates, release trains, and incidents. Set warning thresholds before utilization reaches the point where tail latency accelerates. Pause low-priority generation when the queue is unhealthy.

A healthy system keeps enough slack for urgent human and agent work. Maximum utilization is not maximum throughput when variability and conflicts are high.

Run a Queue Control Trial

For two comparable weeks, cap active agent pull requests in selected repositories while leaving acceptance gates unchanged. Track arrival rate, queue age, landed changes, duplicate work, rebase cycles, CI minutes, reviewer load, post-merge defects, and urgent-task latency. Normalize for change size and release events.

A lower cap is successful if landed throughput and quality stay stable while rework and tail latency fall. If throughput drops, locate the idle stage before raising the cap. Keep a reserve for incidents and human changes. Publish the chosen limit with the evidence window and revisit it when CI, review staffing, repository structure, or agent behavior changes.

Bottom Line

Manage agent pull requests as demand on shared review and validation capacity. Instrument stages, reserve slots, cancel obsolete work, and wake agents on events. Optimize the whole path to a landed, durable change; opening branches faster is not an economic outcome.