The Unreviewed Commit
I merged a pull request last Tuesday that I did not read.
Precision matters here, because the comfortable version — "I reviewed it quickly" — is the lie this post is about. I opened the diff. Four hundred lines. An agent had written them in the time it took me to refill my coffee. Tests green. The description was clear, well-organized, almost suspiciously articulate. I scrolled to the bottom, saw nothing that alarmed me, clicked the button. Actual human attention: ninety seconds, give or take. It is in production now. It is, as far as I know, fine.
"As far as I know" is carrying an enormous amount of weight in that sentence. Across the industry, it is now carrying it at scale.
What review was actually for
We told ourselves for twenty years that code review catches bugs. It doesn't, particularly. Bugs are caught more reliably by tests, types, fuzzers, and static analysis — the deterministic machinery that doesn't get tired at four in the afternoon. Every serious study of review effectiveness lands in roughly the same place: defect detection is real but modest, and it falls off a cliff as diff size grows.
What review actually did was distribute comprehension. Two people understood the code instead of one. Knowledge of how the system worked lived in more than a single head.
That distinction didn't matter much when humans wrote everything, because comprehension came bundled with authorship — you understood the code because you'd written it, and the reviewer was the second copy. The author is a machine now, and the bundle has come apart. If nobody reads the diff, the number of humans who understand that code isn't one. It's zero.
The asymmetry
An agent produces code faster than any human can genuinely read it. Not skim — read. Hold in your head. Argue with. The gap isn't marginal, it's categorical, and it doesn't close by trying harder or hiring better. So teams do what people always do with an impossible demand: keep the ritual, drop the substance. We still call it review. It's approval. The green checkmark migrates from "I understand this" to "nothing jumped out at me," and those are not the same claim.
The cost shows up in the only terms that survive a budget meeting:
- Incidents run longer. Time-to-resolution is a function of comprehension. An on-call engineer who has never seen the code is doing archaeology while the dashboards are red.
- Bus factor hits zero without anyone leaving. You didn't lose the knowledge when someone quit. You never acquired it.
- "Why does it do this?" stops having an answer. Intent used to be reconstructable from the person who wrote it. Now git blame points at a model, and the reasoning evaporated when the context window closed.
- Change gets more expensive every quarter — which is the definition of the thing we're about to talk about.
Debt, taken literally
"Technical debt" has gone soft from overuse. We say it like a parking ticket: a nuisance to clear in some calm sprint that never arrives. But the metaphor is exact and worth taking at face value. You're borrowing against future capacity, and the interest compounds.
The unreviewed commit borrows comprehension you never earned. The loan gets serviced later, by someone else — your future self, the engineer who inherits the service, the on-call at 3 a.m. who has to understand it under fire. They didn't approve the loan; they pay it anyway. And unlike most technical debt, this kind is invisible on every dashboard you own. Velocity looks fantastic. Right up until the incident.
What actually works
Not "slow the agents down." That argument already lost, and it deserved to. I build these systems — agentic coding is the biggest leverage I've found in fifteen years, and the output is frequently better than mine: less tired, less attached to a clever idea from 2019. The goal isn't less generation. It's putting human attention where it still has leverage.
Move review upstream, to the spec. You can't meaningfully review four hundred lines of generated code. You can review the twenty-line intent that produced it. Argue about the interface, the constraints, the failure modes — before generation, not after. That's the highest-leverage human hour in the loop.
Write the tests yourself. If the agent writes the code and the tests, you've verified nothing — it's a closed loop grading its own homework. Human-authored tests are the one artifact that keeps meaning what you think it means.
Budget comprehension explicitly. Decide which parts of the system humans must understand — boundaries, money paths, the data model, the security surface — and enforce real review there, at human speed. Everything else can be a box you're genuinely prepared to throw away.
Prefer disposable over clever. Code nobody understands is only acceptable if you can delete and regenerate it cheaply. That means small modules with clear interfaces and a small blast radius. If regeneration is scarier than repair, you needed to read it.
Track the real number. How many lines shipped this week that no human read? Most teams can't answer. The ones who can are the ones making this trade deliberately rather than by accident.
The trade
The merge button isn't a productivity action. It's the moment your organization says: we own this. Click it without understanding and you haven't shipped faster — you've shipped at the same speed and quietly removed the part where a human is accountable for the result.
That can be the right call. Plenty of code deserves exactly that treatment, and pretending otherwise is how you end up reviewing generated CRUD line by line while your competitors ship. But it should be a decision with a name and an owner — not something that happens to you ninety seconds at a time, while the checkmark turns green.