AI is most dangerous when it is asked to review its own work as if the goal were approval. The same model family that produced a plan can produce a beautifully reasoned defense of that plan. That is not review. It is confirmation with syntax highlighting.
The review prompt has to change the job. The reviewer is not there to admire the implementation. The reviewer is there to find the production failure: data corruption, tenant leakage, broken workflows, unsafe migrations, operational blind spots, and tests that prove the wrong thing.
The loop
The strongest pattern I use is staged. First, create a plan without implementation. Second, run an adversarial review of the plan. Third, revise the plan until critical blockers are gone. Fourth, implement. Fifth, review the branch as production-bound code. Sixth, apply only high-confidence fixes from that review.
That last step matters. A review prompt that rewards finding issues can overreach. Not every possible improvement belongs in the branch. The acceptance rule should be strict: fix blockers, fix concrete correctness issues, add regression tests for accepted findings, and file lower-confidence polish as tracked debt if it matters.
What adversarial means
Adversarial does not mean hostile style. It means the reviewer is allowed to disagree with the author and required to ground the disagreement in evidence. The output should name severity, file and line when available, and a concrete failure scenario. A generic worry is not enough. A concrete path from input to failure is.
- P0 or P1: fix before merge because production correctness, security, data, or operations can break.
- P2: useful follow-up, but not a merge blocker without operator agreement.
- No finding: explicitly say the reviewed surface appears sound and name any untested residual risk.
The second-model advantage
A second model is useful when it is given full context and an independent job. Do not ask it for vibes. Ask it to read the plan or diff, assume an overconfident engineer wrote it, and find the hidden failures. The independence is the value. The first agent may still decide, but it decides after another system has tried to falsify the work.
This is how AI remains useful in high-stakes code: not by pretending it is always right, but by making disagreement cheap, structured, and evidence-bound.
Series linkage
Part 5 of 10 in Prompt Library to Operating System. Evidence proves what ran; adversarial review asks whether the right thing was built.
About AmanERP
AmanERP is designed for real business workflows, so review focuses on failures that would hurt real operators, not on cosmetic disagreement.