IMO they’re primarily about ensuring shared understanding and agreement, not just about how things are changing now, but how they’ll change in the future..
How can one judge on something they don't know?
And yeah perverse incentive is a thing when you grad your own homework.
And these two things combine. Who decides what "done" means? If everyone faces consequences for getting that wrong the next day it's probably fine, but they probably don't.
As soon as you have larger teams with complex architectures trying to make decisions and push larger initiatives forwards, decisions made in one part of the stack really matter in other parts as they get built on and have momentum that can be hard to reverse, even if code is cheap.
Not to shill my work too much (https://www.archme.io) but I think for the reason above the importance of code review has moved from code to architecture, and code in general is the wrong abstraction to be working with as a human engineer in 2026+.
If the spec cannot resolve ambiguity you refine the spec not the code.
...
> About a month ago we changed that [PR process] completely.
...
> And it’s been working great!
How can you tell it's not a bad idea in just a month? How can you tell that it's been working great in just a single month?
Seems that all you are measuring is short-term gains, not long-term liabilities.
You can see the same "gains" in any endeavour if you're willing to eat the seed-corn.
Experience has less value now.