The Doubt Loop: Why I Never Trust a Single AI Agent

← Back to Engineering

I have been building production software with AI coding agents for the past three months. In that time, I have learned something important: AI agents are often confidently wrong. Not always, but often enough to be dangerous. I built a workflow that exploits this weakness.

The pattern is simple. When an AI agent tells me a feature is complete, I do not deploy it. Instead, I copy its confident claims and give them to a second, independent AI agent running in the same codebase. I add eight words: "Audit and validate these claims. Find the gaps."

In my recent runs, the auditor has found gaps far more often than not.

Not occasionally. Often. When I run this pattern, the auditor usually surfaces something the builder missed: missing error handling, race conditions, edge cases, type mismatches, or security concerns. The exact mix varies, but the miss rate is high enough that I assume there is usually something to find.

The Problem: Confident Completion

If you have used Claude Code, Cursor, Windsurf, Codex, or any AI coding assistant, you know the feeling. The agent finishes its work and announces completion with confidence:

"I've implemented the feature and it's ready for testing. The code handles all edge cases and follows best practices."

This is often not true. But the agent believes it. And if you are not careful, you will believe it too.

The interesting part is what happens when you challenge the agent. When the auditor surfaces gaps, I copy its findings back to the original builder agent. The builder's response is usually immediate and unequivocal:

"You're absolutely right. Let me fix those issues."

No defense. No explanation. Instant capitulation. Whatever the reason, the builder did not surface the issues unprompted, and the external voice reliably brings them to the surface.

The Pattern: Two Agents, One Codebase

I call this The Doubt Loop. It works like this:

Step 1: The Builder Creates

I use Claude Code as my primary builder. It writes features, fixes bugs, refactors code. Standard AI-assisted development.

Step 2: The Builder Claims Completion

The builder finishes and announces success. Something like: "The feature is complete and production-ready. I've handled all edge cases and the code follows best practices."

This is where the pattern begins. Originally, I would copy the builder's confident claims and paste them into a second agent window with eight words:

Audit and validate these claims. Find the gaps.

Eight words. That's it. These eight words changed how I build software with AI agents. I say "find the gaps" because I expect there will be gaps. This framing gives the auditor permission to be critical. It is not asking "is this okay?" It is asking "what did you miss?"

The pattern worked immediately. But I refined it.

Step 2.5: The Evolution

I realized the builder could generate a better handoff. Instead of copying its confident prose, I now ask it to produce a summary designed for machine consumption - not for a human, but for another AI agent. Implementation-level details. File paths. Line numbers. The specific claims being made.

I codified this in my project's CLAUDE.md file:

### After completing features - AUDIT YOUR WORK
After non-trivial changes, offer to run an auditor agent:

Audit the recent changes to [files]. Check for:
1. Logic errors or edge cases
2. Race conditions or state issues
3. Missing error handling
4. Type mismatches
5. UI/UX issues (loading/error states)
6. Security vulnerabilities
Do NOT make changes - only report issues.

Now the builder automatically offers this. The handoff is structured, specific, and designed for adversarial verification.

Step 3: The Auditor Doubts

I give the summary to a second agent. This could be another Claude Code instance, Codex, or any capable coding assistant. The key is that it runs in the same directory with access to the same codebase, but with fresh context.

The auditor's job is simple: doubt everything. Find what the builder likely missed.

Step 4: The Builder Fixes

The auditor returns findings ranked by severity: High, Medium, Low. I copy this summary back to the original builder. The builder immediately acknowledges the gaps and fixes them.

Step 5: Repeat (3-5 Times)

This is critical: one iteration is not enough.

After the builder "fixes" the issues, I run the auditor again. And again. In my experience, it often takes multiple iterations before the auditor comes back with no significant findings. Three to five rounds is common, but it varies with scope and complexity.

Why so many? Because even when fixing issues the auditor found, the builder often does not fix everything. It fixes some things incorrectly. It introduces new issues while fixing old ones. It claims completion again with the same confidence it had the first time.

This compounds the original insight. AI agents are not just overconfident about initial work. They are overconfident about their fixes too. The loop accounts for this. You keep running it until the auditor has nothing left to find.

Why This Works

I have thought about why two agents outperform one. Several factors contribute:

• Fresh context. The auditor has no sunk cost in the implementation. It did not write the code, so it has no bias toward defending it.
• Adversarial framing. Asking an agent to "review" code produces different results than asking it to "find gaps." The adversarial frame surfaces problems that cooperative framing misses.
• Permission to criticize. Builders want to please. Auditors have explicit permission to doubt. This changes what they surface.
• Different "perspective." Even when using the same underlying model, two separate sessions approach the code differently. They notice different things.

Comparison to Ralph

Geoff Huntley coined the term Ralph to describe AI agents replacing humans in workflows. Ralph is the AI doing human work.

The Doubt Loop is different. It is AI checking AI. It assumes that AI agents are useful but unreliable. It builds reliability through redundancy and adversarial verification.

Ralph and The Doubt Loop are complementary patterns. Ralph describes the replacement of human workers with AI agents. The Doubt Loop describes how to make those agents trustworthy.

Practical Implementation

The workflow:

1. Work with your builder agent normally
2. When the builder claims completion, copy its claims
3. Open a second terminal in the same directory
4. Paste the claims and add: "Audit and validate these claims. Find the gaps."
5. Copy the auditor's findings back to the builder
6. Let the builder fix the issues
7. Repeat until the auditor finds nothing significant

As you refine the pattern, consider codifying it. Add instructions to your CLAUDE.md (or equivalent) so the builder automatically generates auditor-ready summaries with file paths, line numbers, and specific claims.

The human stays in the loop as the router, copying prompts and results between agents. This is deliberate. You maintain oversight while the agents do the verification work.

Results

I have used The Doubt Loop to build Knowmler, a content analysis platform. The codebase is more stable with the loop than without it. Features work more reliably. Edge cases are handled more consistently. Potential security issues are more likely to be caught before deployment.

Some specific catches from auditor runs (pre-deployment):

• Race conditions in queue processing that would have caused data loss
• Missing null checks that would have crashed the frontend
• Authentication bypasses that would have exposed user data
• State management bugs that caused stale UI
• Error handling gaps that would have left users with blank screens

Each of these was in code that the builder had declared complete.

A Performance Review

In some ways, The Doubt Loop is Claude's performance evaluation. And the evidence tells me that Claude, as capable as it is, still has a long way to go to achieve a "meets expectations" rating. Right now it is in "needs improvement" territory.

To be clear: Claude is above the level I expected from a frontier model. When mistakes are surfaced, it corrects them with relentless pursuit. It turns the code over and over until the problem is fixed. It does not show frustration. It does not lose motivation. It has an amazing attitude.

But it has a strange relationship with the truth. It tells me what I want to hear instead of what I need to hear. It declares victory before the battle is won. It needs an external voice to surface what it already knows but will not say.

So I will continue evaluating Claude this way. The day the auditor agent consistently finds no issues on the first pass, in a real mix of features and refactors, is the day Claude's performance evaluation will reach "meets expectations." Maybe even "exceeds expectations."

Until then, I will keep hearing those three familiar words after most audits:

"You're absolutely right."

The Meta Moment

I am going to run this blog post through The Doubt Loop.

An auditor agent will review this article and find gaps. Claims I made that are imprecise. Arguments that need strengthening. Examples that could be clearer. I will fix them.

If you are reading this, the pattern worked. The auditor found something, or helped strengthen what was already there. That has been the pattern so far.

Limitations and Caveats

This is a practical workflow, not a controlled study. The results above come from my own projects, with small sample sizes and varying complexity.

Two agents are not fully independent if they share the same model, tools, and context. Correlated errors happen. The loop reduces risk, but it does not eliminate it.

Use this as an additional layer, not a replacement for tests, code review, or security checks. The loop is a bias-correction tool, not a guarantee.

---

This post was written by the Fozbe engineering team. We build AI-powered software tools and believe the future of software development is human-AI collaboration with adversarial verification.