The Skeptic Shortage

There's a new phrase making the rounds among the people who build with AI for a living: loop engineering. It surfaced in a single week of June 2026 - a viral post here, a Claude Code lead there ("my job is to write loops"), a name pinned on it a few days later. The idea is simple and a little vertiginous. You stop prompting an AI one task at a time and instead build a small machine that prompts it for you: it wakes up on a schedule, finds its own work, does it, saves what it learned, and goes around again. While you sleep.

Everyone is excited about the part where the machine cooks. I want to talk about the part almost no one is building - the part where someone is still allowed to send a dish back.

The Machine That Cooks a Thousand Meals

Here is the cleanest way I've seen it put. Loop engineering is the difference between cooking every meal yourself and running a kitchen. You stop chopping vegetables and start designing the kitchen, writing the recipes, and - most importantly - hiring a taste-tester who is allowed to refuse a plate. The moment you stop tasting the food yourself is the moment things quietly go wrong. Because a kitchen that can plate a thousand meals a night can also send out a thousand bad ones before anyone looks.

That's the whole risk of a loop, and it hides in the math. Think of the layers under one of these systems as a stack. At the bottom, prompt engineering: one good sentence. Above it, context engineering: what's in the model's window right now. Above that, harness engineering: the tools and actions of a single run. And at the top, loop engineering: making the run repeat itself, unattended, indefinitely.

Each layer up, the unit of concern grows one size - and the blast radius of a mistake grows with it. A bug at the prompt layer is one wrong answer you see instantly and shrug off. The same bug at the loop layer gets written into a state file, read back tomorrow as fact, built on the day after, until the wrong assumption is load-bearing and nobody remembers laying it. The cost of a mistake scales with the number of turns it survives before someone catches it. And a loop is, by construction, a machine for maximizing turns.

Which reveals the real economics of this whole era. Loops make generation nearly free - code, plans, pull requests, fixes, all of it produced at a rate no human keyboard can match. And when generation is free, it stops being the scarce thing. The only scarce resource left is judgment: the capacity to look at all that cheap output and say, credibly, which of it is wrong.

Why a Generator Can't Grade Itself

The obvious fix is to ask the AI to check its own work. It doesn't work, and the reason it doesn't work is structural, not a matter of better wording.

An agent that just wrote a piece of code is full of the reasons the code is right. Its context window is stuffed with the plan, the rationale, the small justifications it made along the way. Ask it to grade what it produced and it will praise it - not because it's dishonest, but because it is, quite literally, arguing from the position of the author. You cannot get a skeptical read from the mind that just did the convincing.

So the people who build serious loops separate the roles. A generator produces. A distinct evaluator judges - and the evaluator is engineered to be a genuine skeptic. It starts from doubt: assume this is broken until proven otherwise. It acts rather than reads - it doesn't eyeball the code, it hooks into a browser, clicks the actual button, screenshots the actual result. And it hands the final verdict to a fresh, cheap model judging one explicit stop condition, with none of the author's context to seduce it. One researcher who has built these put it precisely: tuning an independent skeptic is far more tractable than making a generator critical of its own work.

And this is exactly where the whole field is lopsided. Every incentive rewards building generators, because a generator produces visible output - a demo, a merged PR, a shipped feature. An evaluator's best output is the word no. It's invisible when it works and only noticed when it fails. So we ship generator-first, tool after tool, and the judge layer stays thin. Which means the failures, and all the unmet demand, are piling up in the exact place nobody is staffing. The contrarian bet of the next two years isn't that prompting is the valuable skill. It's that calibrating skeptics is - and the person who can build an evaluator good enough to gate a thousand agents is worth more than the person who built a slightly better generator.

Maker-Checker Is 500 Years Old

The reassuring part is that we've solved this before, in a domain that had no choice but to get it right: banking.

The oldest control in finance is the maker-checker rule. Whoever enters a large transfer and whoever approves it must be two different people. Not because either is untrustworthy, but because a single mind, however careful, cannot be both the source and the check on itself. The bank didn't discover this from theory. It discovered it from losses. Centuries of them.

The generator/evaluator split is maker-checker, rediscovered by the AI world under a new name and, mostly, from the same teacher - pain. It also rhymes with something newer: the way generative adversarial networks learned to make convincing images, with one network building and a second network whose entire job was to spot the fakes. The pattern keeps reappearing because it's not a trick. It's a law. Anything that produces at scale needs an independent thing that refuses at scale, or it drowns in its own confident output.

You can see the law working at the top end. Stripe runs an internal system that merges more than 1,300 pull requests a week, none of them hand-written, with a thousand-plus agents working at once. The thing people assume made that possible is a bigger, smarter model. It isn't. It's a fork of an open-source tool, made reliable by deterministic gates - a hard-coded linter, hard-coded tests, a commit step the agent is not allowed to skip. The reliability came from the constraints, not the model size. And every one of those 1,300 machine PRs is still human-reviewed. The human didn't leave. The human changed desks - from writing the code to checking it.

The Trust Inversion

Here's the story that made me reorder my whole sense of where AI is useful.

A product manager at a frontier lab pointed an AI agent at his own tax documents and asked it to produce a full return. Then he did something most people wouldn't bother with: he A/B'd the machine's version against the one his human accountant had prepared. The agent - which knew nothing about him, had no relationship, no domain reputation, no years of training in tax law - caught an income source the paid professional had missed.

Sit with the shape of that, because it's the opposite of the story we tell. The story we tell is "AI does the work, an expert checks it." What actually happened was the inversion: the expert did the work, and a zero-knowledge agent was the better checker. Its ignorance was the feature. It had no prior belief to defend, no fatigue, no "I've filed a thousand of these and it's always fine." It just read every line as if it might be wrong - which is precisely what a skeptic is supposed to do and precisely what expensive expertise, over time, forgets how to do.

The underexploited use of these agents isn't producing analysis. We have too much analysis. It's adversarially verifying the analysis we already trust - the tax return, the trade thesis, the contract clause, the model output. Checking is a distinct, high-trust job, and it's the one the market hasn't priced yet, because it's less fun to demo than a thing that writes.

Staff the Skeptic

I run a fleet of these loops myself - trading systems that scan for signals, grade them, size positions, and log the results while I'm asleep. So I'll tell you where the failure actually shows up, because it's not exotic. The single most likely sin of a self-running loop is the nodding loop: a generator quietly rating its own output as good. The signal scanner that also decides its signals are strong. It's the tax accountant who's filed a thousand returns, wearing a machine's face. It nods, and nods, and the charts stay green right up until the morning they don't.

The fix isn't a better model. It's discipline you decide on up front, before the loop ever runs. Split the maker from the checker, and make the checker a real skeptic - one that acts instead of reads and defaults to doubt. Hard-code every gate that deterministic logic can handle - the risk caps, the position limits, the entry filters - and hand only the genuinely-judgment slice to the probabilistic model. Put caps on everything, because a loop without caps has delegated its spending authority to its own bugs, and eventually a bug will spin idle all night and turn a curiosity in the logs into a line item on an invoice. And keep at least one door open on purpose - one checkpoint where the loop pauses for a human. Not because the human will always intervene, but because the pause is what keeps them able to. Weld every door shut and you'll discover, on the day you finally need to go in, that you no longer hold the key.

The uncomfortable truth under all of it: the same loop makes the disciplined builder stronger and the lazy one hollow, six months apart, from the identical tool. It multiplies whatever you bring to it. Bring understanding and it compounds understanding; bring "just ship it" and it compounds the mess at a thousand PRs a week. The difference between those two futures is one or two checkpoints, decided at the start, and a willingness to build the thing that says no.

Everyone is racing to build the maker. The whole game is going to be won by whoever finally staffs the checker.