The Three Physics of Software: when you can no longer review 100% of changes

In this series I’ve been describing a regime change. When code is written at machine speed, some of the rules we have always built software on stop holding.

A regime change has to happen somewhere. This post is about where the shift happens: where, and when, we move from the old, familiar regime into the new relativistic one.

The previous posts, if you want to catch up: Nothing was added to your codebase. It got heavier anyway and You can generate code faster than you can delete it.

Where the boundary sits

The boundary between the regimes sits where the speed at which we produce code rises past a certain threshold. That point is easiest to recognise in our code review practices, because review comes right after the code is written. It is the first place the speed hurts. So when a team is forced to change its existing code review practices, that’s a good indication that the boundary has been crossed.

To be clear, it’s not the point where a team stops reviewing all changes.
Many teams never reviewed every change, even if they claimed to.
Changes slipped by for various reasons: big changes got skimmed, urgent fixes went in at midnight, and so on.
Review coverage was below 100% long before AI.

The regime shift happens when reviewing 100% of the code is no longer feasible.
Below the boundary, a team could have reviewed everything and sometimes chose not to.
It was a choice about where to spend attention.

Past the boundary, the team just can’t.
Code simply arrives too fast, and no reasonable number of people would close the gap
(not to mention that you usually don’t have enough experienced reviewers to even try).

The boundary is where partial review stops being a choice and becomes an inevitability.

How to tell you’ve crossed it

You don’t need a percentage to find the boundary. Compare two rates: how fast you merge, and how fast your team can genuinely read what is being merged.

Below one to one, some things may slip past review, but that’s a choice, and the gap can be closed later on if necessary.
There is spare reading capacity to catch up.
Above one to one, the unread code only grows, and no one will be able to catch up later.

So the question to answer is whether you can still read what you ship, at the rate you ship it.

What changes past the boundary

Once a team is past the boundary, strange things will start happening.
Practices that assumed a high level of understanding start losing their footing.
There’s just too much code being produced, and our old techniques for managing it are no longer guaranteed to work.

The code itself behaves differently too. As the earlier posts in this series showed, the same codebase gets heavier at higher speed: every change costs more, and understanding drifts further behind. Those are the effects of the new regime, and they only show up on the far side of the boundary.

Newton was not wrong

None of this makes the old practices wrong.
Below the boundary, they still do what they always did, and a team there is right to keep them.

Physics has the same shape. Newton isn’t wrong; he’s the low-speed case.
Whether you need the relativistic correction depends on whether you’re travelling fast enough to make the effect noticeable.
Particle accelerators need it. Your car doesn’t.

This is the important part: this is a regime shift, not an era we are entering.
An era would start on the same date for everyone.
The boundary is a condition each team will reach at its own time.
Some organisations are already experiencing this, and many are not there yet.

Crossing is fast, the rest is not

Be aware, you can actually reach and cross the boundary very quickly.
A single quarter of agent adoption may be enough.

Dealing with what happens after is a bigger and longer effort.
That is why it pays to know and prepare before the boundary is crossed, not after.

Part of The Three Physics of Software — what happens to the rules of software engineering when the code stops being written by people.