monday morning. I opened github and there were nine PRs waiting for me. all from the same author.
I added up the diffs: almost nine thousand lines. three of the PRs were over two thousand lines each.
I complained on slack. politely, but I complained.
the reply wasn’t about size. it was about the validation process. according to the author, each PR went through TDD with tests written before the code, automated review by claude code, a second review by another model, a third by copilot, and one more manual review by him before opening.
multiple cycles. all robust. all legitimate.
and there’s more. he reminded me that the nine PRs weren’t a monolith — they were split into three batches by priority, each PR with its own scope. he was right about that too. splitting into smaller PRs is exactly what we ask for in any process conversation. and he did it. respect.
except he was answering a different question than the one I was asking.
review isn’t there to check if it works
his defense starts from a premise: that code review exists to check that the code works. if it already went through five layers of validation before the PR opened, the sixth layer — me reading the diff — would be redundancy. LGTM and move on.
that reading sounds obvious. but it misses the point.
review was never about checking whether the code works. tests do that. CI does that. agents do that. review by another person is about sharing knowledge. what exists in the system, why it exists, and how to touch it without breaking it.
that’s what happens when two people read the same diff. the reviewer is unlikely to catch more bugs than CI already caught. but they walk away from the read knowing what changed and why. and that knowledge, spread across the team, is the only thing that keeps every piece of the system from getting a single owner.
I’ve written about this before on the newsletter (in portuguese) — I argued that review is mentorship disguised as process, knowledge passing from senior to junior. that framing was too narrow. review isn’t just a way to do mentorship. it’s how a team stops being a collection of people writing disjoint pieces of the same repository.
and that’s exactly where my colleague’s arithmetic breaks.
the silo doesn’t come from PR size. it comes from the queue.
splitting into nine PRs instead of one monolith is better. nobody’s arguing that. but if three of those PRs are over two thousand lines each, and they all land on the same person in the same week, the practical effect is similar to the monolith: the reviewer reads the three big ones superficially, rubber-stamps the small ones, and nobody — except the author — walks out understanding what’s in the code.
when nine thousand lines were read with attention by only one person — no matter how careful that person was, no matter how many validation cycles they ran — the system has a single owner. and that isn’t efficiency. it’s fragility.
tomorrow that person takes vacation. or switches squads. or (who knows) wins the lottery and disappears. who understands that code? the honest answer is: nobody. and when the next feature needs to touch that part of the system, someone is going to have to rebuild from scratch the understanding that lived inside a single head that isn’t there anymore.
that cost doesn’t show up in CI, doesn’t show up in multi-model review, doesn’t show up in any productivity metric. it shows up three months later, when someone opens a function and asks “why is this like this?” and the slack thread shows that only one person read it with attention — and that person isn’t on the team anymore.
multi-model review accelerates human review. it doesn’t replace it. confusing the two is the mistake that gets expensive later.
the bottleneck was always there
I like the highway metaphor. every road has a point where traffic narrows — a tighter bridge, a curve, construction. while few cars pass through, nobody notices. when the flow goes up, that’s where traffic stops. and we discover that point was always the limit — we just couldn’t see it.
for decades the engineering bottleneck was writing code. whoever wrote more code faster was the “productive” one. the tools that won everyone’s heart — IDEs with autocomplete, copilot, cursor, agents — were always, at their core, tools for writing more code faster.
review existed as ceremony. a stamp at the end of the process. and it worked — because, while writing was the expensive part, knowledge sharing happened naturally. you read the PR because the author had spent a week writing it, and reviewing felt fair. nobody was going to hand you four thousand lines in an afternoon — so nobody was going to hand you four thousand lines to pretend you’d read.
now the agent hands them over. and the ceremony got exposed.
what’s exposed is a question that always existed, just hidden by the human cadence of writing: does anyone besides the author understand what’s being built?
when the answer is “no”, the team isn’t being efficient. it’s accumulating a debt nobody wrote down anywhere.
the work moved rooms
this is the part that matters.
engineering was never just about writing code. it was always about judgment, context, and shared knowledge. the problem was that writing consumed so much time it looked like the main job.
if generating code got cheap, the work moved. it left the writing and went into the understanding. and understanding, to count for anything, has to live in more than one head. that’s not a process detail — it’s what defines whether a repository belongs to a team or to a person who happens to work on a team.
review is expensive. it’s more expensive now than before, because PRs got bigger and more frequent. and it’s more necessary now than before — exactly because writing got cheap, and the only way to keep every feature from becoming the author’s private property is to force a second human head through the diff.
anyone still treating review as a redundant layer after the others isn’t wrong about validation. they’re wrong about what review is.
the line “I already validate it five times before opening” is honest, technical, respectable. and it is also, unintentionally, the perfect definition of the problem. five layers of validation are still one head.
this is the philosophical version. in testando em produção (in portuguese) I wrote about the tactical side: what PR size limits big teams actually practice, what anthropic, google, and openai do internally to solve this, and what you can start doing tomorrow without swapping any tooling.