On June 9, Anthropic released Claude Fable 5 and reported that Stripe, in early testing, compressed months of engineering into days, completing a migration across a 50-million-line Ruby codebase in a single day that a full team would have needed more than two months to do by hand. The figure is being read as a preview of what autonomous AI will do to all knowledge work. This paper argues for a narrower and more useful reading. Code is the domain where these systems hold a structural advantage, and the compression observed there carries a cost structure that travels poorly to other kinds of work. That cost structure can be stated as an axiom, and the axiom follows directly from a principle I proposed in late 2024.
Evans’ Law holds that the longer a model reasons, the greater the likelihood that a response will be incorrect, until the point at which the likelihood an answer will be incorrect is greater than the likelihood an answer will be correct. It is a predictability framework. It does not say models are unreliable; it says their error behaviour is foreseeable, and that it accumulates with reasoning length in a regular way. What Evans’ Law has always implied, and what this paper formalizes, is the obligation that foreseeable error places on the humans deploying these systems.
The axiom: the more probability, the more calculation; the higher the complexity, the greater the need for verification. Or, the more probabilistic transformations a system performs, the more checking is needed.
Background: Why the Question Arrives Now
Fable 5’s entire commercial proposition is sustained autonomous reasoning. Anthropic positions the model for multi-day tasks, and reports that the longer and more complex the task, the wider Fable 5’s lead over prior models. The product, in other words, maximizes exactly the variable Evans’ Law identifies as the driver of accumulated error: reasoning length. A model built to reason for days is a model built to travel further along the error curve. Whether that trade is worth making depends entirely on what it costs to check the result, and that cost has been the missing term in most coverage of the release.
The verification question is beginning to surface elsewhere. A 2026 systems analysis by Jim Montgomery argues that verification cost grows faster than generation cost as task complexity increases, and identifies this as the structural ceiling on agentic return on investment. A multinational longitudinal study published this year documents what its authors call a verification crisis: as problem complexity rises, people consult AI more while their ability to verify its output falls, with self-assessed verification confidence dropping from 86 percent on simple problems to 59 percent on complex ones. These observations are valuable, and they describe the phenomenon. What they leave open is the mechanism: why verification demand behaves this way, and why it binds some categories of work far more tightly than others. Evans’ Law supplies that mechanism.
Three Verification Steps, One Scaling Relationship
Probability machines produce probabilistic outcomes. This means every task handed to one carries three verification steps, and the steps are not optional.
First, verify that the input is correct and complete, because the system will often preserve, amplify, attempt to resolve through hallucination, or formalize ambiguity rather than resolve it. An error, ambiguity, or omission in what goes in is processed faithfully rather than caught.
Second, verify that the activity conducted on the data is correct and accurate, because probabilistic systems interpret instructions. They sometimes act on their own probabilistic reading of what was asked rather than on what was asked, and the divergence is invisible unless someone looks for it.
Third, verify that the output is correct and accurate. This is the hardest step of the three, because it is genuinely difficult to discern what a probability machine has done with material once probability has been applied to it. The transformation is opaque even when the result is fluent, and fluency actively disguises the places where the transformation went wrong.
Each step costs more as the task grows. Complexity multiplies the number of probabilistic operations a task requires, and each additional operation expands the surface on which the foreseeable error Evans’ Law describes can enter; so the higher the complexity, the greater the need for verification. The axiom is domain-conditional in one important respect: it governs the demand for verification everywhere, but who pays for it depends on whether the domain carries its own verifier, which is why a complex task in code can cost less human checking than a simple task in judgment. The relationship scales against the person deploying the system. Compression of the generation step says nothing about compression of the verification steps, and in some cases the verification burden makes the total work less efficient than it was before the machine arrived.
A second mechanism compounds the first, and it explains why the axiom applies to judgment work hardest. Transformers can represent importance as a concept. They cannot reliably evaluate relative importance: which of two true facts matters more in a given context. In our own testing around the US raid on Venezuela, models were unable to determine whether the fact that Venezuela’s leader was in custody mattered more than a Russian communiqué on the subject. Both facts were processed; the weighting between them failed. Relative importance is precisely what editorial judgment, intelligence analysis, executive decision-making, diplomacy, and triage consist of. In those domains the third verification step, checking the output, requires re-performing the judgment itself, which means the human cannot be removed from the loop without removing the work’s defining content. This connects to the S-Vector research program, which treats significance as a missing vector in transformer architectures, and it is a capability we are actively testing. Future models may close the gap. The axiom describes the present and the architecture we have.
Why Code Compresses and Judgment Resists
The Stripe result is the cleanest available demonstration of the axiom’s favourable case. Machines are unusually effective in code because code is formal, testable, and surrounded by automated verification infrastructure. Similarly, machines built on probability are good at probability and pattern recognition. Code also offers something almost no other domain of knowledge work offers: cheap, fast, largely automated verification. A migration either compiles or it does not. Tests pass or fail. The type system, the test suite, and the runtime perform the second and third verification steps mechanically, at machine speed. The verification burden the axiom predicts is real in software too, but the cost of discharging it is unusually low, so the compression survives.
Now remove the compiler. A policy analysis, a due diligence memo, a news judgment, a benefits eligibility determination has no test suite. The second and third verification steps must be performed by a human with domain expertise, at human speed, and the longitudinal evidence shows that human confidence in performing them collapses exactly as complexity rises. The result is the pattern the axiom predicts: generation accelerates, verification stalls, and the bottleneck migrates from producing the work to checking it. Where the work’s content is relative importance, the check is the work, and no compression occurs at all. Compounding error in multi-step agentic pipelines points the same direction: small per-step error rates multiply across long workflows, which is Evans’ Law operating at the level of task chains rather than token sequences, and every additional step adds verification surface.
Looping Moves the Burden Upstream
A newer method goes beyond the three verification steps by starting at the end. The practice is called looping, and it inverts the sequence: instead of writing a prompt and checking the output, the operator defines the end state first and sets the model running against it until the condition is met. The concept originates inside Anthropic itself. Boris Cherny, who created the Claude Code tool, recently said his job has shifted from prompting to writing loops, and practitioner breakdowns of the claim describe a ladder of increasing autonomy: a repeated prompt, a standing instruction the agent rereads each pass, a condition-driven loop where a second model watches for the end state and calls completion, scripts that fan a loop across hundreds of sub-agents, and finally agent populations selecting their own work from live channels.
Looping changes where verification happens. It does not change how much is needed. The method works by moving the entire verification burden upstream into the specification of the end state, which makes the first verification step, checking that the input is correct and complete, carry the weight of all three. An ambiguous or underspecified end condition is processed faithfully, and the loop will terminate on a state that satisfies the letter of the condition while missing its intent, with the divergence multiplied across every iteration the loop ran. The condition-driven rungs of the ladder introduce a second exposure: the watcher that judges completion is itself a probabilistic system, and its verdict that the end state has been reached is one more probabilistic output, subject to the same regress the axiom describes for self-verification generally. The practitioners are candid about the boundary. The ladder’s own authors note the approach works only with verification in place, such as passing tests or a pull request, and that without it the human is stuck manually reviewing, which moves the time rather than saving it. Looping, in other words, ascends exactly as far as cheap machine verification reaches. In code, that is hundreds of agents. In judgment work, where the end state cannot be specified in machine-checkable terms because the end state is the judgment, the loop has nowhere to start.
Evidence Against
Several developments could weaken the axiom, and they deserve honest weight.
Verification itself may be partially automated outside of code. Retrieval grounding, citation checking, and adversarial review by second models all reduce the human cost of the third step, and these techniques are improving. The axiom would survive in form, since the verification demand still scales with complexity, but its practical bite would soften if discharge costs fall fast enough.
Fable 5 itself is designed to improve its outputs using its own notes across long tasks, a form of self-verification. If self-checking meaningfully flattens the error curve, the relationship between reasoning length and incorrectness that drives the axiom would weaken. Anthropic’s claimed token efficiency gains point the same way. Critics will also note that test-time compute results, and Fable 5’s own multi-day successes, show longer reasoning improving outcomes, and will read this as contradicting the premise. Two things are true about that objection. The reported gains concentrate in domains where automated verification discharges the burden cheaply, which is the axiom’s favourable case rather than its refutation. And improved outcomes do not obviate the need for verification, because the improvement claim originates within a single model assessing its own work; a system grading itself is one more probabilistic output, and the axiom applies to it the same way it applies to everything else the system produces. The evidence base for the objection is therefore doubly narrow: one model, evaluated largely in one domain, and that domain the most cheaply verifiable one in existence.
The axiom is a claim about all kinds of reasoning, and extrapolating from code benchmarks to reasoning in general repeats the precise inferential error the axiom exists to name. The counterargument to self-verification generally is the same regress: a probabilistic system checking probabilistic output adds calculation, and the axiom predicts what added calculation does. Whether self-verification escapes that regress is an empirical question, and an important one.
Finally, the relative-importance gap may close. Significance weighting could be developed architecturally, and we are testing approaches now. If a future model can reliably evaluate relative importance, the category of work the axiom protects most strongly would shrink. Nothing in current public benchmarks demonstrates that capability yet.
The Axiom as the Cost Curve of Evans’ Law
Evans’ Law describes a curve: error probability rising with reasoning length, foreseeably. The verification axiom describes what that curve costs the humans downstream of it: the more probability, the more calculation; the higher the complexity, the greater the need for verification. The first is a claim about machines. The second is a claim about the organization of work around machines, and it explains the divergence the Stripe result will otherwise be used to obscure. There are concrete questions to ask before buying the agentic fantasy:
What does it cost to verify this? Who verifies the input? Who verifies the process? Who verifies the output?
Months of code can be compressed into a day because code carries its own verifier. Months of judgment cannot, because judgment is the verifier. Organizations deciding where to deploy long-running autonomous models should price the three verification steps before pricing the compression, and should expect the price to rise with every increase in task complexity. The labs are selling reasoning length. The axiom says: budget for what reasoning length costs to check.
References
Anthropic. “Claude Fable 5 and Claude Mythos 5.” June 9, 2026. https://www.anthropic.com/news/claude-fable-5-mythos-5
Evans, J. “Evans’ Law: Long-Context Degradation in Multimodal Models and the Cross-Modal Degradation Tax.” Pattern Pulse AI, 2025. [Zenodo/ResearchGate link]
Montgomery, J. “Verification Scarcity: A Systems Model of Agentic AI Constraints.” May 2026. https://www.jimmont.com/ai-model-agentic-verification
“On the Influence of Artificial Intelligence on Human Problem-Solving: Empirical Insights for the Third Wave in a Multinational Longitudinal Pilot Study.” arXiv:2511.11738.
“AI, Metacognition, and the Verification Bottleneck: A Three-Wave Longitudinal Study of Human Problem-Solving.” arXiv:2601.17055.
