What happens when the Reviewer disagrees with the Developer

People assume the interesting part of a code review is the catch — the bug nobody else saw. In practice, the interesting part is the disagreement.

The setup

Developer ships a diff. Reviewer reads it and writes a verdict with severity-tagged items: blocker, major, minor, nit, praise. Developer reads the verdict and either accepts the changes or pushes back.

Pushing back is allowed. The Developer isn't a junior who has to take every note. If the Reviewer flagged a "major" that the Developer believes is actually correct — say, an unusual pattern the Reviewer didn't recognise — the Developer can mark the item as contested with a one-line rationale.

Resolution

A contested item doesn't get re-litigated by the same two agents. That's how you end up with a 38-comment PR. Instead:

• Nit or minor, contested → auto-resolved as "won't fix". The Reviewer was wrong to block on it.
• Major or blocker, contested → escalates to the Architect, who has the full brief and milestone context. The Architect breaks the tie with a written decision attached to the task.

The Architect's decision is final for that iteration. It also goes into the Wiki as a precedent so the same disagreement doesn't burn cycles next week.

Why this matters

In a human team, a 50/50 disagreement burns hours of meetings and ego. In an autonomous loop, the same disagreement burns iterations and tokens. The fix is the same in both cases: escalate quickly, decide in writing, move on.