Code reviews are also a fairly long feedback loop. There’s PRs with thousands of lines of code changed. And PRs with a few lines in one file. I’d question whether we’re doing code reviews right in the first place. Leveling it up to first principles: why do we do code reviews and is there a better way?

Being able to run fast and learn means having rapid feedback loops. In the agile world, there’s pair programming — a real-time feedback loop that (mostly) eliminates after-the-fact code reviews at the expense of two engineers doing one task. Many teams also estimate tasks and break down to smaller ones to speed feedback loops. In doing these, “the questioning,” the “vague ask,” and the “many-commented review” can be resolved up front or during development, which can save quite a bit of time and aggravation.

Essentially, communication and feedback at much more frequent intervals is another answer for what to do. Learn from the bad PR experience to shorten feedback loops for future PRs. And to your point, that should also go a long way in building trust.