Yes, usually. Small changes are quicker to read, easier to test and simpler to roll back, and DORA names working in small batches as a capability that predicts delivery performance. For security, a ten-file change gets a real review where a 90-file change gets a skim.
What DORA says about small batches
DORA's capability page says working in small batches reduces the time it takes to get feedback on changes, making problems easier to triage and remediate. It recommends breaking work into units that can be completed independently, and suggests developers should check multiple small releasable changes into trunk at least once per day. It describes "Small" as hours to a couple of days of work.
The page also says that AI adoption often leads to increased software delivery instability, and that small batches act as a countermeasure. Large AI generated changes are hard to review, test and integrate safely.
Why this helps security specifically
Reviewers find fewer problems in large diffs, mostly because attention runs out. Small batches change three things:
- Review depth. A reviewer can hold the whole change in mind, including what it does to authentication, input handling and dependencies.
- Blame radius. When a scan or test fails, the cause is within a small set of lines.
- Rollback cost. Reverting a small change is cheap, so recovery is fast if a flaw ships.
Practical steps
- Set a soft size guide for pull requests. Many teams pick a line or file count that flags large changes for splitting. The exact number is a team choice, so choose one and review it.
- Separate dependency updates from feature work. A pull request that only bumps a library is easy to scan and easy to revert.
- Separate refactors from behavior changes. Mixed changes hide security-relevant edits.
- Use dark launching or feature flags so unfinished work can merge without being visible. DORA describes dark launching as checking in completed small batches into trunk and launching to production without making them visible to users.
- Run automated security checks on every pull request so each small batch gets the same scrutiny.
Where the idea has limits
Small does not mean unreviewed. A tiny change to an authorization check can matter more than a large refactor, so keep targeted review for sensitive paths such as login, payments and permission logic. And splitting a change badly can scatter one logical security fix over several pull requests that are unsafe on their own. Make each batch safe to deploy by itself.
What to measure
| Measure | Why it helps |
|---|---|
| Median pull request size | Shows whether batches are shrinking |
| Time from open to first security feedback | Shows review speed |
| Share of pull requests with a security check run | Shows coverage |
| Change fail rate | Shows whether smaller changes are more stable |
Quick check
Do small batches reduce lead time?
Often, because review and testing are quicker. Check your own data, since the effect varies by team.
Should security review every small change by hand?
No. Automate the routine checks and keep human review for sensitive areas.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how a pull request is checked before merge. Small, frequent checks like this are what small batches make practical.
How Safeguard fits
Safeguard offers policies and gates that run dependency checks on pull requests, so each small change gets the same check. Try a free scan at gold.safeguard.sh/scan.
Sources
- DORA, Working in small batches: https://dora.dev/capabilities/working-in-small-batches/
Last reviewed: 19 October 2026.
