Blog
From sprawl to defaults
More rules did not make our reviews better — it just made them louder. The fix was fewer rules, picked carefully, and lifted to defaults the system enforces so the team doesn’t have to remember them.
We had a 12-page review manifesto. It laid out every rule, every exception, every caveat for the kind of team we were three years ago. New engineers were expected to read it in their first week. Most didn’t, and the ones who did disagreed on what it meant. Real review choices were still being made in tribal knowledge, and the document mostly existed to be cited when a disagreement came up.
The unexpected insight: removing rules improved consistency more than adding them. We picked the five rules that almost always apply — the ones whose violations actually caused outages instead of merely being against house style — and made them the default. Anything not on that short list stayed out of the static review and instead moved into PR-time comments, where they explain themselves instead of blocking the change.
The other move was lifting the defaults into the system itself. No engineer should have to remember to apply them; the workflow enforces them in the background. That “default with enforcement” shape is what changed reviews from a practice teams fall out of, into the path of least resistance. Engineers stop being asked to be careful and start being enabled to be careful.
The result was fewer surprise outcomes at merge time, not louder ones. Reviewers read the diff and decide; defaults handle the rest. The old manifesto is still online if anyone wants it, but nobody cites it anymore — and that is the proof we got the rule count right.