The failure your code review cannot catch

Most discussion of AI-assisted development focuses on output quality: is the suggestion correct, is the code idiomatic, does it compile. Those failures are visible, and visible failures get caught in review.

The failures worth engineering against are the invisible ones - where the tooling reports something confidently false and every downstream decision inherits the error. We hit one of those, and the process we built in response is the part worth sharing.

**The failure mode.** A mounted filesystem served files shorter than they actually were, truncated mid-token. Every tool reading through that mount saw the short version with no indication anything was wrong. Version control then compared the truncated content against the real repository and reported modifications that did not exist. Staging those would have committed the truncation - deleting working code nobody had touched, in a diff that looked completely reasonable to a reviewer.

That is the shape of the dangerous class: not a wrong answer, but a wrong *measurement* that produces a plausible wrong answer. No amount of careful review catches it, because review operates on the same corrupted input.

**Make the rule executable, not written.** Our first instinct was to document the hazard. That instinct is wrong. A warning in a document is a warning someone skips at 1am, and the person most likely to skip it is the one moving fastest. So the rule became a program: a preflight check that runs before any session touches version control, verifies the environment, and **fails closed**. It takes about two seconds, has no dependencies, and carries its own test suite - because an unverified safety check is decoration.

The design principle: if a rule matters, it should be impossible to proceed without satisfying it. Anything less is a suggestion.

**Treat every handoff as a hypothesis.** The second half is cultural. When work spans many sessions - human or AI - each one inherits a summary of what came before, and those summaries are where errors calcify. On a single day, three inherited claims collapsed the moment anyone measured them: a file count that was wrong, a set of tests reported as deleted that were entirely present, and a batch of errors described as outstanding that had already been fixed.

The middle case is the instructive one. It began as a measurement error, got written into prose, and from there acquired the authority of a fact - propagating through two handoffs unchallenged. Prose is remarkably good at laundering uncertainty into confidence. A number in a sentence reads as established; the same number in a tool output reads as a reading you might want to re-take.

So the standing instruction is to re-derive state from the repository at the start of every session rather than trusting the summary, however authoritative it reads. State is cheap to measure and expensive to assume.

**What another engineer can take from this.** Three things generalise. First, distinguish failures your review process can catch from ones it structurally cannot, and spend your engineering effort on the second category. Second, encode critical rules as programs that fail closed, because documentation degrades into folklore. Third, in any workflow with handoffs, build in a re-measurement step - the cost of verifying inherited state is far lower than the cost of one confident, wrong inheritance reaching production.