To code review or not to code review. That is NOT the question.

Once agents multiply everyone's throughput, the scarce resource in an engineering org stops being engineering time and becomes review attention.

Code reviews were never one activity. Blake Smith's classic breakdown lays out their multiple purposes nicely: keeping the team's mental model of the system current, verifying the change solves the problem, surfacing design strengths and weaknesses, catching bugs, and keeping style consistent.

For each of those functions, we need to ask if a human reading a diff is still the best tool. Increasingly, the answer varies by purpose:

• Style belongs to linters and agent instruction files (CLAUDE.md rules and their cousins). It also just matters less when LLMs write and maintain the code. I've yet to see Opus start a religious war with 5.5 over tabs versus spaces.
• Bug-catching is increasingly done better by LLM review agents. They're not perfect and they'll flag a decent number of useless findings, but they're tireless and catch more than all but the very best reviewers in significantly less time.
• Correctness is best verified by robust test suites and automated guards. Tests and evals are stored review: every check we automate is attention we get back next week.
• Design quality still requires humans. LLMs are great at producing a correct solution but remain limited at selecting the optimal architectural one, especially from low-context "fix this" prompts in less-than-mature codebases. This area still requires human oversight and separates good prompters from slop cannons.
• Mental alignment is the team's shared understanding of the codebase and it's incredibly fragile. Unfortunately, I'm not convinced that having multiple team members read a 10,000-line pull request is (or ever was) an efficient way to transmit it. To be fair, this isn't a problem unique to AI-assisted coding. Every company has the guy who's indispensable because he's the only person who actually understands the thing. The new risk is that you can create a codebase that no one understands, not even those who built it.

So the human functions that remain are design and alignment. Conveniently, one practice serves both.

Anything that will take more than a day of work gets a short design discussion first. It doesn't need to be a Design Review with "Stakeholders" and "Decision Makers". Often an informal chat at the end of standup or with the engineers who'd historically review your code will suffice.

Low stakes design reviews:

1. Improve solutions and catch early mistakes
2. Create shared knowledge of what we're building
3. Train junior developers and expose them to how seniors think

The trick is keeping them long and consistent enough to be useful while short enough to prevent them from becoming a bottleneck.

I don't always hold myself to this rule. I haven't figured out the perfect cadence yet and am still experimenting. And it's important to remember that review decisions sit in the context of your team's and organization's risk posture. Sometimes you want to trade velocity for safety and vice versa.

All that said, I will advocate for some pre-merge validation. However, the amount depends on a sliding scale trust policy set for individual team members. Engineers move between tiers when they switch teams or level up their skills.

The tiers:

• The every-PR tier. Nothing merges without a senior read. New and junior teammates usually start here. This is how I prevent my intern from accidentally changing our PHI rules.
• The design tier. One-off issues can go through without additional review, but big features require design check-ins.
• The let-them-cook tier. Full autonomy. You come to me when you need help.

Actual reviews aren't necessarily full code reads. Often, I'll write a special agent skill to summarize the changes and review the specifics I care about like architectural choices, what level of testing was applied, impact on the DB, etc. Once diffs reach a certain size, it's dramatically more effective to review this way.