Your Team's Agents Are All Shipping to the Same Code at Once with Patrick Debois, Tessl

As AI coding agents proliferate, software delivery must shift from a serial 'continuous delivery' model to a 'concurrent delivery' model designed for multipl

Your Team's Agents Are All Shipping to the Same Code at Once

Abstract

As AI coding agents proliferate within software teams, the serial assumptions underlying continuous delivery - bounded change volume, human-arbitrated merges, single-actor planning - break down. This synthesis examines a proposed alternative, concurrent delivery, in which simultaneous work by multiple agents and humans on a shared codebase and ticket board is treated as the routine case rather than an exception. Drawing on a maturity gradient from solo to multiplayer "software factories," the analysis documents a roughly tenfold increase in pull request volume under multiplayer operation, catalogues mechanisms for work-splitting and conflict resolution - including AST-based decomposition, ticket claiming, function-level merges, and speculative merge trains - and identifies intent conflicts as a failure class invisible to existing test-based tooling. Risk-proportional review, decision ledgers, and a dedicated "factory team" role emerge as organizational prerequisites. Practical implications center on redesigning CI/CD, review, and communication practices before concurrency, rather than after it causes failure.

1. Introduction

Software delivery pipelines have traditionally been serial by construction: code is built, tested, held for a release window, and merged to main. This structure assumes a bounded rate of incoming change proposals and treats human attention as the scarce coordinating resource. Autonomous coding agents violate both assumptions by generating far more proposed changes, far faster, than teams previously experienced.

A useful frame for this transition distinguishes three levels of maturity in the software factory - the assembled set of agents, context, skills, and loops that produce changes to a codebase. Solo factories involve individuals running agents on their own laptops, making all merge and planning decisions personally, and serving as the system's central memory. Shared factories standardize setups, context, skills, and loops across a team. Multiplayer factories involve multiple humans and agents collaborating concurrently on the same ticket board and the same codebase.

The multiplayer stage surfaces two structural tensions: on the code side, every participant wants to merge into main; on the human side, multiple participants collaborate on the same board. The central thesis is that these tensions require a reconceived delivery model rather than incremental tooling fixes. As one formulation states, the goal is to "flip this from being this concurrency and it being an exception to becoming the routine." This analysis covers the pressures introduced by increased concurrency, the technical strategies for work-splitting and merge handling, the human-collaboration and review implications, and the organizational role changes required to sustain multiplayer factories at scale.

2. Background and Related Work

The prevailing reference model remains the software development lifecycle (SDLC) loop, and most current agent harnesses stay close to it. The observation that "a lot of the factories are just glorified loops as we would do with the SDLC" is accurate at solo-factory scale, where a single human arbitrates every collision, but it does not anticipate the pressures of concurrent, multi-actor operation.

Two prior bodies of practice inform the proposed alternative. Platform engineering disciplines established around Kubernetes and cloud infrastructure provide the template for a dedicated team owning shared substrate on behalf of product teams - a pattern now proposed for a "factory team." Merge queue and CI/CD literature supplies the concept of speculative evaluation of queued changes, adapted here into "speculative merge trains." A further reference point is informal "vibe coding" by non-engineers, which the multiplayer factory supersedes by routing non-engineer contributions through the same pipeline, knowledge, skills, and loops as engineering work, rather than through unmanaged ad hoc prompting.

3. Core Analysis

3.1 Pressures from Increased Concurrency

Enabling a multiplayer factory increases pull request volume by approximately a factor of 10, which raises productivity but introduces compounding tension. Each additional merge increases the probability of conflicts, including cases where agents revert one another's changes without awareness of the other's intent. Because merging frequently triggers rebases and test reruns across other open PRs, CI/CD pipelines slow down and become more computationally expensive as volume rises. The PR backlog grows not only from feature work but from agent incidents and factory maintenance tasks such as skill or loop improvements, meaning the queue reflects operational overhead as well as product output. This set of pressures motivates the shift from continuous delivery - which serializes concurrency away - to concurrent delivery, which architects for it directly.

3.2 Work-Splitting and Planning Strategies

Before coding begins, work is divided into units - for example, separating authentication from payment logic - with AST (abstract syntax tree) graphs used to identify good split points in the codebase. Agents can operate at varying granularity, down to specific files, functions, or individual edits. To prevent overlapping effort, agents "claim" tickets during planning and announce which files or changes they intend to modify, a mechanism analogous to optimistic locking at the task level. During execution, work trees provide isolation between agents, and broader isolation techniques - dedicated machines per agent, locked API versions, database snapshots and test data, and "digital twins" that mock external systems - prevent agents from interfering with one another's environments even when working on related code.

3.3 Conflict and Merge Resolution

Three collision strategies are identified: waiting, retry-after-wait with requeue, and renegotiation, in which the plan itself is dynamically altered to avoid interference. When merge conflicts occur, systems can simply rerun to check if the conflict resolves, or pursue "smarter" merges that operate at the function level rather than the line level, auto-fixing conflicts and anticipating incoming changes from other agents before they land.

A more consequential failure mode is the intent conflict: two PRs can each pass their tests and merge cleanly while contradicting each other's business logic. The canonical example involves one PR changing invoice totals to be denominated in cents while a concurrent reporting PR still expects euros - both merge successfully, but the resulting system is incorrect. Because existing test suites validate code behavior in isolation, intent conflicts are structurally invisible to them, requiring agents to check cross-PR intent consistency explicitly. Speculative merge trains address throughput by evaluating all incoming PRs pairwise for compatibility, allowing compatible sets to merge immediately while isolating incompatible ones for separate handling, which accelerates the merge queue relative to strictly sequential processing.

3.4 Human Collaboration and Risk-Based Review

Shared task boards increase visibility into in-progress work but correspondingly increase the demand on human attention, since agents raise clarifying questions throughout execution. Rather than posing open-ended questions, agents are expected to present humans with discrete decision options, reducing cognitive load; these decisions are recorded on a shared decision ledger, traceable and reusable by humans or agents in future sessions. Review depth is scaled to risk and impact rather than applied uniformly: low-impact changes such as documentation require minimal review, while high-impact areas such as authentication logic warrant deeper human scrutiny. Canary releases with post-deployment monitoring provide a middle-ground risk control, supplemented by architectural mitigations such as fast data-restore and fast node rollback.

4. Technical Insights

Several implementation-relevant findings merit emphasis. First, the tenfold PR volume increase under multiplayer operation is not merely a throughput statistic but a systemic stressor on CI/CD cost and latency, since each merge can trigger cascading rebases and retests elsewhere in the queue; pipelines sized for solo-factory volume will not scale without redesign. Second, AST-based decomposition offers a structural, rather than heuristic, basis for splitting work among agents, though its effectiveness depends on codebase modularity. Third, function-level merge resolution is a meaningful improvement over line-level diffing but does not by itself solve intent conflicts, which require semantic cross-PR checks beyond syntactic merge logic - this remains an open engineering problem rather than a solved one. Fourth, isolation mechanisms (per-agent machines, locked APIs, database snapshots, digital twins) trade infrastructure cost for reduced collision risk, and teams must judge how much isolation is proportionate to their concurrency level. Finally, speculative merge trains shift cost from sequential blocking to pairwise compatibility evaluation, which scales better with PR volume but requires compatibility-checking logic that itself consumes compute and may lag behind the newest failure modes.

5. Discussion

The intent-conflict problem is the most significant conceptual contribution of this analysis, because it exposes a blind spot in existing software engineering practice: passing tests have never guaranteed business-logic coherence across concurrently developed features, but this gap was previously masked by the low concurrency of human-paced development. As agent-driven concurrency rises, this latent risk becomes acute, and no current standard tooling addresses it directly.

This points to a broader industry trend: the delivery infrastructure required to support agent-driven development is becoming its own distinct layer, separate from the SDLC loops that agents execute. Analytics, planning, and merge-handling infrastructure are described as an emerging "developer infrastructure" layer, suggesting that the market for orchestration tooling may bifurcate from the market for agent harnesses themselves. Organizationally, this implies a new specialization - a "factory team" analogous to a platform team for Kubernetes or cloud infrastructure - responsible for skill and context freshness, system connections, and monitoring the factory's own health rather than product features. A remaining gap is measurement: no quantitative framework is presented for detecting intent conflicts systematically, and the degree to which risk-based review policies can be automated versus requiring human judgment calls remains unresolved.

6. Conclusion

This synthesis establishes that the shift to multi-agent software delivery is not an incremental scaling problem but a structural one, requiring a redesign from continuous delivery to concurrent delivery as the default operating mode. Key contributions include a maturity model for software factories, a catalogue of work-splitting and merge-resolution mechanisms, and the identification of intent conflicts as a novel failure class requiring semantic rather than syntactic validation.

Practically, teams approaching multiplayer-factory scale should anticipate CI/CD cost growth ahead of time, invest in ticket-claiming and isolation infrastructure before concurrency causes collisions, and establish risk-proportional review policies rather than uniform review gates. Establishing a dedicated factory-team role to own the health of the factory itself - rather than treating it as incidental infrastructure - is likely to become a prerequisite for sustaining multi-agent delivery at scale.

Sources

• Your Team's Agents Are All Shipping to the Same Code at Once - Patrick Debois, Tessl - Original Creator (YouTube)
• Analysis and summary by Sean Weldon using AI-assisted research tools

About the Author

Sean Weldon is an AI engineer and systems architect specializing in autonomous systems, agentic workflows, and applied machine learning. He builds production AI systems that automate complex business operations.

LinkedIn | Website | GitHub