Reviewing faster won't save you. Colliding less will.

On 7 July, PostHog told engineers to stop being the code review bottleneck. The advice is to build a pipeline of review agents and take yourself out of the loop. GitHub’s own engineering blog reports that Copilot code review has processed over 60 million reviews, growing tenfold in under a year, with more than one in five code reviews on GitHub now involving an agent.

The industry has reached a consensus. Agents made writing code fast, so the fix is to make reviewing code fast too.

That solves half the problem. Agentic velocity creates two costs, not one. The first is verification, whether a change is correct, secure and up to standard. The second is reconciliation, whether a change can coexist with everything your colleagues changed at the same time. Review agents attack the first. Nothing attacks the second except the structure of your codebase.

We learned that the expensive way.

The merge we abandoned

While building our own Living Knowledge Base, two of our developers made substantial concurrent changes to the same codebase. Both sets of changes were good. Both passed review. Then we tried to merge them.

The reconciliation became so complex that we stopped. We ditched every change from one developer and had agents re-implement the same functionality on top of the other developer’s code. That was quicker, easier and safer than completing the merge.

Sit with that for a moment, because it is the economics of agentic development in a single incident. Throwing away finished, reviewed work and rebuilding it from scratch cost less than merging it. Re-implementation got cheap. Reconciliation did not. Which means the merge tax, not the review queue, is now the dominant cost of putting multiple developers in one codebase.

One developer in a module at a time

The discipline that fell out of that incident is easy to state. Every project is modular by design. One developer works inside a module at a time. Parallelism happens across modules, never within them.

The boundaries are physical, not conventions. Each module is its own repository. The contract between modules is an API, and where the consumer is an agent, that API is exposed as an MCP server. An agent working inside a module sees the contract, not its neighbours’ internals.

This will look familiar. Microservices, CODEOWNERS, module ownership. The shape is old, but the rule is not ownership. Nobody owns a module. The documentation standards we embed in and around every codebase, combined with the reach of modern frontier models, mean any developer can pick up an unfamiliar module and change it safely, and we do this constantly, each developer moving into whichever module their current task requires. The rule is occupancy. A module has one developer inside it at a time, a mutex rather than a deed. Microservices partition software for runtime scaling. CODEOWNERS assigns accountability. We partition for development concurrency, and the constraint costs nothing because one developer with agents now produces what a team once did.

The obvious failure mode is the pinch point. Two features need changes to the same module at the same time, and the rule turns that into a queue. We queue. In practice we have never actually hit it, because a module change that once took weeks now completes in hours, and a queue measured in hours is not a bottleneck worth breaking your structure for. Larger teams will hit the pinch point sooner. The answer is to partition more finely, not to put a second developer in the module.

It is also, we would argue, why large organisations struggle most with agentic development. Many developers making concurrent changes to a shared codebase is precisely the collision pattern that agentic velocity punishes.

Review agents solve the other half

None of this is an argument against review agents. We run an automated code review and a security scan on every commit, and our pipeline is built on gates precisely so that humans are not the bottleneck PostHog describes.

But review is verification. It tells you whether one change is right. It cannot tell you what happens when two right changes collide, and no review agent will merge two divergent architectures for you. Verification scales with review capacity. Reconciliation only scales with structure.

Stop building monoliths

The rule started as traffic control and became an architecture. We now deliberately avoid designing single monolithic platforms. We build functionally distinct, modular software elements and compose them into an appropriate solution for each customer.

The composability pays twice. During development, it is what makes single occupancy workable at all. And in a market moving this fast, it makes the software partially disposable. When a function becomes obsolete, and functions are becoming obsolete faster than at any point in my career, we replace that module and the rest of the estate stays intact. It is the same logic as building software you can throw away, applied at module scale rather than implementation scale.

Partition before you accelerate

The prescription is short. Before you add review capacity, partition your codebase. Let any developer work in any module, but never let two work in one at once. Make the contracts between modules explicit enough that an agent can build against them without reading the neighbours.

Then let PostHog’s advice make your verification fast, because it is good advice for the half of the problem it addresses. Just do not mistake it for the whole answer. The teams that win with agents will not be the ones that review fastest. They will be the ones that collide least.