A task added one mapped database column and its migration. The implementing agent ran the tests for the files it had changed, saw green, and reported completion with the line "no new test failures introduced". The migration had never been applied to the test database. Forty-six tests broke — every one of them in files the task had not touched, which is exactly why the scoped run could not have seen them. The report was accurate about what it measured and wrong about the codebase.

That incident sits at the centre of this article because it broke the one rule that made large diffs reviewable at all. The code review method on this project sorts every changed file into three tiers. Business logic — access control, query filtering, state transitions, anything that decides who can do what — is read line by line, each row of the review carrying the reason it needs eyes and a command that opens the editor at the spot. Glue — controllers, wiring, route definitions — is read for flow at about thirty seconds a file: right service, right route, right template. Boilerplate — entities, migrations, templates, config — is not read at all. Its rule was "trust the tests", and the incident shows the small print that rule always carried: it is sound only when "the tests" means the entire suite. Under a scoped run the premise fails without a sound, and the rule then actively suppresses the one read that would have caught the problem.

The rule now reads "trust a full-suite run". A diff that touches a global-effect artifact — a schema mapping, dependency wiring, shared fixtures, a widely referenced constant — is not done until the full suite has run and its summary is in the report, and when only a scoped run is in evidence, the tier-3 skip is withdrawn and those files get read after all. The same gate moved upstream into the implementation skill, so the task is blocked before it can report done, rather than flagged after.

Size Predicts How Much To Read. It Does Not Predict Whether Reading Is Enough.

Two slices from the same project, reviewed weeks apart with the same method, made the second problem visible. One review produced 35 business-logic rows and 20 flags — one release-blocker, two high-severity. The other produced 22 rows and 9 flags. Same reviewer tooling, same tier rules, same stack. The first slice was a payment surface; the second, an admin area of comparable code volume. Nothing in the line counts predicted a 20-to-9 difference in what the review surfaced, because the property driving it is not size. It is whether the slice touches things whose failure the test suite structurally cannot see.

Working back through the flags produced a list of those things. I call them review deciders, and the admission test for the list is strict: a class earns its place only when a correct-looking green suite says nothing about its failure mode.

  • Money movement. The provider's live behaviour is outside the repo; in the blocker above, a provider-side format change meant the invoice being finalised carried no charge at all, and no stub could have shown it. 121 tests were green over a checkout that could not have charged anyone.
  • Transactional email. Every test environment routes mail to a transport that sends nothing, so "sent correctly" and "unsendable" produce identical green. A dead password-reset is invisible until a user needs one.
  • Bulk and marketing email. One defect is not one incident, it is one incident per recipient, and sender-reputation damage outlives the fix.
  • Identity and single sign-on. The provider configuration lives outside the repo, and the failure mode is everyone locked out, including the person fixing it.
  • Integrations where the far side is someone else's system of record. The test double agrees with your assumptions by construction; in the invoice case above, the double kept carrying the charge the live provider’s schema had dropped.
  • Infrastructure. Blast radius is every slice at once, and the declared state and the actual state drift apart between runs.
  • Personal data leaving the system. An export or sync that over-shares fails as a legal event, not as an assertion.
  • The public web surface. Broken redirects and accidental indexing are live in search results before anyone in the building notices; redirect maps get one chance.
  • Removals. Tests do not cover what no longer exists. A deleted automation task can silently revert its state on the next scheduled run, and nothing red appears anywhere.

Three properties modify any class rather than standing alone: unattended execution (cron, queue, webhook — no human in the loop when it fails), metered cost per call, and the one-shot run — the rerunnable import script is ordinary code, while the single cutover against live data is not. In the review, a file that instantiates a decider is tier 1 no matter what it looks like, and each class present adds a named mandatory check to the review record: prove the email sends through a real transport and name the recipients; list every consumer of the thing that was removed. Deletions get the inverse of the boilerplate rule — read every line, precisely because no test can fail on absent code.

Pricing The Review Before The Code Exists

The slice that produced the 35-row review had been consolidated from five would-be slices, on the reasoning that agent-accelerated build priced each piece at three to seven hours. The build estimates were roughly right. What compounded was everything downstream of build: one page, one data model, one payment surface, all of it needing verification and review attention at once. The sizing metrics from two articles back — line counts, churn, fix-rate — are lagging indicators, visible only after the branch is already large. Commit counts turned out not even to be countable: agent sessions alternate between committing every prompt and committing nothing, so the same amount of work shows up as 12 commits or 60 depending on session settings.

Two leading inputs exist before any code does, sitting in the planning docs. The route count: across six recent slices, the number of planned routes ranked the slices in the same order as the business-logic rows their reviews eventually produced, and the payment slice was the outlier while it was still paperwork — 42 planned routes against 19 for the next largest. And the decider count, straight off the list above, which is answerable at scoping time by reading the scope document. The working rule now: more than about 30 routes, or two or more decider classes, and the slice splits — along the verifiability boundary, with the stub-testable core in one slice and the real-provider integration in another, rather than along the effort boundary that made five slices look like one afternoon each.

The reviews themselves became measurable in the same pass. Each recorded review now carries a machine-readable count block — rows per tier, flags per severity, decider classes present, and the version of the review skill that produced it. The retrospective behind this article needed three attempts over hand-written review markdown to extract the same numbers twice; the next one reads a block.

Where The Series Lands

This is the eleventh article in a sequence that opened with a measured 8x on bounded build work. The hidden requirements that turned 66 hours into 226 were promises no verification step owned. The velocity trap and the sizing metrics were slices cut by build effort in a system where build effort had stopped being the constraint. The review that could not finish and the promise file were the verification instruments being rebuilt to the same standard as the code they check. Build got the multiplier; verification got a to-read list.

So the delivery system's current shape is a set of mechanisms for keeping one budget: tier-1 rows plus decider checks — the lines a person reads with full attention before something ships. The promise file keeps unbuilt work off that list, the full-suite gate keeps silent breakage off it, the split rule keeps any one slice's share of it reviewable in a sitting, and the count blocks record whether it is shrinking. On the payment slice that number was 35 rows and 20 flags; on a well-cut slice it runs under half of that.