The Unreviewed Commit

Consider a pull request with four hundred lines of agent-generated code. The tests pass, the description is clear, and the reviewer has ninety seconds before the next meeting. A quick scan ends in an approval.

This is a hypothetical example, but the engineering question is practical: what has the team actually established before merging? Passing tests provide evidence about the cases they cover. Approval should also establish that someone understands the change, its assumptions and its failure modes.

What review was actually for

Code review serves several purposes: finding defects, challenging design choices, checking requirements and sharing knowledge. Tests, types and static analysis help, but they do not replace those judgments. As a diff grows, a reviewer needs more time and context to make them well.

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.

Start review with intent. Before generating code, agree on the interface, constraints and failure modes. Then split the implementation into reviewable changes and check the diff against that agreement. Reviewing a specification helps focus code review; it does not replace it.

Check the tests independently. An agent can help write tests, but the implementation and its tests may share the same mistaken assumption. Have a person review expected behavior, add negative cases and check the requirements the generated suite may have missed.

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.