I used to spend most of a review reading code.
Now I spend most of it reading the diagram nobody drew.
That shift didn't happen because I got lazy about code. It happened because I kept noticing that the reviews which actually saved a project were never about the code in front of me. They were about the shape of the thing the code was part of, the shape that no diff ever shows you.
Two reviews, two very different price tags
There are really two reviews happening, and we usually only schedule one of them.
Code review catches the bug in the function. Architecture review catches the bug in the plan. Both are useful. They are not remotely the same size.
A code review finds:
- a missing null check
- an off-by-one
- a test that asserts nothing
- a confusing name that'll trip up the next person
An architecture review finds:
- a service that owns data it has no business owning
- a boundary drawn in the wrong place
- a synchronous call that should never have been synchronous
- a workflow that can't be undone once it goes wrong
You can fix a null check in five minutes. You can't fix a wrong boundary without a migration, a rollout, and a quarter of regret.
That asymmetry is the whole argument. The code-level findings are cheap to find and cheap to fix. The architecture-level findings are easy to miss and brutal to correct, because by the time they're visible they have data in them, teams depending on them, and a year of accumulated assumptions wrapped around them.
Why the cheap review feels productive
If architecture review is so much higher leverage, why do we default to reading diffs line by line?
Because code review feels productive. It's concrete. There's a diff, there's a comment box, there's a satisfying green checkmark at the end. You can point at the off-by-one you caught and feel like the review did something.
Architecture review feels like meetings. It's a whiteboard, a design doc, an uncomfortable question asked at the wrong time. There's no checkmark. The win is invisible: a migration that never had to happen, an incident that never occurred, a rewrite that never got scheduled. You don't get credit for the fire you prevented, only for the one you put out.
So we optimize for the visible work and quietly skip the valuable work. This is the same trap as mistaking "it works" for "it's ready": the demo runs, the diff is clean, and both of those tell you almost nothing about whether the underlying decision was sound.
AI made this worse, then made it obvious
This already mattered. AI turned it into the whole game.
When the code itself is increasingly generated and increasingly clean, the code-review layer has less and less to find. The functions are organized. The naming is reasonable. The tests exist. What's left is a perfectly competent implementation of whatever decision you fed it, including the bad ones.
A clean implementation of the wrong boundary is the most dangerous artifact on a team, precisely because it passes every check that code review knows how to run. The polish hides the problem. That's why the review moved up the stack: the bugs that survive now aren't in the lines, they're in the structure the lines obediently implement.
What an architecture review actually asks
If you want to run the higher-leverage review, the questions are unglamorous and they happen early, ideally before there's code to look at:
- Ownership. Who owns this data, and does anything else reach into it directly? Shared ownership is just an unscheduled argument.
- Boundaries. Is this seam in the right place, or did we split where it was convenient instead of where it was correct?
- Coupling. Is this call synchronous because it has to be, or because that was easiest to write? Synchronous-by-default is how a slow dependency becomes your outage.
- Reversibility. When this goes wrong, can we undo it? An irreversible workflow is a decision you only get to make once, under pressure, in production.
- Operational reality. Who runs this at 3am, and does the design account for the reality of operating it rather than just shipping it?
None of those show up in a diff. All of them determine whether the diff was even worth writing.
Review the part that can sink you
I'm not saying stop reviewing code. The null check still matters and someone should still catch it. I'm saying notice where you're spending your attention, and notice that it's probably inverted.
The code is the easy part to review. It's also the cheapest part to fix. If you only review the code, you're carefully inspecting the one thing that was never going to sink you, while the thing that actually sinks projects sails past in a design doc nobody read closely.
The one-line version
Code review catches the bug that costs five minutes. Architecture review catches the bug that costs a quarter. Spend your attention accordingly.