When many coding agents share one codebase, delivery must handle concurrency

Patrick Debois describes a multiplayer software factory: multiple people and coding agents working concurrently on the same delivery pipeline and codebase.

A solo developer may already run several agents locally but still has to make decisions, merge changes and remember what each agent is doing.

Debois distinguishes sharing tools and context from a truly shared factory where people collaborate around the same task board and repository.

More agents can produce more pull requests, but they also increase conflicts, repeated rebases and test runs. One agent can even undo another agent’s change.

The queue includes feature work, incidents caused by agents and maintenance of the factory itself. Debois proposes designing for concurrency as a routine part of delivery.

One response is to split work before coding: assign agents distinct domains, files or functions, using dependency information to find changes that can proceed independently.

Agents can claim tickets and announce the files they expect to touch. That visibility helps others avoid beginning overlapping work.

Isolation can extend beyond Git worktrees to separate machines, snapshots of databases, test data and mocked external services, limiting interference and outside effects.

When work collides, agents might wait, retry or renegotiate their plan. Debois also imagines agents resolving some merge conflicts and anticipating changes in progress.

A clean textual merge is not enough. In his example, one change switches invoice totals to cents while another changes reporting; tests can pass even if the combined intent is wrong.

He suggests checking whether the intent of concurrent changes remains consistent, not only whether their lines conflict.

Speculative merge trains test compatible combinations ahead of time, allowing changes that remain compatible to proceed even when another change fails.

On the human side, a shared task board gives the team visibility into work underway and changes coming. More concurrent agents also create more demands on people’s attention.

An agent can join a team conversation, gather input from several people and refine a ticket by asking about requirements and tests.

Debois says sales, marketing and support can participate in that workflow. Their experiments can enter the same engineering pipeline and be reviewed rather than remaining isolated prototypes.

For a stuck agent, he describes a hybrid approach: open a development environment with the agent’s context, let a person investigate, then hand the work back.

A request with concrete options can make a decision easier for a person, while still allowing them to override the suggestions.

A shared decision log records who decided what and when. Both people and agents can use it to recover context in later sessions.

Changes should also be sized for human review. Optimizing only to avoid agent conflicts can create changes too large for a person to inspect effectively.

Automated review, better context and evidence such as screenshots or tests can reduce the work passed to reviewers and help them see what changed.

The amount of human review should reflect risk. Debois contrasts lower-impact documentation with sensitive changes such as authentication, and mentions gradual releases as a middle ground.

Risk also depends on recovery: teams can design for fast rollback, restore and resilience when something reaches production and goes wrong.

More changes also make communication harder. Different teams need a way to understand relevant changes in language suited to their work.

Debois recommends automating routine work while routing exceptions and meaningful decisions to people.

He expects a team similar to a platform team to maintain the agent infrastructure, shared skills, context, connections and monitoring.

Looking ahead, he considers personal agents that can participate in the shared board and answer other agents on a person’s behalf. He says the organizational model is still evolving.

He closes by inviting feedback and pointing to concurrent delivery research and the team’s work at Tessl.