The Rubber-Stamp Stage
The PR has a confident summary, six green badges, and nobody who can explain the authorization change.
What it is
The Rubber-Stamp Stage is code review that approves AI-generated changes without evaluating the important design and behavior. The reviewer reads the summary, sees green checks, and clears the queue. Approval records that someone clicked a button; the team treats it as evidence that someone understood the change.
What the summary leaves out
In an illustrative document-export PR, AI adds an endpoint, moves shared helpers, and reformats several files. The description says “adds CSV export with tests.” The new route checks that the caller is signed in but never checks whether the requested document belongs to that caller’s workspace. The tests use only the document owner.
Give a review agent the actual diff, the workspace-isolation rule, and the relevant callers. Ask it to trace the authorization path and find a request that would violate the rule. That is a different assignment from “does this look good?” A senior reviewer can use the trace and run the denied request to challenge the claim, without manually repeating every lookup. The evidence must survive checking against the code.
Why it’s dangerous
A team can generate changes faster than its current review process can assess them. The response need not be less AI: AI can investigate callers, compare contracts, and identify risky paths. The problem is treating its findings as a complete list of everything that could be wrong, then assigning a person to bless that list. Two agents agreeing is weak reassurance if both were given only the implementation and its summary, with no statement of the behavior it was supposed to preserve.
Review effort should follow consequences. A thousand lines of generated data may need a generator and sample check; a five-line authorization change can need careful domain review. Diff size is a useful warning, not a reliable measure of risk or a reason to split one coherent change into fragments nobody understands together.
How to make review possible
Keep unrelated formatting and refactoring out of the behavior change. Explain the user-visible result, the important decision, and the checks that could expose a mistake. For the export, name the ownership rule and show a denied cross-workspace request. The author should verify claims in an AI-drafted description before asking anyone to rely on them.
Google’s code-review guidance includes design, functionality, complexity, tests, and the surrounding context. Use AI to gather that context and challenge the change. For this export, the useful review output is the ownership check’s location, the denied-request result, and any path the review did not cover. A bot’s “no findings” message is much less informative.
The serious team fix
- Assign a review people can perform. Route the export to someone who understands workspace isolation. If the change spans several domains, assign clear coverage and let reviewers see the whole design. Decide which low-risk changes can pass through enforced automated checks and which need domain review. Keep an explicit escalation path for uncertain cases. Allocate review time and limit work in progress; requiring a human signature on everything can manufacture the rubber stamp.
- Make known rules executable. Enforce relevant checks in the merge path. In this case, exercise allowed and denied requests against the application’s real authorization configuration. Type checks and lint reduce mechanical work but cannot establish that one customer is forbidden from reading another’s document.
- Keep approval attached to what was reviewed. Use repository controls to require the agreed checks and reviewers, and require renewed review after material changes. An approval of the first version should not authorize a later rewrite of its permission logic. Record emergency bypasses and follow up on them; otherwise the exception quietly becomes the release process.