Matheus Lima points at an assumption most of our work habits still rest on: producing something means you understood it. Send me a PR and I assume you read the code. Send me a brief and I assume you did the research. Generated output breaks that — code, docs, and answers to review questions can all look finished, and often be correct, without the author having checked any of it.
What changes in practice:
- The first review question stops being “is this a good change?” and becomes “does this author understand what they sent me?”
- Trust is the mechanism that lets you review only the parts needing a second pair of eyes. Lose it and you redo the whole investigation.
- The cost is asymmetric: one shortcut — a non-answer to a specific question, a tone that smells generated — buys scrutiny on everything that person sends afterward.
- “Claude wrote it” tells you nothing about what was checked or whether the author agrees with the result.
Lima admits he’s been on both sides, having merged an AI-written fix he didn’t understand (it happened to be correct; he hadn’t done the work to know that). His fixes are cheap and mostly social.
For engineers: read your own diff before sending, understand why the bug happened and why the fix resolves it, and ask reviewers-to-be specific questions like “which cases did you test?”
For leaders: make “ready for review” mean it, ask for a proportional statement of what was verified, make it safe to share labelled unfinished work — and don’t send slop yourself, because your team will match the standard you set.
The line to keep is simple: your name on the work should still mean you understand it and stand behind it. Otherwise every submission hands the reviewer your part of the job before they can start theirs.