A couple of months ago, I wrote about my client team’s decision to make human code review optional: an approval from an AI tool became all that was needed to merge. At the time, I said it was too early to tell. Now, enough time has passed to share some honest reflections.
The Norms Didn’t Hold
Shortly after the change to the PR review process was announced, we’d agreed on a handful of norms to keep some intentionality around review. Unfortunately, most of those team norms were abandoned within a few weeks. We stopped sharing PRs for visibility, and reviewers stopped being requested (even on the riskier changes we’d said deserved a human look). The investment in automated test coverage we’d called more important stayed de-prioritized as well. As external pressure to deliver grew, our informal agreements to one another were put on the back burner. A team facing high pressure to deliver work quickly will rarely choose to make time for the optional, nice-to-have things.
What AI Review Missed
Our review bots were pretty good at catching bugs and flagging code quality issues. Given high-quality ticket and PR descriptions, it was even decent at checking that the business requirements were met. However, a human reviewer doesn’t just flag what’s wrong. They notice what could be better: an enhancement worth considering, a refactor opportunity, or a problem that’s already been solved elsewhere. The AI reviewer approves working code and moves on, and opportunities for improvement are never shared or discussed together.
Less Teamwork
On a remote-first team, code review is an important way to stay aware of the problems your team has been solving. Without it, the awareness of what your team has been up to fades. It’s harder to offer help when you don’t know what challenges someone has been wrestling with, and it’s harder to learn from your team’s work when you don’t actually get to see it. Recurring touch points and dev syncs with other developers helped a little, but we quickly ran out of topics to discuss as we became further removed from the work that other people on the team were doing. PR review is one of the only consistent windows into each other’s work, and I don’t think there’s a great replacement for it.
It Depends on the Team
I’ve since rolled off that team. Despite some of the challenges we faced in that team environment, I’ve continued to work under an optional code review policy. It’s been more manageable on a smaller, higher-trust, and colocated team that has better insight into the work each other is doing throughout the day. In that kind of team environment, the visibility that formal code review provided happens on its own. I don’t land on “optional code review is bad,” but on something more conditional. It takes away a process for sharing knowledge and holding each other accountable, and how much of a loss that is depends on the team.