Machine-Native → Verification
Last updated: September 28, 2026
When no human reads the code, how do you know it is correct?
The industry's answer is to put a smarter model in front of the code and ask it to judge. LLM-powered code review. Machine reasoning about machine output. The problem is that machine reasoning is probabilistic. It catches what it catches. It misses what it misses. Run the same review twice and you may get different findings. That is not a quality system. It is a suggestion engine.
My answer came from watching where quality actually leaked: separate what can be verified mechanically from what requires judgment, and never use judgment where verification will do.
There are two categories of code quality check. The first is mechanical: is this import allowed here? Is there a secret in this file? Did the version move when the code did? These questions have deterministic answers. They do not need a model. They do not need judgment. They need a parser and a rule.
The second category is judgment: is this the right abstraction? Does this implementation handle edge cases the spec did not anticipate? Is this error message helpful? These require reasoning, context, and experience. A model is the right tool here.
The mistake is using one tool for both. Ask a model a deterministic question and it will get it right most of the time. Most of the time is not a quality system.
So the first category became a mechanical verification tool. 51 checks. Every check is deterministic. Every check is a hard failure. Within those checks there is no "warning" severity and no "consider fixing this." Breakage blocks the build. Drift that can only be measured, not ruled right or wrong, is tracked as a metric instead of a finding. The code passes or it does not ship.
The line between the two categories is not a philosophy. It is measurable. On the last feature we shipped, two defects made it past the entire pipeline to me: a timezone assumption in a test, and a data backfill that was written, reviewed, and tested, then left out of the production runbook and never run. The first has no deterministic answer. It lives on the judgment side of the line, and that is where the work continues. The second is a gap a mechanical check can close. That is how the suite grows: one lesson at a time.
Most code quality tools report findings for a human to triage. Here is a list of issues. Decide which ones matter. Fix the ones you care about. Ignore the rest.
Here there is no triage step because there is nothing to triage. If a check fires, the code is wrong, and it does not advance until the finding is resolved. Exemptions exist, but they are not developer decisions. An exemption is a Product Architect ruling, recorded in the system with the reasoning behind it, and it is as governed as the check it suppresses.
This is the burden flip applied to verification. The producing engineer does not declare the code ready and hope nothing catches a problem. The system assumes the code has problems, and the engineer must prove it does not.
Every file in the codebase describes itself: what it does, what it depends on, what it promises to the files that call it. In most codebases that description is a comment, and comments drift. Here the verification tool reads the structural claims a file makes about itself and checks them against the code. If the file claims one thing and the code does another, the build fails.
What a parser cannot verify is behavior: whether the code actually does what the file says it does. That is a judgment question, and it goes to Craig, my AI review engineer, whose attention is spent only where judgment is deserved.
Documentation that lies is a build failure.
The reason is structural, not tidiness. My AI employees navigate the codebase by reading what files say about themselves. If a description is wrong, an employee makes a decision based on false information, and the consequences compound silently until something breaks in production. Making the documentation load-bearing is not discipline. It is structural integrity.
One shared tool. Every product. Every deploy. Every check a hard failure. Fix the code, not the check.