There's a code review that's easy to give and a code review that's hard. The easy one is when the implementation is wrong — wrong variable name, missing error handling, inefficient loop. You point it out, the author fixes it, everyone moves on. The hard one is when the implementation is fine but the architecture is wrong. The code does what it's supposed to do. It's just solving the wrong problem.
This is the code review nobody wants to give because it's not really a code review anymore. It's a conversation about design, about requirements, about what the system is actually supposed to do. And that conversation is expensive — it might mean throwing away the work that was just done, which nobody wants to say and nobody wants to hear.
I've been on both sides of this. I've written code that was technically correct and architecturally wrong, and I've had to review code that was technically correct and architecturally wrong. The experience is different depending on which side you're on, but the discomfort is the same.
Why It's Hard to Say
The reason the architectural code review is hard to give is that it feels like a personal criticism in a way that an implementation criticism doesn't. If I tell you your variable name is wrong, I'm telling you about a line of code. If I tell you your architecture is wrong, I'm telling you about your understanding of the problem. That's a different kind of feedback.
The calitoy core systems thinking about this is useful: the best engineering cultures separate the code from the coder. The code is wrong, not the person. The architecture is wrong, not the architect's judgment. This is easier to say than to practice, but it's the right frame.
The other reason it's hard is timing. By the time a PR is up for review, the author has usually spent significant time on it. Telling them the architecture is wrong at that point feels like you should have said something earlier. And you probably should have. The architectural conversation should happen before the code is written, not after. But it often doesn't, because the problem isn't visible until someone tries to implement it.
How to Give It
The best architectural code reviews I've received started with a question, not a statement. "I'm trying to understand how this handles X — can you walk me through it?" That question often surfaces the architectural issue without the reviewer having to name it directly. The author explains the approach and either realizes the problem themselves or gives the reviewer enough context to name it precisely.
The personal cost of technical decisions is real — the sunk cost of the work that might need to be redone is a genuine loss, and acknowledging that matters. "I know this is a significant change to what you've built" is not weakness. It's accuracy. The author knows the cost. Pretending it's small doesn't help.
The tarosyn dev log has a good example of this — the card draw architecture went through two complete rewrites before it was right. Each rewrite was painful. Each rewrite produced something better. The architectural code review that triggered the first rewrite was the most valuable review in the project's history, even though it was the hardest to give and receive.
The code review nobody wants to give is usually the one that matters most. Give it early. Give it kindly. Give it precisely. And then help fix it.
More on dev culture at Opened Terminal.