Verifier Engineering Is the Bottleneck

When AI will be able to do X? Original science, running a company, writing a novel that matters, cure cancer, dementia, etc.?

Scale, data, and algorithms, have been the answers for a long time, but the variable that actually sets the timeline is the construction of a good verifier.

The asymmetry

Frontier models became superhuman at competition math and competitive programming before they became reliable at scheduling a meeting. That inverts a century of intuition about which tasks are hard. Formal mathematics was supposed to be the summit. Calendar Tetris was supposed to be trivial.

It stops being strange once you ask a different question about each task. Not how hard is this to do, but how cheap is this to check. A competition problem has an answer key. A program has a test suite. Checking is nearly free, nearly perfect, and available at unlimited scale, so you can run the loop that actually produces capability: generate millions of attempts, check them, reinforce what passed, repeat. The model does not need to be taught mathematics. It needs an environment where mathematics grades itself.

Scheduling a week well has no answer key. Whether the week went well depends on preferences you never stated and consequences that show up later. The task is not harder in any computational sense. It is harder to check, and right now that is the property that matters.

Generation is expensive, verification is sometimes cheap, and capability pools wherever the asymmetry is favorable. The jagged frontier of what AI can and cannot do is a map of where good verifiers exist.

Verifiability is not a property of tasks

Most discussions split tasks into two kinds: verifiable ones like math and code, and unverifiable ones like writing, strategy, and taste. That binary is false.

Verifiability is a property of a pair, a task and a particular checking procedure. Theorem proving is verifiable by a proof assistant with perfect soundness, by a human mathematician at high cost, or by a language model judge that is fast and has blind spots you can exploit. Same task, three verifiers, three completely different training dynamics. When someone says a domain is not verifiable, what they are reporting is that nobody has built a good verifier for it yet. That is a fact about an engineering discipline, not about the universe.

Treat verifiers as engineered artifacts and you can ask what the specs are. Four parameters decide whether a verifier can carry a training run.

Soundness. Of the outputs it accepts, how many are actually good? Unit tests are the cautionary tale. Code can pass every test and still be wrong, and an optimized model will find that gap and live in it.

Cost. Checking has to be much cheaper than generating, because the loop only works if you can afford millions of attempts. Once evaluating an output costs what producing it costs, which is what happens when you have to read the novel to judge the novel, reinforcement learning dies of economics before it dies of philosophy.

Density. Does the verifier speak once per ten-thousand token episode, or does it grade every step? One sparse perfect bit and a dense stream of noisy feedback produce very different learners. Much of the recent progress in reasoning models is really progress in densifying reward.

Robustness. How fast does satisfying the verifier come apart from being good when a strong optimizer is pointed at it? Every verifier is a proxy and every proxy breaks somewhere. Reward hacking is this parameter, measured the hard way.

Through this lens the last two years reorganize. Process reward models, judge pipelines, debate protocols, the formal methods revival, prover-verifier games, the quiet money going into evaluation infrastructure. These are not separate research threads. They are all verifier engineering. When the history gets written, the breakthroughs will be credited to models and the causal story will run through verifiers.

The frontier moves twice

Verifiers do not only unlock capability in a domain. They reshape the domain.

We have run this experiment on ourselves. Software engineering was not always organized around test suites. We restructured the work so more of it would be checkable, because checkable work is manageable work. Standardized testing did this to education, metrics did it to management, citations did it to science. A cheap verifier appears and the activity reorganizes around whatever the verifier can see, sometimes for the better and demonstrably sometimes not.

AI accelerates this. As verifiers improve in a domain, the work restructures to become more verifiable, because that is where the automation gains are.

This cuts both ways. It is why AI will reach further than today's frontier suggests, and it is also a warning. The parts of a job that resist verification do not disappear, they concentrate. What stays human for a while is whatever nobody has managed to build a checker for.

Some predictions

Progress in a domain tracks verifier quality with a short lag, which will keep producing timeline surprises in both directions. Domains that look far away will fall quickly once someone ships a good verifier. Large parts of formal science, hardware design, and experimental biology are in that group, since the lab result is the verifier if you can automate the lab. Domains that look adjacent to solved ones will stall for years because their verifiers are quietly terrible. Long-horizon agency is the big one. Agents that are brilliant for five minutes and unreliable for five hours are not missing an architectural insight. We have no cheap, sound, dense verifier for whether a multi-day trajectory is going well. Whoever builds one, probably by checking plans against subgoals against actions, solves agents.

Domains whose best verifier is a language model judge will show a signature: fast early progress, then a plateau that looks like a capability ceiling but is really the model learning to exploit the judge faster than the judge improves. Look for it in open-ended writing, taste-dependent design, and safety training. When progress stalls in a judge-verified domain, the answer is not more compute on the student. It is more compute on the teacher.

In any domain you care about, verifier engineering is higher leverage than data collection or model scale. Frontier labs have partly figured this out. The rest of the ecosystem has not. There are a thousand startups building agents and a handful building verifiers, that ratio is backwards. If you are an expert in law, medicine, materials, or finance, any highly regulated field, the most valuable thing you can do is not fine-tuning models. It is to formalize what correct means in your domain and compress your judgment into a checking procedure with good specs. Do that and you write the curriculum for superhuman performance in your field.

Implications for alignment

Which tasks score badly on all four parameters at once? Mostly the ones that matter for safety. Whether a plan has acceptable long-term consequences. Whether a model is deceiving you. Whether results are being reported honestly. Whether a system's values hold up off distribution. The feedback arrives in years, the ground truth is contested, and the thing being checked may be smarter than the thing checking it.

This is why alignment is hard. We are using a training paradigm whose power scales with verifier quality to build minds whose most consequential properties are those we verify the worst. Capability flows into the well-verified basins. Oversight lives in the badlands, and the gap widens on its own.

Debate, amplification, weak-to-strong generalization, interpretability: scalable oversight is verifier engineering aimed at the hardest cases, attempted early. Every verifier approximates some ideal judgment we cannot afford to run. How far each approximation stretches before it breaks is a science we do not yet have.

Bottlenecks are where the leverage is

For seventy years computing was a story about generation, machines that could produce more. That story is close to finished. Generation is becoming abundant, then cheap, then effectively free.

What is not free is knowing whether generated outputs are good. Every domain that learns to check itself gets transformed within a few years. Every domain that cannot will wait, no matter how much intelligence we point at it. The most important open problems are really verification problems.

The useful thing about a bottleneck is that it tells you where effort compounds. Work anywhere else and your gains are capped by the constraint. We spent the last century building the answer machines. The bottlenecks are now the answer keys.