Verification is the new bottleneck. The question is which kind.
The problem in AI isn't generating information anymore. It's knowing whether that information is actually correct. Two types of verification are emerging, and they solve very different problems.

Lately, I've been noticing how much Claude Code is talking about verification. Maybe it's an echo chamber effect (when you're building in this space, everyone suddenly seems to be working on what you're working on).
Verification is the real bottleneck.
The problem in AI isn't generating information anymore. It's knowing whether that information is actually correct.
That's why both OpenAI and Anthropic are shipping verification services and features at full speed. Claude Code now runs agent-based code review on every pull request, with multiple AI reviewers cross-checking findings to reduce false positives. OpenAI is pushing Codex toward iterative execution loops where the agent runs tests, reads the output, and self-corrects. Both are good moves. Necessary, even.
But it's worth pausing for a second on what kind of verification we're actually getting, because not all verification is the same.
In this AI world, there are two types: probabilistic and deterministic.
Probabilistic verification (what the AI labs are doing)
This is the type of verification AI engines are applying right now. Call it cognitive verification. Picture it like a small army of minions, each one checking whether a piece of data looks correct.
The problem? It depends entirely on what they're checking against. You can have a thousand minions verify a fact, but if their reference source is wrong, the answer is still wrong.
And here's the bigger issue: there's no determinism. We're playing with probabilities. Sometimes that verification has a 99.9% chance of being correct. Sometimes (especially in areas where the engine wasn't trained well), that percentage drops.
That's when hallucinations show up, because an AI engine almost never tells you, "I'm not sure if this is true." It just hands you the most plausible-sounding answer with the same confidence as everything else.
For many use cases, this is fine. Honestly, it's the only thing that scales to fuzzy, human, ambiguous problems. But for some specific things, it's a beautiful disaster waiting to happen.
Deterministic verification (what we do at Predictable Machines)
The other kind of verification is the one we're betting the company on. Deterministic verification.
What does that actually mean? We verify using mathematical methods to obtain binary results. Is it correct? Yes or no.
You can't apply this to everything. Ask a philosophical question, and deterministic verification has no value, because the result is ambiguous by nature. But for what we apply it to, it makes total sense. Code.
What do we check it against? The specifications of what you want that code to do. The spec is the source of truth. Does the code do what you wanted? Yes or no.
The how, in short: we generate specifications and requirements (think of it as very detailed documentation of what you want to build), we translate that into a mathematical language called Lean, and we apply a methodology called Formal Verification to formulate every possible theorem about the expected behavior. Then we verify each one. When something fails, we catch it.
It sounds abstract, so let me make it concrete.
Imagine you ask your AI assistant to implement a search function for your e-commerce site. We generate a set of specifications based on the expected behavior of that search: which input filters it must accept, and what shape any output has to take. Then we test every behavioral theorem. The system would flag things like "the price filter accepts a string when the spec requires a number" or "the response object is missing a field the spec requires whenever results come back." We verify every possibility, not just the happy path.
I used e-commerce because it's easy to picture. Now switch the scenario to code generation in regulated, sensitive sectors: banking, pharma, and healthcare. And then picture teams of 20 or more developers working on the same project, all generating code with AI. The fragmentation in that scenario is pouring gasoline on a fire.
Where this leaves us
I hope the two flavors of verification are clearer now, because the word will be everywhere over the next year. When you see "verification" in a feature announcement, the next question to ask is: probabilistic or deterministic? Both have a place. They just solve very different problems.
For most general AI use cases, probabilistic approaches are sufficient. But the second the output has to be correct, not just plausible (code, contracts, regulated systems), probabilistic verification is not going to cut it. You need math.
This matters even more now that building itself has gotten so much easier. I wrote about what changes once building becomes the default: when creation is cheap, correctness is the part that's still expensive.
That's the bet we're making at Predictable Machines.
If you want to know more about what we're building, especially what we have cooking with Predictable Code, drop me a line. Always happy to nerd out about formal verification.