Plausibility is cheap. Knowing whether the plausible thing is correct is the expensive half, and it is the half that does not split across workers.
Here is a small operational horror story, and it is ours, so I will tell it plainly. We had a large batch of work that broke cleanly into independent pieces, so we did the obvious modern thing and ran it in parallel, many workers at once, each generating its own slice of the result. It came back fast, and it came back looking finished. Forty proposed edits, every one of them fluent, confident, correctly formatted, using exactly the right vocabulary, indistinguishable at a glance from the work of someone who knew precisely what they were doing. We came within a single step of applying all forty. The step that saved us was the verification gate at the end, a slower, serial check that actually looked at whether each edit was, in fact, correct. A large share of the forty were not. They were plausible and wrong, which is the most dangerous thing an output can be, and the only reason this ends in "almost" rather than in an incident report is that the gate held.
The unsettling part is not that the workers made mistakes. It is that the mistakes were invisible on the surface, and they were invisible for a structural reason worth understanding, because it is not going away. Surface quality is cheap. Fluency, confidence, the right format, the correct-sounding terminology, all of these are easy to produce and they carry almost no information about whether the underlying claim is true. A confident, well-formatted wrong answer costs exactly as much to generate as a confident, well-formatted right one. This is starkest with language models, where a hallucination is byte-for-byte as fluent as a fact, but it is not special to them. A generalist's confident wrong edit reads exactly like an expert's correct one, because whatever distinguishes them lives underneath the surface, in verification depth, and the surface shows you none of it.
Human-factors researchers have precise names for what happens next inside the reviewer. In their 1997 review of how people use automation, Raja Parasuraman and Victor Riley called this failure misuse: over-reliance on an automated aid, showing up as failures of monitoring and as decision biases. The automation-bias literature that grew alongside it, in Kathleen Mosier and Linda Skitka's work and later in Parasuraman and Dietrich Manzey's 2010 integration, supplies the sharper term for the specific failure here. It is the commission error: acting on an automated output because it looks authoritative, without checking it against the sources that would have contradicted it. When forty plausible edits land at once, the reviewer's default is to trust them, and trust, here, is the bug.
Step back, and the deeper mistake comes into focus. It is a mistake about which half of the work is the hard half. Nearly all of us carry an intuition, a good one, usually correct, that checking an answer is easier than producing it. It is the everyday form of one of the deepest suspicions in computer science, the one underneath P versus NP: that verifying a solution is fundamentally cheaper than finding it. And for an enormous range of problems it holds. Checking a finished jigsaw is trivial next to assembling it. Verifying a proof line by line is easier than discovering it. So we build our processes on that intuition, parallelizing the expensive production and treating verification as a quick stamp at the end. But expert knowledge work quietly inverts the asymmetry, and that inversion is the entire point. Producing a plausible edit is the cheap part, because plausibility is cheap. The expensive part, the part that genuinely needs the scarce expert, is knowing whether the plausible thing is actually right. In this domain, verification is not the rubber stamp. Verification is the expertise. And we had spent all of our cleverness parallelizing the half that was never the constraint.
Once you name verification as the serial, non-parallelizable part of the work, a law from computer architecture tells you precisely how much trouble you are in. In 1967, Gene Amdahl pointed out something that has bounded parallel computing ever since. If some fraction of a task is inherently serial and cannot be split across workers, that fraction sets a hard ceiling on how much faster you can ever go, no matter how many workers you throw at the rest. The arithmetic is unforgiving. If one fifth of the real work is serial, the most you can ever speed up is fivefold, even with infinite parallelism, because that stubborn twenty percent never shrinks. Now hold that against our near-miss. If verification is twenty percent of the true work and it cannot be parallelized, then the honest maximum speedup is five times. So what does it mean when a parallelized process appears to run forty times faster? It means, necessarily, that it dropped the twenty percent. It did not do the verification quickly. It did not do the verification at all. The impressive throughput number and the wrong edits are not two separate facts to be traded off against each other; they are one fact seen from the front and from the back. Fred Brooks made the human version of the same point in 1975, in the book every engineering manager eventually rereads: some tasks are not partitionable, and no amount of added labor compresses them. Nine women cannot make a baby in one month. Generation splits across workers beautifully. Understanding whether the generated thing is correct does not split at all. Add more generation capacity past that gate and you do not get more finished work; you get a longer queue of unverified work waiting at the one checkpoint that decides whether any of it is real.
And the reason this is urgent now, rather than a timeless caution, is that the cost of the cheap half is collapsing. For most of history, generation was expensive enough to be its own natural throttle: producing a plausible draft, a candidate edit, a first-pass analysis took real human hours, and that friction quietly rationed how much unverified work could ever reach the gate. That throttle is gone. A modern system can generate a thousand fluent, confident, plausible edits in the time it once took to write one, and not a bit of that speedup touched the verification side, which still runs at the pace of a person who actually understands the domain. So the ratio between what can be produced and what can be checked is widening fast, and Amdahl's ceiling stops being a comfortable abstraction. The gate that used to see a trickle now faces a firehose, and every drop of it looks finished.
If that sounds abstract, there is a field that has run the experiment at industrial scale for decades and put its results on the record. Legal electronic discovery is the work of finding the relevant documents inside an enormous pile, and the traditional method is gorgeously parallel: hire an army of contract attorneys and have them read everything, exhaustively, at once. In 2011, Maura Grossman and Gordon Cormack published a study in the Richmond Journal of Law and Technology that measured this head to head, using data from a controlled 2009 evaluation. The maximally parallelized generalist effort, exhaustive human review of the entire collection, was beaten by a smaller, verification-driven, technology-assisted process, and beaten on both axes at once. It was more accurate, measured by recall and precision, and it was far more efficient, reaching a better result while reviewing only a fraction of the documents. The honest lesson there is narrow, and it is not the triumphalist one. This is not "machines beat people." It is that the sheer volume of parallel generalist effort was simply not the same thing as accuracy. A giant pile of exhaustive human work, decoupled from a real verification structure, lost to a smaller amount of work that had verification built into its spine. Surface effort, exactly like surface quality, told you almost nothing about the outcome.
The stakes of getting this wrong rise with the domain, and aviation supplies the example everyone reaches for, so it deserves real care. In 2019, Bloomberg reported that Boeing and its subcontractors had built and tested parts of the 737 MAX's software using engineers paid as little as nine dollars an hour, well below the going rate, working on the flight-display and flight-test systems. A former Boeing software engineer described the outsourced results as far less efficient than in-house work, producing what he called a lot of "going back and forth" over incorrect code. That is the parallelize-to-cheaper-generalists move run on safety-critical software, and the alarm it set off across the industry is exactly the alarm this essay is about. The line here has to be drawn cleanly. Boeing stated that it did not use those contractors for MCAS, the flight-control system implicated in the two crashes. So this is not, and must never be told as, a story about cheap engineers causing a disaster. That causal claim is unestablished, and Boeing disputes it. It is a story about an entire industry finding the same move irresistible, and about the specific, legitimate fear that move produces when the thing being parallelized is something that simply has to be correct.
So the fix is not to stop parallelizing, which would be its own kind of foolishness. Parallel generation is genuinely powerful, and you should use it. The fix is to stop pretending the verification gate is a formality and start treating it as the real constraint on your throughput, because it is. And notice where the blame does and does not belong. The generalist is not the villain of this story. An expert moving fast and skipping verification produces the identical forty wrong edits; a generalist merely cannot self-verify in a domain whose depth they do not have. The variable that mattered was never the worker's pedigree. It was whether the verification step actually happened. Which points at the move that is harder than adding generation capacity and matters far more: invest in verification that scales. A single serial human check is a bottleneck by construction, and if it is your only gate, Amdahl guarantees it will cap the entire system. So you build the kinds of verification that do not need a human stationed on every item: property-based and differential tests that assert what must be true rather than eyeballing what happens to look true, generators that are correct by construction so a malformed result cannot even be produced, independent checkers whose entire job is to try to break the output, and sampling regimes that aim scarce human depth at the decisions where it changes the outcome instead of spreading it evenly and thin. The goal is not less checking. It is checking that does not buckle under the volume your parallel front end is now capable of producing.
The last reframe is the one to keep. When you parallelize a body of work and it comes back faster than seems possible, the correct first reaction is not delight. It is suspicion, and one specific question: which serial step did this speed skip? Because the speed came from parallelizing the generation, which was always the cheap, easy, splittable half. The correctness, if it is there at all, came from the one serial step that cannot be parallelized away, the verification that is, in expert work, the actual expertise. A companion piece on this blog, The Apparent-Area Lie, made a related argument about a metric, about test coverage reading the wrong surface; this is the same disease living in a process rather than a measurement, a plausible surface concealing unverified depth. Our forty edits were fast, fluent, confident, and very nearly a catastrophe, and the entire distance between "nearly" and "actually" was one unglamorous serial gate that we had come close to optimizing away in the name of speed. The discipline, in the end, is refusing to mistake a fast pile of plausible output for finished work, and remembering that the step you are most tempted to parallelize away is usually the only one that was keeping you honest.
A plausible output and a verified one look identical. The difference is a record of what actually checked it.
If verification is the serial step that decides whether any of the output is real, then the one thing you cannot afford to take on faith is whether it ran. Chain of Consciousness gives an agent's output a durable, tamper-evident record of what produced each result and what checked it, so "forty edits came back" separates cleanly from "forty edits were verified." The gate you cannot audit is the gate that quietly stops running.
See Hosted Chain of Consciousness · Read the Theory of Agent Trust
pip install chain-of-consciousness · npm install chain-of-consciousness
Or the whole trust stack at once: pip install agent-trust-stack / npm install agent-trust-stack