Modern tools. Unchanged standards.

If they are not made at the start, they get made anyway. They get made accidentally, thousands of times, by whoever is closest to the deadline, and every one of those small decisions looks reasonable on the day it is taken.

Nothing errors. Nothing fails review. The code works, the tests are green, and the cost arrives later as something that looks like an infrastructure problem, a performance problem, or a delivery problem, long after anybody can point at where it came from.

So we agree the standards before the work rather than discovering them during it, and the four below account for most of the difference.

The most common version of this is a platform that talks to several external providers of the same thing, none of which agree on how it should be delivered.

The direct version works. Each module talks to each provider, and on the day it ships it is indistinguishable from the alternative. The version with a boundary also works, and puts one adapter in front of each provider so that everything downstream reads one internal shape.

The difference is not visible until something moves. A fourth provider arrives, or a field changes, or somebody needs to know which parts of the system will break. In the first version that is a project. In the second it is an adapter and a set of tests.

That is dependency inversion, and stating it as a principle undersells it. Which provider a prospective customer happens to use stops being a qualification question, which is a sales conversation rather than a code review conversation. The principle earns its place because of what it does to the business, not because of what it does to the diagram.

The same reasoning applies to any capability a platform does not own: payment providers, identity checks, mapping, messaging, model vendors. The question is never whether the integration works. It is what has to change when the second one arrives.

Anything holding a connection, a file handle, an event listener, or a buffer has to have someone who owns it and an event that ends it. If either half of that is a shrug at review time, the code is not finished, however well it runs today.

This is the category that automated gates are worst at. A listener registered when a component appears and never removed when it goes. A connection opened for a query and held for the length of a request that then waits on something slow. An anonymous closure that captures the object graph around it and outlives the thing it was written inside. A cache with no eviction, or a collection appended to per event and keyed by something unbounded.

Every one of those is correct code. Linting will not find them, type checking will not find them, and the test suite is green, because a test never runs long enough for unbounded to mean anything.

They are found by somebody who has seen them before, reading the code and asking who owns this and what ends it. At low volume they are tidiness. At scale they stop being tidiness and become the largest line in the bill, arriving labelled as infrastructure.

A module that reads what it needs is one you can change. A module that reads what happens to exist is one that breaks when something unrelated moves.

The practical version is that interfaces are defined by the consumer’s need rather than by the producer’s convenience, and that a component receives what it requires rather than reaching for what is available. Both of those are ordinary discipline until a system is large enough that no single person holds all of it, and then they are the difference between a change that takes an afternoon and a change nobody wants to make.

There is a second consequence that matters more than the maintenance one. A boundary enforced structurally is inherited by features that have not been written yet. A rule that lives in the data layer applies to the next screen automatically. A rule that lives in a convention applies until somebody forgets. In anything holding sensitive data, that distinction is the difference between a control and a training slide.

Most code runs rarely enough that ordinary choices are the right ones, and premature optimisation is a real failure mode rather than a slogan.

But every system has a small number of paths that run millions of times, and on those the calculation inverts. A structure that regrows as it fills, work repeated per record rather than per batch, an allocation inside a loop that could have sat outside it: at low volume these are invisible and correct. At high volume they are paid for on every run, every night, and they never appear as a line item because they arrive labelled as infrastructure.

Knowing which paths are hot before writing them is experience. Finding out afterwards is a bill.

None of this survives on discipline alone, which is why the machinery described above exists.

Formatting, linting, type checking, and static analysis are enforced by the pipeline rather than by memory, and coverage thresholds and security findings block a merge whoever or whatever drafted the change. That removes the mechanical half from human attention entirely.

What is left is the half a gate cannot check: whether the boundary is in the right place, whether a resource has an owner, whether this path is hot, and whether the shape of the thing will still make sense when somebody else is holding it. That is what review is actually for, and it is why every change has a named engineer who can explain and defend it.

A tool can draft a module that reads one provider directly. It works, it passes review, and it is indistinguishable from the right answer until the fourth provider arrives. Knowing which of the two you are looking at, before either is written, is the part that does not come from a tool.