The honest limits: what none of this fixes

A production course whose own file history runs past two dozen separate fix passes, a silent failure that reported a confident wrong number, and the bias a same-model reviewer carries into its own…

6 min read

Modules 2 through 5 describe machinery that measurably helps: skills that load at the right moment, subagents that reason without inheriting each other's blind spots, workflows that catch a plausible-sounding wrong finding before it ships. All of that is true, and none of it means one pass is enough, that a silent failure announces itself, or that a second agent checking a first agent's work is automatically a neutral check. This module names the three limits with the most direct evidence available — real files in this repository, not a caveat added for balance.

Twenty-nine seed versions on one paper, most of them after the content was already "done"

content/courses.ts's entry for wec13 — one paper of one subject in the Veridian course — carries a comment above its seedVersion field for nearly every one of the 29 times that number has been bumped. Read them in sequence and the pattern is not "we found bugs while building it." It's "we found bugs for weeks after we thought it was finished." A 4-agent review council ran once, on 2026-08-28. Fixes tracing back to that single council run are still landing, one lesson at a time, in version bumps dated all the way through 2026-09-08 — ten days later, each one a separate audit against a real mark scheme or examiner report finding a gap the council's own pass, and every mark-scheme-bullet-coverage audit before it, had missed. business-objectives.ts alone was independently re-audited and fixed on 2026-08-31, 2026-09-05, and again on 2026-09-08 — three separate passes, three separate genuine findings, on one file, in the same paper, after the course had already been built, reviewed by a council, and shipped as "Live."

None of those fixes were wasted work, and none of them mean the workflow pattern failed — every one of them is exactly what an adversarial audit is supposed to produce. The honest reading is narrower and less comfortable: adversarial verification and multi-agent councils reduce the rate of undetected errors, they do not make a single pass — or a single council, or a single audit — sufficient. The real cost of quality on a project like this one is repeated, independently-triggered checking spread over weeks, not one thorough pass that catches everything the first time.

A silent failure looks exactly like an answer, right up until someone asks why the number is low

Building this course's own machinery is one thing; trusting what it reports is another, and this site has already published the sharpest example of that gap going wrong in a completely different project. A caption fetcher for a persona-extraction pipeline was missing one flag, which meant every request tripped a bot-detection wall instead of failing cleanly. The result wasn't an error. It was a manifest field: 456 out of 515 videos recorded as "no_captions" — a value that, read back later, says "this creator doesn't caption their videos." What actually happened was that the fetcher got blocked 456 times. "Same word, same column, entirely different fact — and nothing in the output distinguished them." The write-up states the general version of the failure plainly: "A failure that maps onto an existing, innocent-looking state in your data model will not be found by testing that things run. It will be found by someone asking why a number seems low, and only if they happen to look."

That is the same shape as a subagent that dies mid-task and returns nothing rather than an error — the exact failure the Workflows module names in the SAT-porting chain, where the fix that actually worked was telling agents to write incrementally rather than trusting a final summary. Both failures share one property that makes them worse than a crash: the system that produced them reports success. A workflow script that logs "all agents completed" is reporting that every agent() call returned — not that what it returned was true, complete, or the thing anyone actually asked for. Believing a clean run is a different claim from verifying one, and nothing in this course's machinery collapses that distinction automatically.

A second agent from the same model is not a neutral check by default

The Workflows module's adversarial-verify pattern — independent skeptics, majority-refute, default toward disbelief — is the single most load-bearing pattern in this course. It also has a specific, documented blind spot that the pattern's own framing doesn't fully close on its own. agent-orchestration's skill file states it without softening: "A second agent from the same model family is not a neutral check by default — published research on LLM-as-judge self-preference bias found judges systematically score familiar-reading output higher, independent of whether it's actually correct — which is exactly the shape 'an agent reports a bug that turns out not to exist' can hide inside." A skeptic asked to re-read a finding and vote on it can be swayed by how plausible the finding sounds, not by whether it's true, and that's a bias in the judging step itself — separate from, and not fixed by, the adversarial framing of the question.

The same source names two concrete mitigations, and both are corrections to something the naive version of adversarial-verify gets wrong: spawn the verifying agent "with a clean context that does not include the first agent's own reasoning trace or self-report," because a verifier that inherits the claim-maker's context inherits its blind spot before it even starts; and require "cited, reproducible evidence... for every finding, not a verdict," because a familiarity-biased judge produces plausible-sounding verdicts far more easily than it produces plausible-sounding citations of evidence that isn't really there. Skip either mitigation and the adversarial-verify pattern still runs, still produces a vote, and still looks like the same rigorous check — while quietly carrying the exact bias it exists to remove.

What this actually adds up to

None of these three limits is an argument against the machinery in modules 2 through 5. Each one is an argument against trusting it more than the evidence supports. Budget for repeated, independently-triggered audit passes as the normal cost of real quality, not as a sign an earlier pass was careless. Treat "the workflow ran clean and adversarial verify passed" as evidence in favor of a result, not proof of it — a silent failure and a confidently-wrong report both pass that same clean-run check by construction. And when a verify step is the thing standing between a finding and a decision, check that the verifier itself was set up to actually disagree — a clean context and a demand for cited evidence, not just a second vote from an agent that already half-believes the first one.

Building with Claude · progress saved in this browser · sign in to sync across devices

Up next

Reference: every artifact this course draws on

Unlike this platform's research-backed courses on outside subjects, almost nothing here needs an evidence tier — the claim is the file, and you can open it yourself

4 min