An architecture review reads the system — its boundaries, its data flow, its failure modes, and the decisions that produced them. A code review reads the lines inside one of those boundaries. The two are routinely confused, and the confusion is rarely accidental. Code reviews are easier to schedule, easier to scope, and easier to invoice for, and they leave behind a satisfying artefact — line comments, a merge, a green check. Architecture reviews leave behind a memo and a smaller number of decisions that have been quietly changed. Most senior teams, when they say they want a review, want the second. Most engagements, when written down on paper, deliver the first. The substitution is the failure mode this note is about.
What each one is actually reading
A code review reads a diff. It is bounded by the change — the files touched, the tests added, the function renamed. The reviewer can see whether the change does what the description claims it does, whether the tests cover the obvious branches, whether the new code matches the conventions of the surrounding code, and whether anything has been imported that ought not to have been. It is a useful activity, and the studio is not against it. It is, in a healthy team, mostly automated and mostly lightweight, and the human attention left over is spent on the handful of changes where the reviewer's judgment actually matters.
An architecture review reads the surface where the change lives. It asks a different category of question. Where is the boundary between this service and the next one. What does this service own and what does it borrow. What happens when the upstream queue is empty for an hour. What happens when it is full for a minute. Which of these decisions were made deliberately and which were inherited from the moment the first commit was written and have never been re-opened. The reviewer is not, in this mode, looking at the code at all in the line-by-line sense. The reviewer is looking at the shape the code is sitting inside, and at whether that shape is the one the team would draw today if they were starting fresh.
The two readings are not on a spectrum. They are different jobs. A senior architect can read a diff, and often does. A skilled code reviewer cannot, by reading more diffs more carefully, eventually produce an architecture review. The data they would need is not in the diff. It is in the conversations that happened twenty months ago, the decisions nobody wrote down, the SLA the platform team agreed to verbally, the assumption about message ordering that was never tested and never written and never violated until last quarter.
Why teams ask for one and contract for the other
The substitution happens for a reason that is almost always commercial rather than technical. A code review is procurable. There is a market for it, the deliverable is recognisable, the engagement closes inside a sprint, and the invoice is defensible to a CFO who has never had to sign one. An architecture review is none of those things. The deliverable is a memo. The engagement is shorter than a code-review engagement and produces less material. The reader does not, in most cases, write any code. The engagement is awkward to compare to a price per file or a price per pull request, because the artefact is not a per-file artefact. It is a single document that names two or three decisions the team should consider revisiting, and one or two they should not, and the reasoning behind both.
A second pressure pushes in the same direction. Teams have learned, often through painful experience, that asking for an architecture review can sound like asking for the architects to be wrong. It is, in fact, exactly the opposite — the team that asks for the review is the team that wants to be sure of its decisions, not the team that wants them undone. But the framing is awkward in a room where the people who made the decisions are present, and a code-review engagement carries none of that awkwardness. A code review never tells the principal engineer that a foundational call from two years ago is now load-bearing in a way it should not be. An architecture review sometimes does, and the team that needs to hear that often quietly arranges to hear something else instead.
A team that will only commission the review whose answer it has already decided is not commissioning a review.
How the studio runs an architecture review
The engagement is short and specific. It is one to three weeks, fixed fee, scoped against one to three named questions agreed in writing before the work begins. The questions are usually about a boundary — between two services, between two teams, between the in-house build and a vendor — or about a category of failure that has happened more than once and the team would prefer not see again. The studio reads the code, but does not produce line comments. The studio interviews engineers, but does not interview them as a manager would. The studio reads the decision record, the incident postmortems, the architecture diagrams as they exist, and the diagrams as they are described in conversation, which are often not the same diagrams.
The deliverable is a memo of three to eight pages. It contains, in order, the question that was asked, the decisions the studio recommends the team revisit, the decisions the studio specifically recommends the team leave alone, and the conditions under which the studio's reading would change. The memo is written in English rather than in tickets. The team owns it. The engagement closes. The studio is not retained to implement the changes the memo recommends, and the cleanest reads come from engagements where the studio has no commercial interest in the next phase.
A team can read a memo of this shape against its own backlog the same week it lands. The decisions named in it are the decisions the team can act on. The decisions left alone are decisions the team can stop second-guessing. Both are the deliverable. The line edits that a code review would have produced are not in the memo, deliberately. A code review is a different engagement. The studio is happy to refer the team to one, and is even happier when the team's own engineers do that work themselves, which is usually the right shape.
The studio's stance, plainly: we do not do code reviews. We do architecture reviews, and we charge for them. The two activities look adjacent on a calendar and are not adjacent on the work. A senior team that is asking for the second and being delivered the first is paying for a service it is not receiving, and the cost of the substitution is not visible until a quarterly decision turns out to have been the wrong one — at which point the line edits, however careful, are not the artefact anyone needed.