Somewhere in your review queue is a pull request that will be approved without anyone reading it. You can picture it: the diff opens, a reviewer’s eye moves down it, then the green button. LGTM.
AI-generated pull requests arrive faster than qualified reviewers can read them. GitHub’s merged pull requests grew from 25 million a month to 90 million a month in three years, and the queue stopped being something a team could empty. The human gate is a control; when it stops holding, “reviewed” becomes false assurance.
This article names the two responses: code review “surrender”, the ritual continuing after the reviewer has privately stopped believing it is real, and code review “exploitation”, the reviewer absorbing the cost of an unworkable queue. Both share one visible artefact, the rubber stamp, which shows up in your data while the cause stays hidden.
A rubber stamp records that an approval happened; it says nothing about what was checked. So what is happening to the reviewers?
What is code review “surrender”, and how is it different from a deliberate decision to stop reviewing?
Code review surrender is what happens when reviewers keep performing the review while privately stopping believing the review is real. They open the diff, scan for shape rather than logic, leave a comment that shows attention without requiring any, and approve. The behaviour is there; the belief is gone. That gap is what distinguishes surrender.
This is different from deciding to stop reviewing. A deliberate decision to remove the review gate is honest: it can be written down, risk-accepted and governed. Surrender is the reverse. The policy still says “human review required” and nobody believes it, so your process documentation stays accurate on paper and false in practice.
Reviewers who surrender usually still believe review matters. Michaela Greiler, who named the term, stresses this. What withdraws is the belief that this particular approval is doing anything. It is a capacity failure, so reviewers stop meaningful review with little or no alternative. As AI raised both the count and the size of pull requests, median size grew 64%.
The distinction matters because the remedy differs. More review policy cannot fix surrender; the volume was the broken part. The fix is less unverifiable work, covered in how stacked pull requests and context engineering reduce review load. Approval fatigue is the mechanism underneath.
What is code review “exploitation”, and why do reviewers feel it without ever raising it?
If surrender is the belief side, exploitation is the cost side. Code review exploitation is the reviewer absorbing the cost of an unworkable queue: evenings, deep-work blocks, the mentoring conversation that never happened, a standard they cannot meet. None of that cost appears in any metric your organisation collects.
Reviewers rarely raise it. Speaking up sounds like a competence complaint, “I can’t keep up.” The queue is no one’s fault in particular. And the alternative is blocking delivery.
Review is counted as an event rather than hours, so the absorbed cost never shows up in capacity planning. One developer said in DORA’s study: “I spend less time writing code, I spend more time babysitting the AI.”
Senior engineers absorb most of it, because they hold the pattern recognition to catch what AI gets subtly wrong. That is the senior time this quietly consumes, covered in what teams lose when no human reads the code before it ships. Before the fix can work, though, it is worth seeing why the model keeps collapsing in the first place.
Why does the “agents write, humans review” model keep collapsing into rubber stamps?
Three properties of AI-generated change defeat vigilance-based review. Plausibility: AI code is idiomatic, tidy and consistent, removing the anomaly signals that bad human code used to announce itself, and a model can produce hundreds of lines of plausible, consistent code with subtle semantic errors. Volume: the queue never empties, so reviewers settle into a sustainable but shallow pace. Diffuse accountability: no single change feels risky enough to justify the deep read.
Add approval fatigue and the collapse becomes all but inevitable, regardless of individual diligence. Sustained vigilance against a stream of plausible changes degrades, and the threshold for “looks fine” falls. The Google Cloud Office of the CTO describes the shift: the bottleneck moved from writing code to reviewing it, and a stream of micro-approvals turns approve into a reflex. Under high AI adoption, 31% more pull requests merge with no review at all than in low-adoption teams.
“Humans review” is a control, and a control that is performed but not effective is worse than a documented absence of control, because it produces assurance nobody can tell apart from the real thing. The audit trail says “reviewed” while nothing was verified.
That leaves one question: why name the two conditions at all?
Naming the two conditions is what changes the argument. Surrender and exploitation give the failure a structural vocabulary, so saying “our reviewers have surrendered” accuses no one, because the phrase names a queue problem. Plausibility, volume and diffuse accountability do most of the work, and approval fatigue does the rest, which is why the false assurance above is so hard to spot.
The answer is less unverifiable work and visible author-side verification, plus a reckoning with the senior time this consumes. The sequence is mapped in the complete picture of the review collapse.
Frequently Asked Questions
Is rubber-stamping the same thing as LGTM culture?
Not quite. LGTM culture is the name for the norm, the shared expectation that a quick “looks good to me” is an acceptable contribution. Rubber-stamping is the behaviour itself: an approval granted without reconstructing what the change does. Both describe the same visible artefact, and neither explains it. The cause sits upstream in the queue, the shape of the change and the reviewer’s dwindling belief that the ritual is real.
Is this just reviewer burnout by another name?
No. Burnout is a psychological state, and it can happen in any job. What this article describes is structural: a cost absorbed because the queue makes the work impossible, and a withdrawal of belief because the ritual stopped matching reality. A rested reviewer returning to the same queue will reproduce the same approvals within weeks. That is why leave, wellness programs and headcount gestures do not shift the pattern.
How can you tell a rubber stamp from a genuinely trivial approval?
Ask the approver to state the intent of the change and one thing that would break it, without reopening the diff. A genuinely trivial approval survives that test, because the change really was a version bump or a copy edit. A rubber stamp does not. The distinction is not how fast the approval happened, since a fast approval of a small, well-described change is exactly what good review looks like.
Does requiring two approvals stop rubber-stamping?
No, and it usually makes things worse. Two approvers do not produce twice the scrutiny; they produce two approval events and a quieter sense that someone else must have read it. Diffuse accountability spreads further, and each reviewer’s threshold for “looks fine” falls a little faster. The number of signatures is not a measure of the control’s strength. What was verified matters more than how many people clicked approve.
Can AI-generated code be reviewed properly at all?
Yes, but not with diff-only review at current volume. AI-generated code is plausible, idiomatically clean and structurally tidy, which removes the anomaly signals reviewers once relied on. Reviewing it properly means seeing the intent, the constraints and the evidence behind the change, and holding a small enough diff in mind to reason about it. The problem is the mismatch between the method and the shape of the work.
Are reviewers really seeing more code, or are they just slower?
Both, but not in equal measure. Reviewers are receiving more changes, and the changes are larger and more plausible than they used to be, so each one costs more attention than its line count suggests. The queue is a function of arrival rate versus departure rate. When arrivals triple and departure capacity stays flat, the queue grows regardless of how hard anyone works. Slowness is the symptom, not the cause.
Do AI code review tools fix the problem?
Not on their own. An AI reviewer can add comments and catch some classes of defect, but it does not restore the reviewer’s belief that the human gate is real, and it does not make the absorbed cost visible in capacity planning. It can even raise the noise floor, since comment volume goes up while the human burden stays the same. The control problem is about accountability, and a tool cannot hold accountability.
What happens to the audit trail when reviewers rubber-stamp?
It keeps recording approval events, which is precisely the problem. The audit trail will show that every change was reviewed by a named human, and that record will be accurate about the event and false about the scrutiny. A performed but ineffective control is worse than a documented absence of control, because it produces assurance that no one can later distinguish from the real thing. Compliance evidence quietly becomes fiction.
What happens to junior reviewers when the queue outruns capacity?
They learn the norm before they learn the craft. A junior reviewer under an unworkable queue copies what the senior reviewers do: open, scan, approve. The feedback loop that would have taught them to read logic, question intent and recognise risk is the first thing the queue removes. They also inherit the invisible cost earlier, without the pattern recognition that makes deep review possible in the first place.
Should teams stop requiring human review for AI-generated code?
That is a legitimate choice only when it is made openly. Removing the requirement and documenting the risk is an honest position that can be governed and revisited. The failure described here is different: keeping the requirement, performing it, and quietly not doing it. The question is not whether humans review everything, but whether the approvals you claim are real. An absent control you know about beats a control you only appear to have.
How can you measure rubber-stamping without surveilling reviewers?
Measure the conditions rather than the people. Track how long changes wait for review, how often merged changes are reverted or reopened, and how much of the queue is small enough to review well. Then sample merged changes and ask the approver to explain intent without the diff. If they cannot, you have found a structural problem, not a lazy individual. Counting comments or approval speed tells you almost nothing about whether verification happened.
