Why do so many people think that code reviews are primarily about mistrust or spotting mistakes?<p>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..
Of all the many things I hate about this era of tech, the elevation of bad programmer culture to the stratosphere is definitely top 5.
We don't need shared understanding and agreement in the AI era. The AI will do that for us.
[dead]
> But a lot of the reason rewrites were so dangerous is that they took forever, and the old system kept changing underneath yo<p>I think a bigger reason is that people don't understand why the current system is the way it is. That risk is increasing with lower j understanding of the codebase. (doesn't apply as much to building the same thing in a different language)
Something's wrong with that code review strategy. There should be knowledge share.<p>And yeah perverse incentive is a thing when you grad your own homework.<p>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.
> The thing that’s really changed here is that the cost of context switching has dropped dramatically, because we’re operating a level higher than we used to.<p>I completely disagree with this.<p>I would argue that the cost of context switching has dramatically increased, since within the agentic pattern, an engineer is now forced to work at a higher pace across multiple topics; even if operating at a higher level, the amount of information required to be processed by a human brain is generally overwhelming.
To your note about nobody doing code reviews. I've found that to be fine in fairly straightforward applications and/or small teams where individual SWEs can own verticals.<p>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.<p>Not to shill my work too much (<a href="https://www.archme.io" rel="nofollow">https://www.archme.io</a>) 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+.
And that way, bit by bit, we become dependent on a few global corporations that own the brain that we used yo use. Brain as a service, dammit. Don't get banned on a whim or you'll lose your ability to think.
> Bad ideas that aren't bad anymore<p>...<p>> About a month ago we changed that <i>[PR process]</i> completely.<p>...<p>> And it’s been working great!<p>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?<p>Seems that all you are measuring is short-term gains, not long-term liabilities.<p>You can see the same "gains" in any endeavour if you're willing to eat the seed-corn.
> Deep expertise in a specific technology is a lot less valuable when you have a collaborator that has read all of the source code for that framework and can answer any question about it in a few seconds. This is another case (like what I mentioned above) where knowledge is less valuable, but where judgement is still important.<p>How can one judge on something they don't know?
[dead]
They were only bad ideas for puny human brains. But for super intelligences...<p>Experience has less value now.