Code Review is an Anti-Pattern
I'm not the only one to have had this controversial thought. It seems to rub some folks the wrong way, but code review in general is a huge waste of time. On any given team there are approximately 5% of the team ornery enough to care about "code quality" to endeavor on the task of telling other people to change how their code is written. And, because it's only ever a small cohort, the whole job inevitably falls on them to perform the code review! This type of pareto distribution isn't new (80-20 in terms of work completion is a common complaint) but specifically if the intention of code review is to improve "code quality" then the vast majority of the time it is not doing that.
I prefer effective review stages. I want good review! If my software is going to meaningfully exist alongside other people's software we have to somehow reconcile our different versions of the build together. But just stating "have better taste" doesn't mean anything when the 5% of the team is now left reviewing an order of magnitude more PRs from junior developers, some of whom might not even really know how to actually code by hand anymore. "Reconciling code" cannot functionally remain a manual process, in the same way that most teams these days are not functionally capable of manual release cycles due to volume. CI/CD isn't really optional after a certain scale, and that scale margin (headcount of developers within a department) has been reduced significantly.
And while there are tools out there that can perform non-static code analysis, they still require the time and attention of development teams to write down the standards and expectations of their code and to provide those standards/expectations to the tools performing the analysis. And with agentic analysis you still lose the benefits of discussing code patterns with junior developers and building relationships with one another while building inside a shared environment. If the purpose of code review is to provide guidance/counsel to juniors while also maintaining useful coding standards then
- code review isn't currently doing that well
- software engineers have been coping about code review for years
- we finally have an opportunity to build software communication platforms that will functionally work in favor of the requirements, not just pretend to
I desire practical review stages, and I think agent harnesses underlie the functional review stage. I think instead of reading code we should be discussing the purposes and design patterns in context of the business requirements, and encoding that knowledge into a shared, discoverable repository where new code can immediately draw from rather than require blind discovery from accidentally stepping on some senior engineer's toes. I think the zed team are on to something (I routinely use their IDE, I'm a shill frankly), but also I'm not certain we've really explored the space in meaningful depth yet. Basing our assumptions off of code review itself has driven the conversation in a direction that somebody who knows better would have immediately noted as an anti-pattern. "I know this looks fine and almost clever now, but once you scale this pattern it's going to require an enormous amount of effort to detangle it."
Steve Yegge actually discusses some of these alternatives in depth, so I won't really go too far further. It just felt important now as I'm actively configuring my remote CI/CD review and deployment strategies for this web page and my project repository. I don't "review" the code in detail but I still read and write within it to keep up with the patterns and scalability needs as the agents delegate work and prioritize.