| For #1, code review hasn't really existed long enough to be a "tradition" — everyone does this differently. For example, my internship was "here's a book on python, get some stuff done"; and my first few jobs out of university included one where I had exactly one mentor review my code for a few months before they left, a second where I was the only person who knew how the platform worked, and a third where my theoretical peer was someone who refused to listen or share knowledge. And all that was about 15 years ago. For #2, society has weird risk responses. It's not that we "expect" self-driving cars to be 10x better, it's that we need them to be 10x better just to feel as if the risk is the same when we're not in the driving seat. Code generation doesn't need this. Bluntly, most managers don't have much reason to care about code quality already — I suspect many categorise us devs talking about "technical debt" (and similar) in the same way they categorise free yoga classes and table tennis sets in the office: a cost of hiring devs, but not a real business requirement. For #3, when they're better in general, all bets are off. It's like chess engines: we go from being in control, to helping spot mistakes, to just getting in the way because we "hallucinated" something that wasn't really a consequence of the code or of the ticket or etc. For #4, we will always find fault, but it will become asymptomatically rare for the faults we find to be both real and not merely aesthetic. |