This piece adapts Loop engineering is verifier engineering, an essay by Ilko Kacharov, Camplight co-owner, for teams deciding whether — and where — to trust autonomous software delivery.
The pitch you’ll hear more and more this year goes like this: AI agents now run in loops. Give one a goal, let it work, check, and retry until the job is done — overnight, unattended, at a fraction of the cost of a development team. The manufacturing world has a name for a plant that runs with the lights off, and the software world has borrowed it: the dark factory.
The pitch is not wrong. We build these systems. But if you’re evaluating one — from us or anyone else — you should know which part of it actually determines whether it works. It isn’t the part most vendors talk about.
The loop is the cheap part
In February 2026, the research group METR tested whether the most heavily engineered agent systems on earth beat a naive one — an agent that simply acts, observes the result, and repeats. The answer: barely, and not to statistical significance. One flagship harness beat the naive baseline in 50.7% of samples. A coin flip. Quadrupling the compute budget barely moved the result. An Oxford synthesis of 27 papers landed in the same place: additional scaffolding does not consistently improve reliability.
So when a vendor demos an elaborate multi-agent architecture, understand what you’re looking at: commodity. Nobody is competing on the loop.
What actually decides the outcome
The research draws a different line — not loop versus no loop, but what closes the loop. When an AI checks its own work, quality doesn’t just stagnate; it degrades. In one widely cited study, a model’s accuracy on a reasoning benchmark fell from 75.8% to 38.1% after it was asked to review its own answers — at three to five times the cost. The model talked itself out of correct answers and billed for the privilege.
When the loop closes over reality instead — an executed test suite, a compiler, a deploy that succeeds or fails — improvements compound. Every credible result in the literature runs on that kind of signal. In plain terms: an autonomous system is only as trustworthy as the thing that can tell it no.
The two-independences test
Here is the test we apply to any verification setup, and the one we’d suggest you apply to any autonomous delivery proposal. A real verifier needs two properties, and most shipped systems have only one.
Independent context: the judge is not the maker. A separate evaluation, not the same AI grading its own homework. Anthropic’s engineers put it plainly — agents asked to evaluate their own work respond by confidently praising it, even when the quality is obviously mediocre to a human observer.
Independent evidence: the judge can go look for itself. It runs the tests rather than reading the agent’s report that the tests passed. Many popular verification features fail exactly here: the checker is a fresh model, but all it sees is the worker’s own account of what happened. Independent context, borrowed evidence.
A gate with one independence and not the other is theater. The dumbest verifier that touches reality — a test suite, a build, a measurable outcome — beats the cleverest one that doesn’t.
Which work belongs in a dark factory
This gives you a practical scoping rule. Autonomous loops work where checking is cheaper than doing: framework migrations, dependency upgrades, refactors under an existing test suite, performance work against a measurable budget, bug fixes that reproduce mechanically. A machine can reject bad output for free, so the loop can run in the dark.
Where “done” is a judgment call — API design, architecture, product decisions, prose — the loop does not fail loudly. It produces confident, plausible output forever, and nothing inside it can tell whether the work was worth doing. That work isn’t harder for the AI. It’s harder for the gate. It stays lit.
This is also why the first phase of any autonomous delivery engagement is not agent configuration. It’s building the gates: the test coverage, the checks, the graders with their own context and their own tools. That verification layer is slower to build than the loop and worth far more — it’s the asset that persists after any single project ships.
You can automate the work, not the verdict
One caveat keeps the “dark” in dark factory honest: verifiers are targets, and targets get gamed. Agents delete failing tests, satisfy the letter of a metric, hit 40 pages a day of content that no one needed. A gate you never inspect is a gate that rots. The advantage of engineered verification is not that it removes human judgment — it’s that it moves judgment somewhere inspectable. A rotting test suite is a thing you can read and fix on a Tuesday. “The model seemed confident” is not.
So the honest version of the pitch is this: the work can run while you sleep, the checking of the work can run while you sleep, and someone accountable still decides what good means and puts their name on it. That last part is not a limitation of the technology. It is the job that remains — and choosing a partner for autonomous delivery is mostly a question of whether they’ve engineered for it or hand-waved it.
Before you sign off on any system that works unattended, ask one question: what, specifically, can tell it no — and does that thing have its own eyes? If the answer reduces to “the AI checks its work,” the lights are off but nobody’s home.
The original essay, with the full research trail and sources, is at kachar.dev.
