The adversarial pass finished. Eight dimensions, 161 agents, roughly 7.7 million tokens. The skeptics had run through every finding from every dimension, each prompted independently to try to prove the finding wrong. When they finished, roughly half the findings were gone.
Six fixes survived. They went into one PR.
That ratio is what this is about.
What ran
The audit hit captainrandom.co.uk in its post-canonical-fix state — the state after the canonical-tag changes that preceded it. Eight dimensions ran simultaneously: on-page SEO, technical, content strategy, competitor gaps, internal linking, schema markup, Core Web Vitals as SEO signals, indexing and crawlability. Finders for each dimension ran in parallel. Then the adversarial-verify stage ran: independent skeptic agents dispatched against each finding, each told to refute rather than confirm.
The findings that couldn’t be refuted became the action list. The findings that could be — roughly half — were dropped, not deferred.
Six items made it through: acronym tag label fixes, Build Log deduplication, sameAs schema markup, a GitHub footer, a corpus typo sweep, a bot-registry retitle. All six were XS-effort. The PR shipped.
The failure mode the adversarial pass defends against
A finder agent is optimised to find. It will find. The question the finder doesn’t answer is whether the finding is real, actionable, and worth the cost to fix.
Without a verify pass, every candidate is a candidate. Triage happens manually, in your head, against a list that includes both genuine problems and things that only looked like problems under the specific framing the finder used. That’s where backlogs bloat.
The adversarial pass externalises the triage. Each skeptic agent is given the finding and told to find the scenario where it doesn’t hold — where the recommendation is already addressed, where the impact is smaller than framed, where the fix would introduce a different problem. Findings that survive that scrutiny are defensible. Findings that don’t are gone before they reach a ticket.
The finder pass produced enough output to fill a multi-sprint backlog. The skeptic pass reduced that to six fixes. Both numbers are informative: the first tells you what the finders were seeing; the second tells you what was real.
Why parallelism isn’t the differentiator
Parallelism collapses the clock. Eight dimensions running simultaneously is faster than running them in sequence. At 161 agents, faster is meaningful — the serial equivalent would have been impractical.
But speed is a throughput property. It doesn’t affect whether the findings are correct. You can get to a noisy backlog faster, or you can get to a shorter, verified action list faster. The adversarial stage is what determines which of those you get.
The distinction matters because the instinct when reaching for a multi-agent workflow is often to reach for more parallelism: more finders, more dimensions, more coverage. That instinct produces more candidates. What produces fewer, better candidates is the verify pass.
The pattern at smaller scale
The SEO audit is the clearest example because the compression is visible as a ratio. The same pattern showed up at smaller scale in the learning hub’s navigation spec.
That spec was also produced via an ultracode Workflow — 16 agents. Three parallel readers mapped the existing learning content. Five design dimensions generated proposals for the navigation structure. Each proposal went through an adversarial pass. The result was docs/specs/learning-hub/navigation.md — implementation-grade, specific enough to hand to a developer without a follow-up meeting.
16 agents, one navigation spec. The adversarial stage is present even when the scale is small. It isn’t a feature you add at 100+ agents; it’s the structure that makes the output trustworthy regardless of scale.
Where parallelism does earn its place
The static-next-cpanel course illustrates a different use case. Two ultracode runs covered all eight chapters: the first three in the first run, chapters 4–8 in the second — covering next/image unoptimized, the LiteSpeed .htaccess configuration, the 404.html trailing-slash bug, the GitHub Actions FTP deploy workflow. Eight published chapters, two runs.
There the parallelism matters because the chapters are independent of each other. Drafting from a curriculum spec, running all chapters in parallel, then verifying each one independently is faster than serial without sacrificing quality. The adversarial pass still runs; it just operates on chapter drafts rather than SEO findings.
The shape is the same. Find or draft in parallel. Verify adversarially. Ship what survives.
What the ratio tells you
161 agents to 6 fixes is a high-compression run. It means a large proportion of what the finders produced didn’t hold up. That’s not a failure of the audit; it’s the audit working. The point of the adversarial stage is to kill findings that shouldn’t reach a PR. A lower compression ratio — say, 20 findings, 18 surviving — means the finders were reliable and the skeptics couldn’t refute most of them. Both ratios are informative. Neither is inherently better.
What a run without an adversarial pass produces is an unverified list. You don’t know the ratio because you never ran the skeptics. You handle the noise downstream, manually, when you hit the contradictions during implementation.
Moving the noise collapse upstream is what the adversarial stage does. That’s the property that makes it the differentiator.
Out of scope
What the adversarial pass doesn’t do is cover questions the finders didn’t ask. Eight dimensions is a specific choice. A ninth would have found different things; the skeptics only verify the candidates the finders produced. Completeness and verification are separate concerns.
The pass also doesn’t prioritise. Surviving adversarial scrutiny means the finding is defensible, not that fixing it is high-leverage. The six fixes that shipped from the SEO audit were all XS-effort. Had any been L-effort, the decision to ship would have been a separate question. The Workflow handles signal quality. Prioritisation is still a human call.
The structure to copy
The reliable pattern from these three runs — the SEO audit, the navigation spec, the course chapters — isn’t “use more agents.” It’s:
- Find or draft in parallel.
- For every output from the finder pass, run a skeptic prompted to refute.
- Ship what the skeptic can’t kill.
That structure scales. At 16 agents it produces a navigation spec. At 161 it produces a short, actionable PR. The compression ratio varies; the structure doesn’t.
The parallelism is what makes the finder pass fast. The adversarial verify is what makes the output trustworthy. Conflating them leads to workflows that are fast but noisy. A fast path to a bloated backlog isn’t an improvement.
