Huge AI Pull Requests Are a Reviewer Tax, Not a Speed Win

AI-generated pull requests are getting bigger, and someone still has to read them. That someone is usually the one senior person on the team, and their week has not gotten any longer just because the agent's output did.

The post that set this off is Stop sending me huge PRs; a rant by Pete Mertz, published 14 August 2026 on Small. His argument takes two minutes to read. Mine is about who pays the bill.

---

🔍 The work didn't vanish, it changed hands

Mertz's core line is the one worth pinning above your desk:

"Small PRs were never asked for because they're easier to write, it's always been for the benefit of the reviewer."

That reframes the whole thing. Every "small PRs please" rule you ever rolled your eyes at was never about the author's convenience. It was a transfer of effort from the reader to the writer, on purpose, because a codebase gets read far more often than it gets written.

Coding agents quietly reversed that transfer. Writing cost dropped close to zero. Reading cost did not move at all.

Stage	Before agents	With agents
Writing 3,000 lines	Days of human work	Minutes
Understanding 3,000 lines	Hours of human work	Hours of human work
Who absorbs the cost	Author	Reviewer

Mertz is honest that the comprehension curve is a guess. He says he has no data and is "wildly speculating" that time-to-understand grows exponentially with diff size. I have no data either. But I would bet on the direction being right, because a diff is not a list of lines. It is a graph of interactions, and interactions grow faster than lines do.

---

⚖️ Why this bites small teams hardest

Big companies absorb this with staffing. A five-person startup in Colombo, or a two-person freelance team shipping for an overseas client, does not have that option. There is usually exactly one person whose approval means anything.

Here is the arithmetic that worries me. These are my own working numbers, not a study — plug in your own and the shape stays the same:

Team shape	AI-assisted diff produced per week	Review hours needed at ~200 lines/hour	Senior review hours actually available
1 senior + 1 junior	~4,000 lines	~20 hrs	~8 hrs
1 senior + 4 juniors	~15,000 lines	~75 hrs	~8 hrs
Solo builder, self-review	~6,000 lines	~30 hrs	~2 hrs

Nobody has 75 hours. So the review becomes a scroll, a scan of the test file names, and an approve. The gate is still on the org chart but it stopped being a gate.

Key takeaway: When review capacity is fixed and code output is not, oversized PRs don't slow you down — they silently turn code review into a rubber stamp, and you lose the one control that was catching real bugs.

Mertz closes with the joke that lands hardest: are you sending giant PRs so the reviewer gives up halfway and approves? For a lot of teams that is not a joke, it is the mechanism.

---

🛠️ How to split a one-shot change into reviewable pieces

The pushback is always "it won't work without the whole change." Mertz's answer is the right one: a PR does not have to be a shippable product, it has to be a comprehensible unit. Feature flags and dead-but-tested code exist for exactly this.

Practical axes to cut along, in the order I reach for them:

Split axis	PR 1	PR 2	Why it reads well
Pure code before wiring	Data module, pure functions, tests	UI that calls it	Reviewer can verify logic without React noise
Mechanical before meaningful	Renames, moves, formatting	Actual behaviour change	The scary diff shrinks to 40 real lines
Schema before usage	Migration + types	Queries that use them	Migrations deserve their own careful read
Happy path before edges	Core flow	Error handling, retries, limits	Edge cases get real attention instead of scroll-past

The workflow that keeps this cheap is to let the agent build the whole thing first, then restructure before you ask anyone to look. Several people in the Hacker News thread on this post described the same habit: build to learn, then repackage for review in a separate pass.

# let the agent finish, then carve it up
git checkout -b feat/thing-part-1 main
git checkout feat/thing-full -- lib/data/thing.ts lib/data/thing.test.ts
git commit -m "feat: pure calculation module for thing (no UI yet)"

# stage the rest interactively when a file mixes concerns
git add -p components/thing.tsx

git add -p is the single highest-leverage command here. It is how you land a 300-line PR out of a 2,000-line working tree without hand-editing anything.

---

💰 The token argument, and what it actually costs

Mertz has no patience for "just use AI to read it": you are burning tokens re-ingesting code an AI already wrote, and if a different model is doing the review anyway, why is it in a human queue at all?

There is a real number under that complaint. A 3,000-line diff is not free to feed to a review model, and if you are on a learning budget or paying in dollars from an LKR income, it compounds every time the PR gets a new revision. Before you build an "AI reviews the AI" loop, paste a representative diff into our AI token counter and see what one pass really costs, then multiply by revisions and by team size.

The second-order cost is worse than the token bill:

• Review models are agreeable. They rarely say "this whole approach is wrong."
• Agent-written tests can assert almost nothing while looking complete. Thread commenters flagged this specifically, and it matches what I see.
• A generated test suite reviewed by a generated reviewer gives you a green checkmark and no information.

When a diff is genuinely too large to reason about and you cannot split it yet, comparing two versions side by side in a plain text diff checker is a decent way to isolate one file's real change from the noise around it.

---

🌐 If you contribute to open source from Sri Lanka, read this twice

For a lot of engineers here, merged pull requests in public repos are the portfolio. They are what gets you past a hiring filter when your degree is from a university the recruiter has never heard of.

That signal is being repriced right now. Maintainers are getting flooded, and the thread on Mertz's post mentions projects that have started blocking AI-assisted contributions outright. The consequence for you is direct:

1. A 2,000-line first-time PR now reads as a warning, not as effort. It looks like unattended agent output whether or not it is.
2. A 60-line PR with a clear description and one focused test reads as competence. It is also far more likely to actually get merged.
3. The scarce skill is no longer producing code. It is packaging a change so a stranger can trust it in ten minutes.

Use the agent. Just do the second pass it will not do for you.

---

💡 What this means for you

Mertz's point about React is the one I keep returning to. When React arrived we did not start accepting bigger PRs because it was faster to write. The reviewer's budget did not change, so the norm did not change. Nothing about agents changes that either.

Three things worth doing this week:

• Set a soft cap and make it visible. Even a CI warning at 400 lines that politely asks for a split moves behaviour, and costs nothing to add.
• Make splitting the last step of the agent workflow, not an afterthought. Build whole, ship in pieces.
• Kill the comment noise while you are there. Document the function; do not write five lines explaining why a variable is called is_logged_in. If the name needs a paragraph, fix the name.

If you are the only reviewer on your team, you are the constraint on everything shipping. Protect that hour. Nobody else on the org chart will.