A second opinion is only worth having if it doesn't know the first

Every serious development effort has a moment of verification: someone re-reads, someone tests, someone signs off. In practice that moment is almost always ineffective, and not because the reviewer is careless. It’s ineffective because the reviewer read the plan before reading the result.

Whoever knows the reasoning reviews the reasoning

When you explain to a colleague what you did and why, you’re also handing them the grid they’ll judge it by. From that point on the review answers a single question — does the code do what the author said they meant to do? — and that question almost always comes back yes. It isn’t laziness: it’s how attention works once the context is shared.

The question nobody asks is the other one: what happens in all the cases the author never considered? To ask it, you have to not know what the author considered.

What you actually find when you only look at the diff

Three real cases, stripped of every identifying detail: all three cleared an internal review, all three were caught by a review that had seen nothing but the changed lines.

• A lock guarding access to an external service, put there to prevent two concurrent calls. Correct in the normal path. But if the operation threw, the lock was never released: from that moment the whole service stayed frozen until a restart. Whoever wrote the change was reasoning about the case they meant to solve.
• An automated conformance check that, when the data was ambiguous, let it through. A check that says yes when in doubt isn’t a check: it’s a rubber stamp.
• A test document citing line numbers that no longer existed and claiming more test coverage than was actually there. The software worked. The document the client would have based acceptance on did not.

The costliest defect isn’t in the code — it’s in the claim

That third case is the one that matters most today. With code produced fast — by people or by tools — the part that degrades first isn’t the logic: it’s the claims about the work done. Which files changed, how many tests cover what, what was actually verified versus merely asserted.

A wrong claim in a release document doesn’t produce an error on screen. It produces a decision taken on a false premise, and the decision always lands higher up than the defect.

How to organise it in practice

You don’t need a QA department. You need three rules:

1. Whoever verifies doesn’t get the plan — only the result and the original requirements.
2. Every verdict carries its evidence: the command run, the output, the line. With no evidence the verdict is not verified — a perfectly legitimate outcome, unlike an invented pass.
3. Findings are closed or argued down, never quietly archived.

It costs a few hours per release. The comparison isn’t against the time saved by skipping it, but against the cost of discovering in production that the check was a rubber stamp.