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

Several coding agents can work on one laptop and still leave one person with a demanding job. The developer remembers what each agent is doing, makes the decisions and merges the results. Patrick Debois of Tessl calls this a solo factory. Behind it sits a familiar delivery pipeline that builds, tests and takes changes through merge and release. That pipeline can automate a great deal while still moving changes in serial order.

Sharing context, skills and the loops that agents run lets colleagues reproduce a setup. The coordination problem changes when those colleagues put their setups to work at the same time. Their agents all want to merge into the same main branch. The people share a ticket board and need to know which changes are coming. The developer who could keep the whole plan in memory on a laptop now sees only part of it.

Debois estimates that incoming pull request volume can rise almost tenfold when a multiplayer factory starts up. What that buys the team depends on what reaches release. Two agents can keep each other busy by undoing each other’s changes. Both produce work for the merge queue while the code goes back to where it started.

Why does landing one change make the rest of the queue more expensive? Consider two other PRs waiting when the first one merges. Each was tested against the previous state of main. In the pipeline Debois describes, each now has to rebase, bringing its changes onto the new base, and typically rerun its tests. The two waiting branches incur that cost independently. As the queue grows, a single successful merge can trigger more CI work and a longer wait for release.

Features also compete for approval with fixes for agent incidents and maintenance of the factory itself. Someone has to review changes to the skills and loops that produce the next round of PRs. Debois uses concurrent delivery for the design problem this creates. Simultaneous work is frequent enough to plan for it before coding begins.

Authentication and payments suggest a natural split between two agents. A graph of the code can help identify pieces that actually separate well. Where two tasks come close together, the assignment can get more precise, down to a file, a function or even individual edits within a file. Doing this during planning reveals how much independent work there is before the agents start.

An agent claims a ticket on the board so another agent leaves that task alone. It also announces which files it expects to touch and what it plans to change. The announcement serves a different purpose from the claim. Two agents can each own a different ticket and still discover that their plans involve the same function. Publishing the intended edits gives them a chance to spot that overlap while they can still adjust the work.

Separate Git worktrees give agents their own working files. Isolation can extend to the things those files depend on. An agent can have its own machine and context, a fixed API version, a database snapshot and its own test data. Mocks or digital twins can stand in for outside systems. An agent can then run an experiment without another agent changing the data underneath it or the experiment affecting the outside world. The resulting code will still need to meet everyone else’s changes on main.

A collision during execution leaves a choice about the plan already in flight.

• Wait and retry. Let one agent finish the contested work, then give the other another attempt.
• Requeue the task. Return the waiting work to the queue until the work it depends on is done.
• Renegotiate the split. Change who does what while the agents are working. If they can agree on separate edits, both can continue.

If the overlap survives until merge time, one option is to rerun the work and try the merge again. An agent could also inspect the whole function containing the conflicting lines and attempt a repair that accommodates both edits. An agent that can see a neighboring change coming could go further and adapt its own code while the other change is still in progress. That possibility depends on knowing what the other agent intends to do.

What unit does the report expect to receive? One PR changes the function that calculates an invoice total so it returns cents. At the same time, another PR changes how the total is reported. The reporting change still expects dollars. The edits can touch different lines and their tests can pass, yet the output of the calculation is the input to the report. A number calculated in cents would be read as a number of dollars.

Debois proposes having an agent compare the intents of the incoming PRs. For this pair, the agent would need to follow the total across the two changes and ask where the conversion to the report’s intended unit takes place. If the changes disagree about that responsibility, the agent has something specific to flag for a person or to correct in a PR.

If one PR fails to land, which others actually have to wait? A queue that processes each candidate in turn can leave the rest rebasing and redoing work after a failure. A speculative merge train looks ahead at the incoming PRs and checks candidates in pairs for compatibility. If one candidate drops out, the queue already has information about which other changes can go through together. Those candidates can advance while the troublesome one waits.

The train spends effort checking combinations ahead of time to reduce waiting later. What those checks establish depends on what they test. A train that only checks whether the invoice edits merge and pass their existing tests could carry the unit error straight through. Debois expects planning, merge handling and analytics for concurrent changes to become developer infrastructure in their own right as teams outgrow simple agent loops.

One shared board makes incoming changes and work in progress visible beyond the developer who started each task. Visibility also exposes a bottleneck. Several agents can ask for attention at once, and moving all their questions onto a board still leaves people answering them.

One way to put that attention to better use is to invite an agent into a conversation the team is already having. Several people can clarify the same request while the agent refines the ticket. The agent can ask what behavior they want, which requirements apply and what test would show that the work is done. The answers turn the ticket into something like a coding agent’s plan, available on the board for everyone to inspect.

Consider the old path for a request from sales, marketing or support. A colleague filed a ticket and could wait weeks for an engineer to pick it up. Building a quick version independently brought another problem when the result didn’t fit engineering practice. At Tessl, colleagues bring the agent into their organizational chat. They can experiment, refine the feature or start building it using engineering’s pipeline, knowledge, skills and loops. The support colleague who knows the original requirement can help settle what the feature should do while the idea is still taking shape.

What would you need in front of you to unblock an agent? When a ticket calls for rapid experimentation, another round of comments can be slow. In the handoff Debois describes, the stuck agent opens an IDE with its working context and files already available. A person can try an experiment there, make the missing choice and hand the work back. The agent resumes with the result of that intervention.

Some tasks only need a decision. The agent can present a few options, let a person pick one or override them, then continue. That saves the person from having to reconstruct the problem and write the next prompt from scratch. The choice goes into a shared decision log. A colleague can trace who decided what, and an agent in a later session can query the same decision when it needs that context.

There is a second reason to divide the work. A change can be isolated from other agents and still be too large for a person to review well. Smaller PRs can move through merge trains in pieces that reviewers can understand. Better context and tools can reduce failures before review, and another agent can challenge the code before a person sees it. Screenshots of a flow, video and test results give the reviewer a way to inspect what the change actually did.

When developers tell Debois they have stopped reading the code, his follow-up is about the impact of sending that change to production. An application with no customers has a different exposure from a service people rely on. Even within one application, the review decision can vary by change.

• Documentation. A limited-impact edit may go through after the applicable checks.
• Authentication. A mistake can have enough impact to justify closer human review before release.
• A feature that can roll out gradually. Release it in stages and inspect the output and errors as it reaches users.

Recovery changes that calculation too. If a release could lose data, how quickly could the team restore it? If one node fails, what happens to the service? How quickly could the team roll back a bad release? Review and testing can lower the likelihood of failure. Architectural choices about node failure, rollback and data restoration help determine how costly a failure will be once it happens.

Debois works remotely while most of his team gathers in London. He already had trouble catching up on changes discussed in the room. With several agents producing code, marketing and support can find themselves in much the same position. A list of merged PRs leaves them to work out the implications. Communicating a change in the language of each group’s work becomes part of delivering it.

The more routine work the agents handle, the more valuable it becomes to route an exception to someone who can decide it. Someone also has to maintain the system doing the routing. Debois sees a factory team emerging, much as a platform team might look after a cluster. Its responsibilities include establishing who owns each skill, keeping shared context up to date, connecting agents to the right components and monitoring the factory. An outdated instruction shared by the whole team has a different reach from one sitting on a single developer’s laptop.

The shared log gives an agent a way to recover a decision someone has already made. Debois’s team is exploring what happens when the board needs a new decision. A personal agent working there on someone’s behalf could answer another agent’s question and exercise the judgment that person has delegated to it.