Claude Code and other agents will lie to you about their own

Stop trusting a majority vote when using LLM agents for code review. I've been running a setup where any change to a safety gate must be reviewed by a panel of four rival models from different labs. My rule is simple: one single dissent kills the change. It's not a democracy; if one model flags a risk, the code doesn't ship, regardless of how many other models gave it a thumbs up.

I recently had a situation where this "paranoid" approach saved me from shipping a security hole three times in a row. I was trying to fix a safety gate that prevents my agent from freezing a test harness.

The four-round failure loop

In this specific run, one of my four reviewers was offline, so I was running a three-of-four panel. Even with the reduced count, the results were eye-opening.

• Round 1: I submitted a fix that allowed the agent to skip a check by providing a written justification. GPT and Gemini approved it immediately. DeepSeek flagged it, noting that a self-attested waiver doesn't actually enforce anything.
• Round 2: I updated the waiver to require that the check actually be executed. Again, GPT and Gemini signed off. DeepSeek caught the flaw: the "did it run" test was just matching any command that mentioned the tool, not verifying that the tool actually passed.
• Round 3: I removed the waiver entirely. Once again, the majority approved. DeepSeek pointed out that the pass-receipt was being matched against the agent's own reply text, meaning the agent could just type a "magic word" to bypass the gate.
• Round 4: I finally changed the logic so the receipt only comes from actual tool output, never the agent's text. Only then did all three models agree.

If I had relied on a majority vote, I would have confidently deployed a broken safety gate in the first round.

The problem with correlated blind spots

The reason majority voting fails in an AI workflow is that models trained on overlapping datasets often share the same blind spots. When three models agree, it feels like a consensus, but it's often just a shared hallucination or a common oversight. The "outlier" model is usually the one providing the actual signal.

I noticed this further when Gemini caught a bug that the other two missed entirely. I had a botched ternary operator for a temp filename: Date.now ? 'x' : 'x'. Because it always returned the same string, the process would race itself and silently skip checks. The other models walked right past it.

Practical tutorial for agent verification

If you are building a deployment pipeline or a custom LLM agent, stop letting the system grade its own output. Here is a basic framework for a more robust verification process:

1. Diversify your reviewers: Use models from different families (e.g., Claude, GPT, DeepSeek) to avoid correlated errors.
2. Implement a "Veto" system: In verification tasks, one credible dissent should be treated as a failure.
3. Strict Output Validation: Ensure that "success" signals come from external tool outputs or system logs, not from the agent's own chat completion.

For example, instead of checking if the agent says "I have run the test," your verification script should check the actual exit code of the process:

# Bad: checking agent text
# Good: checking actual tool output
if [ $? -eq 0 ]; then
  echo "Verification passed"
else
  echo "Verification failed"
  exit 1
fi

This approach catches the "confident mistakes" that usually slip through a standard prompt engineering flow. It's not about stopping sabotage; it's about acknowledging that LLMs are prone to overclaiming their own accuracy.