Rule 16 of 33 · Chapter IV — How We Build and Review
Ship small, ship often
Why this rule exists
Big changes are where bugs hide, reviews go to die, and integration pain compounds, because the larger a change gets the harder it is to reason about, test, and safely reverse. A five-hundred-line pull request doesn't get reviewed, it gets rubber-stamped, because no reviewer can actually hold that much in their head, so the review that's supposed to catch problems catches almost nothing. Small, frequent changes flip all of this: they're easy to review carefully, easy to test, easy to roll back if they misbehave, and they surface integration problems while they're still small. Shipping often also tightens the feedback loop with reality, so we learn whether an idea works in days instead of months, which is the single biggest driver of building the right thing. The instinct to batch work into one big impressive drop feels productive and is almost always slower and riskier than it looks. Small and boring beats big and heroic, over and over.
In practice
Break work into the smallest pieces that each stand on their own and merge them as they're ready, rather than hoarding a giant branch. Keep pull requests small enough that a reviewer can genuinely understand the whole thing, and if one is growing huge, split it. Merge to main frequently behind a flag if the feature isn't ready to be seen, so you're integrating continuously instead of in one terrifying event. Deploy often and in small increments, because ten small deploys are far easier to debug than one big one when something breaks. When a change has to be large, call that out and help your reviewer by structuring it into readable commits. Favor a steady stream of small wins over the big-bang release you'll be up all night babysitting.
When it doesn't apply
Some changes are irreducibly large, a framework upgrade, a schema migration, a genuinely atomic refactor, and forcing them small does more harm than good. When that happens, invest extra in review, testing, and a rollback plan proportional to the size and risk.