Two coding agents branch from the same Django commit. One renames a helper function, phone2numeric. Nobody tells the other, which writes new code calling the helper by its old name. Both patches pass their tests. Git merges them without a conflict, since they touched different lines. Then the merged code falls over with a NameError, because the old name no longer exists.
Xia, Wu and Park built tasks like this around a dozen Django helpers, and the merges broke almost every time. Then they combed Django's real history for the same failure and found exactly one.
That one doesn't tell you much. Django's history only holds code that humans already reviewed and made fit together. This break happens earlier, while agents work in parallel and before anyone reviews anything. Nobody has records of that stage yet.
So check for it yourself. It's cheap. After merging, run every task's tests against the combined code. A green patch only vouches for itself.
Built to break: 105 of 108 merged runs failed, across 12 Django helpers. A script made the breaking change; one agent (GPT-5.5) wrote the code that depended on it.
Mined from Django's history: 834 runs on 417 real pairs of pull requests. One run broke, on one test.
Agent told about the change: 89 of 108 runs (82%) fixed their code after getting a short note describing it.
Hardest to recover (runs fixed, out of 9): urlencode 3, escape 4, slugify 6.
Fine print on that note: it was filled in from a template after the change was finished, so it was complete and accurate. An agent working mid-task alongside another rarely gets that.
Same break, other shapes: a helper gains a required argument. A helper returns an object where it used to return a string.
Not yet measured: how often this happens before review. Whether three changes can break together when every pair of them works fine.