Main idea

Merging code no member of the team could explain isn't a review lapse: it is a loan. The team gets the feature immediately, and commits to paying later in an inability to diagnose — at the moment this code has to be modified, secured or picked up without knowing why it is written that way.

The liability stays invisible as long as nothing breaks: the application runs, the screens respond, the tests pass. Dozens of pull requests opened overnight by an assistant and integrated without anyone checking the impacts look like progress; they are interest accruing.

Hence a simple merge rule, almost blunt: don't integrate code nobody can explain. It doesn't call for endless documentation — a small understanding budget per feature is enough: the contract, the tests, the architectural decision, the known limits. Just enough for the reasoning to stay humanly transmissible.

Why it matters

This puts an immediate price back on not understanding, at the place and at the moment the decision is made. As long as the cost is deferred, each integration looks reasonable in isolation, and the liability accumulates without any arbitration having accepted it.

It also gives a review criterion that doesn't depend on the reviewer's technical level: the question isn't "is this code good?" but "can anyone here say why it is the way it is?".

Nuances and limits

The rule runs into a grey area: explain at what level? Nobody explains a third-party library line by line, and a team that demanded that degree of explanation everywhere would integrate nothing. The object of the explanation is the intent and the boundaries, not each instruction.

And it only holds if someone has the authority to block an integration. In a team where deadlines come first, it becomes a declarative formality, and the explanation shrinks to a ticked box.

Open questions

• What perimeter should the explanation cover — the feature, the module, the line — for the rule to stay applicable without becoming a ritual?