The Second Opinion Brief
The exact prompt that makes one AI attack another one's work instead of agreeing with it.
Want help applying this to your business? Get in touch and tell me what you are working on.
Why asking the same AI again does nothing
I had an AI rebuild a large piece of financial work for a client. The same AI also wrote the eight automated checks that tested its own work. All eight passed. I was told repeatedly that the numbers were sound, and the passing checks were the evidence.
Before any of it went out, I had a different company's AI attack the work. It found, in minutes, that one of those eight checks could not fail. The code set its own result to pass, worked out a figure from three numbers somebody had typed in by hand, printed it, compared it to nothing at all, and returned success. Every figure in that section could have been wrong and it would still have said PASS.
The model that wrote that check had read it many times and saw nothing wrong, because it knew what the code was meant to do. The reviewer had no such knowledge, read only what was there, and caught it straight away.
This is measured, not just my experience. The Self-Correction Bench study (arXiv 2507.02778) tested 14 models and found a 64.5% self-correction blind spot: models reliably fix errors handed to them as someone else's work, and fail on the identical error when it is their own. Separately, a cross-family code review reported correctness problems in 3 of 19 fixes that same-family review had already approved.
The brief, ready to copy
Fill in the four bracketed lines. Paste the whole thing into an AI from a different company than the one that did the work.
You are reviewing work you did not produce. Assume the author is confidently wrong somewhere.
THE WORK: [paste it, or attach the files]
THE CLAIM I AM RELYING ON: [the one sentence you would have to defend if challenged]
WHO WROTE THE TESTS: the same author who wrote the work
WHAT AN ERROR COSTS HERE: [money, a filing, a client relationship, a deadline]
Your job:
1. Attack the claim above. Do not set out to confirm it.
2. Treat every passing test as unverified until you have read the test itself.
3. Rank findings by what each one would cost if true, largest first.
4. For each finding tell me: what is wrong, exactly where, how you would prove it, and how confident you are.
5. Say plainly which parts you could not check, and why.
Do not summarise the work back to me. Do not tell me what is good.
That is the whole tool. Everything below explains why each line is in there, so you can adapt it without breaking it.
Why each line is in there
| The line | What it stops happening |
|---|---|
| Assume the author is confidently wrong somewhere | A neutral review of work that looks good comes back saying it looks good. The reviewer needs a side. |
| The claim I am relying on | Without this the reviewer picks its own target and audits spelling. Name the sentence you would have to defend. |
| The same author wrote the tests | This single line is what aimed my reviewer at the check that could not fail. Left out, passing tests read as proof. |
| What an error costs here | Turns a flat list of nitpicks into a ranked one. You want the expensive problem first, not the tidiest. |
| How you would prove it, and how confident | Gives you a way to check each finding yourself instead of taking the reviewer on faith. |
| Which parts you could not check | The most ignored line. It tells you where you still have no coverage, which is the thing a clean review otherwise hides. |
Pick a genuinely different reviewer
Switching between a big and a small model from the same company is not a second opinion. On that job I moved between three models from one maker and got three different working styles with the same blind spots. The findings that mattered came from a different maker entirely.
Models trained on overlapping material share overlapping assumptions, so their mistakes line up. Pick across companies. If you use Claude for the work, review with ChatGPT or Gemini, and the other way round.
Make it a rule in your setup rather than a decision you take each time. Mine routes any request to check work it just produced over to a different model automatically. Removing the decision removes the chance to skip it.
What to do with what comes back
Across three passes the reviewer produced 17 findings. Roughly half of the final pass needed no action, being true and already known. That does not make the review a waste, and it makes one rule non-negotiable: check every finding against the real thing before changing anything.
A reviewer gives you suspicions, not verdicts. Acting on its output without checking repeats the exact mistake you brought it in to catch, with an extra step added.
The biggest correction on that job did not come from a bug. The reviewer disagreed with how I had described a problem. I had been told a leftover gap was a limit of the tool rather than evidence of an error, and it said treat that as real until proven otherwise. It was right, and chasing it found the largest error of the job.
A fix is new work. On the final pass the reviewer found two documents contradicting each other. My fix was wrong in a different way, and only got caught because the reviewer looked again.
Five questions for any check you are trusting
Run these on anything you rely on to tell you your work is fine, whether a person or an AI built it.
| Ask | What a bad answer sounds like |
|---|---|
| Has this check ever failed? | Never. Then it has been used, not tested. |
| What exactly does it compare, and to what? | Vague answers here are where the empty checks hide. |
| If I broke the data on purpose, would it go red? | If you cannot say yes, go and try it. It takes about thirty seconds. |
| Who wrote it? | The same author who wrote the work. Nothing independent has happened yet. |
| Does its name promise more than it measures? | A check called validate everything that reads three fields. |
A check you have never seen fail is a hope, not a control. Break your data on purpose once and watch it go red before you trust the green.
Four ways this goes wrong
| The mistake | The fix |
|---|---|
| Asking for a review instead of an attack | Say attack the claim. Neutral wording gets you a compliment. |
| Using a second model from the same company | Cross companies. Same family, same blind spots. |
| Acting on findings without checking them | Verify each one against the real data first. Around half may need nothing. |
| Not reviewing the fix | Run the reviewer again on the corrected version. A fix is new work. |
The whole thing in five lines
- Name the one claim you would have to defend.
- Hand the work to an AI from a different company, with the brief above.
- Tell it the author wrote the tests too.
- Check every finding yourself before changing anything.
- Review the fix as carefully as you reviewed the original.
About Andrew Voskov
Andrew Voskov is the founder of Cherry Pi AI. This brief came out of a real job where a second model found what eight passing tests had missed, and he now runs it on anything where being wrong would be expensive.
Want help applying this to your business? Get in touch and tell me what you are working on.
Found this useful? Follow along on LinkedIn — I post free systems and breakdowns every week.
Follow Andrew on LinkedIn