Concurrent Change

Parallelism is not decided. It is discovered — by finding what the pieces of a change must agree on, and noticing which of them already do.

Two agents can work at once when nothing either produces changes what the other assumes. That is the whole condition. It is a fact about the change, and no amount of instruction, file-locking, or careful sequencing in the prompt can create it where it does not hold.

One operation: find the agreements the work depends on, establish them first, then fan out over what remains.

The unit is the contract, not the file

The instinct is to split by file or directory, because those look separable. They are not the boundary. Two agents editing different files collide the moment they must agree on a name, a shape, a rule, or an error case — and they will resolve that disagreement differently, in isolation, each locally correct.

The real boundary is the contract: the types, signatures, invariants, and vocabulary the pieces share. Work is concurrent when the contract between the pieces is already fixed.

This gives the sequence, and it is almost always the same:

Establish the contract in one place, alone. Then fan out over the implementations.

Types, module boundaries, error cases, the names of things — these are what everything downstream reads. Written once, sequentially, they cost little. Discovered independently by four agents, they produce four dialects and a merge that has to pick a winner and rewrite the losers.