Experienced engineers love to say:
“Keep your PRs small.”
But what does small actually mean?
One function?
One file?
10 files?
100 files?
1,000 files?
“Small” has always been subjective.
A small PR in a five-person startup looks very different from a small PR in a codebase thousands of engineers have worked in over decades.
Now add agents.
An agent can analyze an entire repository, trace dependencies, make a coordinated change across thousands of files, run tests, validate the result, and explain what changed.
So why are we still judging the quality of a change by how many files it touched?
The goal was never actually small PRs.
The goal was:
- Understandable changes
- Verifiable changes
- Safe changes
- Known blast radius
- Easy rollback
Small PRs were simply one of the best tools we had to achieve those things when humans were writing all of the code.
That assumption has changed.
Code review need to evolve from:
“Did I inspect every changed line?”
to:
“Do I have enough evidence to trust this change?”
That means understanding what the agent was asked to do, what constraints it operated under, how the result was tested, what it skipped, and what could break if the change is wrong.
A 100,000-file mechanical change with deterministic validation can be easier to trust than a subtle 20-file change with weak tests.
File count is not risk.
Complexity is not the same thing as size.
Agents are changing the unit of work.
And some of the software engineering practices we treat as gospel need to change with it.
“Keep PRs small” is becoming “Keep changes understandable and verifiable.”
This isn’t the "future" of software engineering.
It’s today.