I find it particularly hard to state that you "should" or you "shouldn't" do that..
For instance, I've worked in a company that used PRs just like that, with code review working through the new code's logic. There were some cases where this approach led to a massive overhead in code review, making some people spend hours reviewing code.
However, that approach also made us avoid hundreds of bugs throughout the 5 years I've been there, specially when the one reviewing was one of the 2 developers that were there for more than 8 years.
Perhaps the best way to reach an agreement in this subject would be to get some examples on bugs you've not found and had to solve weeks later, and see how many hours you had to spend on them. Compare that to how long you usually take reviewing code, and you'll have a more solid view on "is it worth it?" (you might also consider how many bugs you have actually found using this approach, maybe your team is experienced enough to make it unnecessary).
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I find it particularly hard to state that you "should" or you "shouldn't" do that..
For instance, I've worked in a company that used PRs just like that, with code review working through the new code's logic. There were some cases where this approach led to a massive overhead in code review, making some people spend hours reviewing code.
However, that approach also made us avoid hundreds of bugs throughout the 5 years I've been there, specially when the one reviewing was one of the 2 developers that were there for more than 8 years.
Perhaps the best way to reach an agreement in this subject would be to get some examples on bugs you've not found and had to solve weeks later, and see how many hours you had to spend on them. Compare that to how long you usually take reviewing code, and you'll have a more solid view on "is it worth it?" (you might also consider how many bugs you have actually found using this approach, maybe your team is experienced enough to make it unnecessary).