All articles
Engineering

Code Review Is Not CI

Tests evaluate declared expectations; review looks for the expectation nobody thought to declare.

MergeWatch Team2 min read

CI and code review both sit between a commit and a merge, but they solve different problems.

CI evaluates a specification

A test encodes an expectation. Given known inputs, the program should produce known outputs. Static analysis applies another declared specification: this value must not be nullable; this call must be awaited.

Review starts where those declarations end. It asks whether the specification itself is incomplete.

Continuous integrationCode review
Repeats declared checksSearches for missing assumptions
Produces pass or failProduces evidence and judgment
Optimized for determinismComfortable with ambiguity
Gates automaticallySupports a human decision

A concrete boundary

Imagine a pull request that changes a cache from per-user to per-project. Every test passes because the fixtures contain one user per project. CI is correct: the software satisfies its encoded expectations. Review can still notice that the authorization boundary and the cache boundary no longer match.

- const key = `${projectId}:${userId}`;
+ const key = projectId;

The right outcome is not to replace CI with an AI reviewer. It is to let each system make the claim it can support—and no larger one. That is also why we retired “safe to merge”.

Keep reading

Engineering·

Why We Stopped Saying "Safe to Merge"

Code review can assess a change, but that is not the same thing as proving a build is safe to merge.

MergeWatch Team · 2 min read