Who it's for
Engineers who use AI to review changes before a person does.
You'll be able to
Split AI review into narrow checkers, and know what their verdict is worth.
"Is this change good?" is too big a question for one reviewer. The factory asks four narrow questions instead, one checker each.
Four questions, four checkers
Each checker reads the same change and answers one question.
| Checker | What it looks for |
|---|---|
| Spec | Each acceptance point in the spec: met, missing, or extra work nobody asked for |
| Test | New code has tests, and no test was deleted, weakened or switched off |
| Architecture | The team's own written rules, each one answerable with true or false |
| Security | Secrets in the code, injection, login and permission mistakes, risky new packages |
Each checker is told to stay in its lane. The spec checker does not judge style, tests or security. The test checker does not judge whether the code is correct. The architecture checker checks only the rules on the list and adds none of its own.
Each answer in the same shape
Every checker answers the same way: a verdict of pass, warn or fail, and a list of findings. Each finding names a file, a line, the problem and the evidence. Because the shape is fixed, a script can read the answers and write one report.
The security checker has one extra rule. Every finding must quote the code it is about. If the quote is empty, or is not in the change, the script drops the finding. A claim the checker can't point to does not reach the report.
They read, they don't decide
The checkers only read. They never edit a file. The main session or a person makes the fixes.
This matters because the change under review is written by someone else, maybe an agent. It can hold text that tries to steer a reviewer, such as "ignore the rules above". Each checker treats the change as material to check, never as instructions, and reports such a sentence as a finding. Since checkers can't change anything and block nothing, the worst result is a wrong report.
A checker's verdict is advice. The gate blocks, and a person decides.
One change, a pull request, goes to four checkers. Each reads the same change on its own and answers one question.
- Spec checker: each acceptance point in the spec.
- Test checker: new tests; none deleted or weakened.
- Architecture checker: the team's own written rules.
- Security checker: secrets, injection, permissions.
Their answers are advice, and the advice goes to a person. The same change also goes to the gate: tests and scans, not an AI. The gate blocks or passes on its own. The person reads the advice, decides and merges.
A task closes when the gate passes and a person has read the checker report. A fail needs a fix, or an override that a person writes down in the pull request. No checker runs in CI, and none is a required check.
Try it
In your own repository, with any AI tool:
- Write four short review instructions, one per question above. Tell each to stay out of the others' areas.
- Ask each for a verdict and findings that quote the exact lines.
- Run all four on your last merged pull request, then run one general "review this" on the same change.
- Compare what each found, and which findings held up when you checked them.