(The Three Physics of Software — part 1 of 2)

All our software building practices were formed with a single constraint in mind: people wrote the code. Therefore, producing it was slow and expensive. Reviews, onboarding, design docs, keeping modules small. All of it tried to maximise the effectiveness of the people writing the code.

When a machine writes the code, things move much faster. Too fast for human comprehension to keep up. That gap has an effect, and it isn’t the one people expect.

### The same code, at speed, is a heavier object

In physics, mass is an object’s resistance to changes in its motion. In special relativity an object’s mass is a function of velocity, and not because anything was added to it. So when you move faster you need more energy to make it turn.

The same thing happens with code. Same repository, same complexity, nothing added: at higher change rates it behaves like a heavier object. And it isn’t only that there are more changes. Each individual change costs more than it used to.

In code, that mass is not the line count. It is the system’s resistance to being moved somewhere else. What creates that resistance is the overall complexity: how much there is, and how tightly it is bound together. By that measure a large codebase of genuinely separate parts is lighter than a small one where everything touches everything.

### Conflicts, drift, and what they do to review

High velocity causes two different things in parallel.

**More conflicts.** Work in flight tends to land in the same areas of the system. Chances of this happening grow quadratically with the number of changes in flight, not linearly. [Brooks’ coordination cost](https://en.wikipedia.org/wiki/Brooks%27s_law), re-denominated in tokens. It never went anywhere.

**Less understanding.** Reading continues to run at human speed. When generation runs at machine speed, understanding drifts.

And less understanding results in higher costs. Resolving a conflict means understanding both sides of it. Without that understanding, resolving it is harder and the result is less reliable.

Bottom line: when you move faster, reviews get longer and less effective at the same time, and quality deteriorates.

The old guarantee was never that one person, or a few, had read the whole codebase. In large systems that is never the case. The assumption was that to reach the necessary quality and hold it, **every line had been read by at least two people who understood why it was there**: the author, then a reviewer.

That is the line. You cross it when changes start shipping without real review: approved, build green, and nobody on the team who could explain why the code looks the way it does. Go back through the last month of merges and see how many you find.

Past that line it stops being a decline and becomes a self-reinforcing loop. Less understanding makes review harder, harder review is less effective, and less effective review lands more code nobody understood, which widens the gap again. That is why the cost per change accelerates instead of just rising.

### Why it’s very hard to see

Because it is not a clear wall. It is a gradual change, and it tends to hide in plain sight.

Not for lack of measurement. Conflict rate, review cycle time, PR size, time to merge. Many engineering organisations monitor all of those. What’s missing is a clear connection to the cause. It is hard to measure how much system you are carrying, how tightly it is bound together, or how much of it anyone still understands.

**Everyone is watching the numbers. Nobody is reading them as weight.**

And if that isn’t enough: by the time you start noticing something is wrong, slowing back down comes with a cost. Conflicts need to be resolved, understanding needs to be rebuilt. That catch-up time never makes it into the plan.

### What still holds

We moved into a new regime. Writing code got faster and human understanding did not.

And given that slowing down is not a good option, the only escape left is **reducing the mass.**

That’s part 2.

—

*Part of [The Three Physics of Software](https://practicalsw.com/three-physics) — what happens to the rules of software engineering when the code stops being written by people.*