In this article
Last updated September 18, 2026
3 min read
Self-review has always had limits.
The person who wrote a change knows what they meant, remembers the constraints they considered, and can read missing
intent back into the code.
An AI agent has a related problem. The same context that helped it implement the feature can make its review repeat the
same assumptions.
The answer is not to declare the second agent objective or infallible.
The answer is to create useful independence.
Separate the jobs
The maker’s job is to implement the approved plan inside scope.
The checker’s job is to challenge the result against an independent target.
Give the maker:
- approved plan;
- specification;
- task context;
- allowed tools;
- scope fence;
- required handoff artifacts.
Give the checker:
- approved specification version;
- acceptance criteria and invariants;
- diff and changed files;
- deterministic check outputs;
- risk lane;
- recorded human decisions;
- explicit questions to answer.
The maker’s summary can help navigation. It should not replace the underlying evidence.
Change the incentives
A generic instruction to “review carefully” is not enough.
Ask the checker to find:
- promised behaviour without evidence;
- changed behaviour without a promise;
- scope expansion;
- hidden product decisions;
- reused components with mismatched responsibility;
- dependency and supply-chain concerns;
- missing or stale documentation;
- deterministic claims without recorded commands;
- model judgements presented as facts;
- conditions that make the verdict inconclusive.
The output should contain findings, evidence, severity, uncertainty, and a recommended next action.
Preserve disagreement
Multiple agents are often used to create consensus. That can be the wrong target.
If the maker and checker disagree, do not average the answers or ask a third model to vote without new evidence.
Record:
- exact disputed claim;
- evidence each side used;
- source conflict or missing fact;
- what deterministic check could help;
- which human owns the remaining judgement.
Disagreement is useful when the workflow converts it into a clear next step.
Keep specialist review scoped
Not every change needs every specialist.
Use the risk lane to select architecture, security, data, performance, design, product, or documentation review.
Give each specialist a narrow job and require a structured artifact. A security reviewer should not silently rewrite
the feature. An architecture reviewer should not decide product behaviour. An implementer should not close their own
finding.
Role limits are the control.
Do not let another model become the final authority
A separate checker reduces shared context and incentive problems. It does not remove model limitations.
Final readiness can include deterministic results and model-judged findings, but production remains an accountable
human verdict for consequential work.
The reviewer needs to know which parts are:
- proven by commands;
- measured;
- judged by a model;
- decided by a human;
- unresolved.
How paqad-ai applies maker-checker separation
paqad-ai’s current design describes specialist roles with different jobs across requirements, implementation,
verification, review, security, and documentation. The workflow and structured artifacts control their handoffs.
That is more than adding another agent to the same conversation.
The point is to stop one reasoning path from writing the question, choosing the answer, producing the evidence, and
awarding itself a passing grade.
Use agents to challenge agents.
Keep the final consequence owned.
Install paqad-ai: https://github.com/Eliyce/paqad-ai/
Source notes
- Addy Osmani, Loop Engineering, practitioner analysis of agent loops with
separate checking. - Addy Osmani, Own the Outer Loop.
- Product mechanism: first-party details from the current
Eliyce/paqad-ai repository.