QC subagents default to self-validating behaviour instead of adversarial review
Problem
When using Claude Code's Agent tool for quality control workflows, QC agents (especially re-QC agents verifying fixes) default to self-validating behaviour rather than truly adversarial review. This wastes significant tokens on confirmation loops that must be redone with stronger adversarial prompts.
What happens
- A QC agent finds issues in a report
- A fix agent applies fixes
- A re-QC agent is launched to verify fixes
- The re-QC agent frames its mission as "verify these N fixes were applied" rather than performing a fresh adversarial review
- The re-QC agent confirms fixes and declares PASS
- Later, an independent adversarial QC finds issues the self-validating re-QC missed
- All the intermediate re-QC and fix rounds were wasted tokens
Expected behaviour
Re-QC agents should perform the same level of adversarial scrutiny as initial QC agents. Fix verification should be a secondary checklist, not the primary mission. The agent should treat the report as if seeing it for the first time.
Impact
Roughly 300K+ agent tokens were wasted on self-validating re-QC cycles across two reports that now need fresh adversarial QC from scratch. This is a significant portion of weekly token limits.
Additional context
The user explicitly requested adversarial QC from the start. The task instructions clearly stated the QC philosophy: "loop until LITERALLY 0 issues at ALL severities." Despite this, the orchestrator wrote re-QC prompts framed as "verify these N fixes were applied" rather than truly adversarial prompts. The user had to catch this mid-session and call it out.
The self-validating pattern was not a result of ambiguous instructions - it was the model defaulting to confirmation behaviour despite explicit instructions to the contrary.
Suggestion
Consider providing guidance or system-level framing for QC-pattern workflows that ensures re-QC agents maintain adversarial posture rather than defaulting to confirmation bias. The tendency to confirm rather than challenge appears to be a default model behaviour that requires explicit, strong prompting to override.
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗