Rubber-stamping
Rubber-stamping is approving a pull request without reading it closely enough to find a defect, so the approval records that a review step happened rather than that the code was checked.
Why it matters
Many teams make an approval a merge requirement, so the approval is the control. A rubber stamp keeps the control in place on paper while removing it in practice: the change merges with a reviewer's name on it and nobody has asked what happens on an empty list, a second request or a hostile input. It is most common on large diffs, on changes from trusted colleagues, and on code that already passed CI or an AI reviewer.
The fix is not to approve less. Some pull requests are correct, and an approval is the right verdict for them. The skill is earning the approval: reading the requirements first, then the diff against them, and approving because you looked for the failure modes and did not find any. DiffDojo mixes clean pull requests into its library for that reason, so a reviewer is graded on approving the right ones as well as on catching bugs.
See also
- Automation complacency
- Escaped defect
- Worked example: body-only edits don't reliably autosave: body() is read outside effect's tracking in Angular, a change that looks finished and passes a quick read