Measure the collisions before the pull request

What is established, and by whom

Background. Coding agents now produce pull requests at scale, and the coordination paper starts from reports that their pull requests are produced faster but accepted less often. Pull-request telemetry records the end of the process: by then, duplicated effort has already been spent and overwritten work is already gone.

My result. In Before the Pull Request (arXiv preprint), concurrent coding agents coordinated through grite, a git-native append-only coordination log. Three findings:

1. With the shared substrate, the share of work that merely re-did a teammate’s task fell from 78% to 0%, while useful throughput more than tripled, at bounded overhead.
2. Every agent’s copy of the log converged to the same state with no write silently dropped, whereas a file-based tracker lost concurrent writes.
3. The log is minable: conflicting edits, lock starvation, redundant rediscovery and race-to-close were recovered automatically with provenance, several of them invisible in pull-request history.

The disclosure matters here. grite is a Neul Labs project, Neul Labs is a company I founded, and it builds AI agent infrastructure. The paper is therefore evidence about a substrate I have an interest in, produced by me. Treat it as a demonstration of what the measurement can show, not as an independent evaluation of the tool.

What a reproducible coordination study should measure

The rate that matters most is usually not “conflicts” in the abstract but wasted completed work: effort that reached an end state and was discarded because another agent did the same thing. Alongside it:

• Lost writes — events one agent made that no other agent ever observed.
• Claim latency and starvation — how long work waits on a claim that is never released.
• Failure provenance — for every counted failure, the event sequence that produced it, so a reviewer can disagree with a classification.

Illustrative example — not a client engagement. A lab runs four agents on a backlog of 60 issues and suspects overlap. The study fixes definitions first, then compares their current tracker with an append-only log over three repeated runs. The analysis notebook shows most waste comes from two agents re-discovering the same failing test, not from edit conflicts, which points the next experiment at shared test state rather than locking.

Open questions

Whether these rates hold with heterogeneous models, mixed human-agent teams and long-lived repositories is untested. So is the link between less duplication and higher pull-request acceptance: plausible, but a separate measurement. These are the questions I would most like to study with a second, independent substrate.