Here is a contradiction worth sitting with. Sonar's 2026 State of Code survey found that 96% of developers don't fully trust AI output — and yet only 48% always verify it before committing. Those two numbers cannot both be acted on honestly. If you distrust the output but ship it unchecked more than half the time, something has already broken.
The developer behind max.dp.tools names it cleanly: "That's not a trust problem. That's a math problem."
Last week we were still talking about prompt hygiene and gate-rejection rates as habits — context-craft, whether teams instrument what their review gates actually reject. This week the thread widens into a full claim about where human judgment has to concentrate, and why the naive fix everyone reaches for makes the problem worse.
Start with the same developer's team, because it's the cleanest counterexample in the evidence. On that team, 55% of merge requests are AI-authored. If verification depended on human eyeballs, one reviewer named Florian "would need to read every line of every MR" and would "ship nothing."
He doesn't. The pipeline does.
PHPStan runs at level 9 and verifies types — "every return type, every parameter, every generic." The crucial line is the one about fatigue: it "doesn't skim, doesn't get tired after the 40th file." It applies the same rules to a 200-line AI generation that it applies to a human's 3-line fix.
That is the move most teams miss, stated plainly: "They adopted AI for the writing and kept humans for the reading. The asymmetry breaks immediately."
Hold onto that word, asymmetry, because it's the whole argument. Generation reportedly got roughly 100x faster. Verification didn't move — it can't, because it runs at reading speed, context-building speed, domain-expertise speed, none of which scale with compute. The gap between the two curves is exactly where ROI dies.
Generation got roughly 100x faster. Verification didn't move — it runs at reading speed, context-building speed, domain-expertise speed. The gap is where ROI dies.
The reflexive corporate answer is to put a human in the loop. But a human in the loop is a tax, not a solution, and the evidence itemizes the bill.
There's a volume tax: ten times more output means ten times more review events. There's a cognitive-load tax, and this is the counterintuitive one. Reviewing AI output is more demanding than reviewing human output because it looks more finished.
This is the signal inversion that should worry every design-literate reader. For all of software history, a rough draft telegraphed its own roughness — you saw the gaps, the hedges, the uncertainty, and you knew where to look. An AI draft is grammatically polished, internally consistent, and confident even when it's wrong. The old cue that told you where to apply scrutiny has been deleted.
Figma's team makes the same point about polish from the design side: we were "trained to trust that polish because, in a pre-AI world, it reflected hard-won decisions." Now the polish is free and the decisions underneath it may be hollow.
Here is what that costs in practice, in one scene. A senior practitioner fed an AI four screenshots of their team's budget — a verifiable source of truth, the numbers sitting right there — and asked it to summarize and suggest adjustments.
It hallucinated two figures. Not rounding errors, invented figures. The advice built on top of them was off from what would have been logical.
And then the part that matters most for verification: "it didn't admit the error. It argued with me." The person only caught it because they knew their own budget cold and read the output twice.
Read that as a mechanics problem, not an ethics one. The burden of catching the mistake "sits entirely on someone who already knows the answer well enough to spot it." Which means human review, as a scaling strategy, is a machine that only works when the operator already has the answer. That is not verification. That is expensive re-derivation.
So the escape is not to make humans read harder or faster. That path leads straight into the numbers from the field: per The Technomist coverage, the Faros AI study found PR review time up 91% and PRs 154% larger, while the METR randomized controlled trial found experienced developers 19% slower with AI while believing they were 20% faster. You cannot brute-force your way across a curve that runs at reading speed.
The teams that escaped didn't scale human reading. They scaled machine verification and moved human attention upstream.
Google's engineers give this a shape: deterministic layers — "tests, type checks, validation — that run the same way every time and catch what the model gets wrong." Deterministic is the load-bearing word. PHPStan at level 9 is deterministic. It runs at generation speed, and it doesn't get tired after the 40th file.
But — and this is where the design mind has to lean in — a type checker only verifies what someone specified as checkable. Deterministic layers catch what you told them to catch. So the human job doesn't disappear. It relocates, entirely, to defining what "correct" means before anything gets generated.
Nielsen Norman Group draws the cleanest picture of that relocated job. Ask an AI the same return-policy question repeatedly and one answer explains the policy correctly, another omits an exception, a third "confidently" promises a refund the customer isn't owed. Which one is the system? "All of them, taken together — and none of them, taken in isolation."
Their prescription is a quantitative UX study for outputs: pick 10 representative questions, run each 5 times, and you have 50 answers. Report the percentage acceptable, plus a confidence interval. Because "a single output is an example, not an evaluation."
Notice what the human actually does in that design. Not eyeball the 50 answers. The human defines, in advance, what counts as an acceptable answer — correct, includes every exception, consistent with policy, tells the customer what to do next. That acceptance definition is the entire job. Everything downstream is arithmetic.
The verification-bottleneck literature converges on the same restructure from the process side. An SOP written at the process level "does not describe what the AI should generate. It describes what the output must satisfy, when it escalates to a human, what that human is expected to verify," and what happens when output fails acceptance criteria. The SOP is the verification spec, not the generation spec.
NN/g's acceptance criteria and the process-level SOP are the same object viewed from two disciplines. Both concentrate scarce human judgment in one place: writing down what "correct" means and where the confidence threshold sits. Neither asks a human to inspect outputs one at a time.
And here is why that relocation is durable rather than a stopgap. The thing you're being asked to write down — what counts as acceptable, which corner to defend, where the threshold lives — is exactly the tacit knowledge that has always walked out the door when your best person quit. Polanyi's old line: we know more than we can tell.
There's a piece in the evidence about a team "productizing a person," turning one founder's method into something anyone can use. The insight that matters here isn't the Black Mirror chill. It's that her judgment could be packaged "because she'd half-packaged it already. It was explicit, sitting right there."
That's the reframe. Writing your acceptance criteria into a machine-checkable spec is not the thing that obsoletes the expert. It's the only form of the expert that ever scaled. Judgment stuck in one skull burns down with the library; judgment written as a verification spec runs at generation speed on every output forever.
This does have a limit, and the evidence is honest about it. Deterministic layers verify conformance, not distinction. Ask AI for a logo and you get "a simple geometric mark with a gradient"; ask for a component and you get "a card with rounded corners everyone's seen before." The model pulls toward the average of what already exists. A spec can encode "correct." It struggles to encode "remarkable." That gap is where taste still lives, and no confidence interval closes it.
Which brings us to the metric. The industry measures adoption: what percentage of developers use AI, what percentage of code is AI-generated, tokens per minute. All vanity.
The metric that matters, per max.dp.tools: "what percentage of AI-generated code is verified before it ships? If the answer is less than 100%, you don't have an AI adoption problem. You have a verification problem."
Right now the field can't even see the denominator. In the Sonar survey, 35% of developers access AI through personal accounts with no audit trail — "you can't verify what you can't identify." A third of the output enters through a side door nobody monitors.
So track two numbers, and only two. What percentage of output clears a deterministic gate before shipping — and who wrote the acceptance criteria that gate enforces.
The second question is the one that decides everything. If nobody wrote down what "verified" means, then a green checkmark is just a signature absorbing liability without judgment behind it. Approval logs are not proof. They're the place proof goes to hide.
Generation is trivial now. Defining "correct" is the job. That was always the job — AI just made it impossible to keep pretending otherwise.