Who verifies the verifier?
Andrej Karpathy’s automation thesis points to a new engineering investment: executable evidence that an agent solved the right problem.
Editorial image for Who verifies the verifier?VIBECIO Editorial Desk ·
A software team can now generate a convincing implementation faster than it can agree on what would make the implementation correct. That imbalance changes the economics of testing. An acceptance test is more than a final obstacle before release: it can become the mechanism that lets an agent make useful progress without a person examining every intermediate step. A mistaken acceptance test can give the same autonomy to the wrong objective.
Andrej Karpathy’s November 2025 essay “Verifiability” frames this distinction at the level of the computing paradigm. He argues that tasks become more amenable to optimization when attempts can be repeated, evaluated efficiently, and rewarded. This helps explain why progress varies across tasks. A correct answer to a bounded problem is easier to establish than the quality of a strategic decision whose consequences emerge over years.
An executable definition of progress
Karpathy’s autoresearch repository turns that idea into a deliberately constrained system. An agent modifies a training file, runs an experiment within a fixed time budget, and compares a validation metric. Data preparation and evaluation are held apart from the editable training code. The human can revise the instructions that direct the experiment loop. This arrangement creates a tractable search problem; it does not establish a general method for accepting arbitrary production software.
The enterprise implication is to invest in the boundary around a delegated task. “Improve the service” offers little guidance on which tradeoffs are acceptable. “Reduce the latency of this operation while preserving these outputs, permissions, and resource limits” creates a more useful contract. Even then, the contract needs adversarial attention: which important behavior could disappear while every listed condition continues to pass?
For a hypothetical account-transfer feature, happy-path tests might confirm that the sender’s balance decreases and the receiver’s increases. A stronger specification also asks what happens when the request is duplicated, one side of the update fails, the actor loses permission, or concurrent requests arrive. These cases express the nature of the business operation. They are not optional embellishments to otherwise correct code.
The harness determines what the agents can see
Nicholas Carlini’s Anthropic compiler experiment is revealing for its supervision design. He describes agents making progress through tests and feedback, then colliding on the same failure when Linux compilation became one large shared task. Comparing subsets against GCC helped isolate independent work. He also reports regressions, enforcement changes, and remaining compiler limitations. The experiment demonstrates how much task structure matters alongside model capability.
Our inference is that adding agents should follow a decomposition of the evidence. If ten workers all encounter one opaque failure, ten concurrent attempts may increase coordination costs. If the harness identifies separate failing cases with stable inputs and interpretable outputs, parallelism has somewhere useful to go. The deciding factor is whether the work can be divided without losing the property the team is trying to preserve.
Correct code can implement an incorrect assumption
Karpathy’s earlier MenuGen account provides a smaller example. A generated payment integration attempted to associate purchased credits with an account by matching email addresses. He recognized that a checkout email could differ from the login email. The failure was a mistaken identity relationship, not an inability to produce syntactically plausible code.
That distinction should shape review. Ask a reviewer to examine the assumed relationship between records, the owner of a permission, and the source of an authoritative value. A test suite generated from the same mistaken assumption can simply confirm the mistake. Independent fixtures, examples supplied by domain experts, and comparison with actual system behavior give verification additional grounds beyond the implementation’s own explanation.
Treat acceptance rules as production assets
A practical engineering program versions acceptance rules and records why they exist. Changes to the verifier deserve review separate from changes to the implementation. If a new feature requires adjusting an expected outcome, the reviewer should be able to tell whether the requirement changed or the test became more permissive to make a failing run pass.
The organization also needs a route for evidence that arrives late. A deployment can satisfy pre-release checks and still reveal an unmodeled condition. A useful incident review converts that discovery into a reproducible case, updates the operating limits, and identifies who may authorize another attempt. This is how delegated work becomes more dependable over time without pretending that a test suite can anticipate everything.
The investment case is broader than fewer defects. Better verification can reduce the human attention required for each additional implementation attempt. It lets a team direct more computational effort toward work it can recognize as correct. The scarce capability is then the ability to formulate, challenge, and maintain that definition of correct. Engineering accountability moves with the work; it does not disappear when the code arrives automatically.
Sources