Design Review
vs.
Code Review

Code review and design review are not the same activity. They answer different questions, examine different evidence, and produce different kinds of accountability. Most engineering organizations have invested heavily in code review infrastructure and almost nothing in design review infrastructure. This is the governance gap.

A PR can pass every SonarQube Quality Gate, every ArchUnit test, every code review checklist — and still be a design disaster. The code is syntactically correct, the tests pass, the reviewer approved it. The decision it encodes violates an architectural principle that was never expressed as a code rule.

Code review is bounded by what can be verified from the diff. The reviewer can see that a new class was added. They can see that a new package dependency was introduced. What they cannot see — unless they have deep architectural context and specifically look for it — is that the design decision encoded in that class violates the principle that established the service boundary four ADRs ago.

This is not a failure of code review. Code review is doing exactly what it is designed to do. The failure is expecting code review to do something it was not designed for.

A design review evaluates a Change Intention — a declaration of what is changing in the Architecture Ledger, why, and what the intended scope is. It is initiated before the code is written, not after.

The design reviewer asks: does this intended change conform to the Steering principles that govern the affected domain? Does it cross a boundary that was intentionally established? Does it introduce a coupling that ADR-042 explicitly warned against? Is there a compliance constraint that applies to this domain that the change needs to account for?

The output of a design review is not a merge approval. It is an architectural approval record — timestamped, attributed, and linked to the specific CHI and Steering artifacts that were in force at the time. This record is durable in a way that a GitHub PR approval is not.

In rkito, a Design Review is triggered by a Change Intention (CHI). The CHI is created before or alongside the development work — either manually via the CLI (rkito intent "add webhook for payment events") or automatically drafted by the CDA when it detects unplanned drift on a PR.

The Design Review evaluates the CHI against the Architecture Ledger and Steering artifacts. The architect approves or rejects with a rationale that becomes part of the durable record.

Once a CHI is approved, the CDA uses it as the authorized scope for that branch. If the code implementation stays within the approved scope, the PR processes normally. If it exceeds the scope, the CDA flags the deviation for architect review.

Code review and design review coexist. They are not competing processes — they answer different questions and neither replaces the other.