Foundations¶
The architecture I would recommend for a real engineering organisation looks roughly like this.
Read top to bottom, the shape of the system is: intent becomes a dependency graph, the graph is allocated to isolated execution contexts, those contexts produce reviewable change sets, and a single controlled gate lets change into trunk.
The fan-out is deliberate and so is the fan-in. Everything above the merge queue is parallel; everything at and below it is serial.
The two halves of the problem¶
| Half | Mechanism | Where it's covered |
|---|---|---|
| Parallel without collision | Isolated environments, ownership domains, architectural decomposition | Isolation, Ownership, Decomposition |
| Serial without becoming a bottleneck | Small PRs, automated evidence, merge queue | Integration |
Most tooling in 2026 is strong on the first half and thin on the second — and thinnest of all on the part between them: deciding who is allowed to write what, right now. That gap is the subject of the Ownership section.
Nothing here is model-specific
Every mechanism on this site works the same whether the writer is Codex, Claude Code, OpenHands, or a human being with an IDE. That is the point — see Five Primitives.