This is likely more relevant when you present something to a business leader who has the feeling they have to contribute something, but it can also apply to inexperienced code reviewers.
When junior developers join my team, I find that they're often shy about critiquing anyone else's code because they assume they're the least skilled person, so they couldn't possibly find anything to be improved in anyone else's code.
I've considered sending developers like this a code review and including the note, "And just so you feel comfortable suggesting improvements, I've intentionally left in one mistake (not necessarily a functional bug)."
I've never done it because I worry it comes across as condescending. Like, "Obviously I'm perfect, but to give you something to do, I added a mistake, and now it's your job to go digging around for it."
Instead, I try to reassure junior developers that they should feel comfortable making suggestions and asking questions in the code review, even if they're not finding things that are officially "bugs."
Over the years I noticed that reviewing the same code knowing a bug is there will increase my chances of finding it comparing to not knowing a bug exists.
It would be interesting to measure if introducing a "catch" in every PR would increase the number of times the reviewer will find additional issues.
You should fix that instead of trying to hack around this. Code review shouldn't be a nitpicking party for people that need to drum up their egos.
Are you really suggesting that developers purposely introduce bugs into a code base just to keep reviewers on their toes?
It may seem like a relatively harmless idea in the small, but in the large, imagine hundreds or thousands of developers taking this advice, and purposely committing bugs. Yikes.
If people want to use this approach as a training exercise (as mtlynch suggested in a sibling post), that's one thing, but that's not what OP suggested, and what OP suggested seems like pretty risky advice.