One coding agent can create a local integration problem. Several engineers running coding agents in the same monorepo create a different one: each agent needs some way to see what the others are doing before their changes collide.
A Thoughtworks Europe practice exercise described in An Accidental Blackboard put ten engineers in one room to build a simulated airline disruption-management system. The useful part for an AI-assisted development workflow is not how quickly they built it. It is what happened when many agents began working in the same repository at the same time.
The first problem was integration pressure
With many agents changing one codebase, the build pipelines began to suffer. The team introduced a discipline in which agents committed frequently, rebased from main and ran the existing build checks so integration failures would be found early rather than accumulating.
That helped expose conflicts, but it also created another problem: pushing too frequently overloaded the CI pipeline. The team later backed away from continuous pushes and moved towards pushing more coherent chunks of work.
The lesson is not that there is one correct commit interval. It is that agentic development at team scale turns integration cadence into something that has to be designed. Integrate too slowly and agents work against stale assumptions. Integrate too aggressively and the machinery that checks the work can become the bottleneck.
The plans became a shared coordination surface
The more interesting effect came from the plans the agents were already writing. Work was scoped to numbered sections of a shared specification, and those plans were stored in the repository. As agents updated their plans and committed them, other agents could see both progress and intended integration points.
In the exercise, one agent could see that another agent was already working on a dependency and avoid duplicating that work. When the dependency was completed, the plan could also carry notes about how it had been implemented. The repository was doing more than storing source code: it was carrying enough shared state for agents to coordinate.
The article describes this as an accidental form of a blackboard system: a shared space that independent agents can read from and write to while working towards a larger goal. The behaviour was emergent rather than deliberately designed, and the author explicitly says he was not confident that the same result could simply be prompted into existence again.
What is worth copying
The case study does not establish a universal recipe, but it does expose several practical requirements that become visible once more than one engineer is directing agents against the same codebase:
- Give work shared identifiers. The agents were working from the same specification and numbered sections, so progress and dependencies could refer to the same pieces of work.
- Make progress visible outside one agent session. Plans stored in the repository gave other agents something they could inspect instead of relying on context held privately in another session.
- Record integration points. The plans described where one component depended on another, which let agents recognise when they needed to wait, adapt or integrate.
- Integrate early enough to expose breakage. Frequent commit and rebase cycles helped reveal build problems while the changes were still close to the work that caused them.
- Do not turn CI into the coordination channel. The experiment eventually reduced the push frequency because the continuous flow of commits was overloading the pipeline.
Source control can help without being the final answer
The accidental coordination worked because plans and progress travelled with repository updates. But the article itself argues that a deliberate communication channel for agents should sit independently of source control rather than depending on constant pushes.
That distinction matters. Git is good at preserving code history and reconciling changes. It is not automatically the best place for high-frequency status updates between autonomous workers. The exercise found value in the shared visibility, then also found the cost of using the commit pipeline to provide it.
The team-scale question is different
For a single developer using one agent, the main control problem is usually whether the agent understands the task and stays within its boundaries. With several engineers and several agents, there is another question: where does shared progress live?
The Thoughtworks exercise suggests a useful test before scaling an agentic workflow across a team. Can each agent see which part of the shared plan is in progress, which dependencies are expected, what has already landed and when it should integrate with main? If that information exists only inside separate conversations, the agents do not have the shared state that made coordination possible in this case.
The repository happened to provide that state here. The more durable lesson is to make coordination explicit before concurrent agent work becomes large enough for collisions, stale assumptions and overloaded checks to become the way the team discovers what everyone else was doing.