The Approve Button Illusion: Why Human-in-the-Loop Is Broken

February 24, 2026

If there's one thing the AI industry seems to agree on, it's that humans need to stay in the loop. Keep people involved, the thinking goes, and the system stays safe. Accountable. Trustworthy.

It sounds responsible. And it might even be true, in principle.

But look at how it's actually implemented in most products, and you'll quickly notice a problem. The "loop" isn't a loop. It's a button.


A Button Is Not a Decision

Picture two scenarios.

In the first, an AI agent has rewritten authentication logic for your app. It's touched the database schema, updated security protocols, and modified how sessions are handled. It shows you a summary: "Auth logic updated. Ready to merge." One button. Approve.

In the second, an AI assistant has drafted your weekly grocery order based on your usual habits. Eggs, milk, bread, the oat milk you like. It asks: "Ready to order?" One button. Approve.

The interface is identical. The physical gesture — clicking a button — is identical. But the stakes are not. In the first scenario, a misunderstood change could introduce a serious security vulnerability. In the second, worst case, you get the wrong brand of cereal.

This is what I think of as the Approve Button Illusion. We've flattened every kind of human oversight into a single, undifferentiated interaction that feels like control while providing almost none of it.


The Summary Screen Problem

The standard defense is that the human reviewed the summary before clicking. And sure — there's usually a summary. A few sentences. Maybe a bullet list of changes.

But reading a three-sentence summary of a code migration is not the same thing as understanding it. To actually own that decision, you'd need to read the diff, trace the logic, and mentally run through what happens when something breaks. A summary screen discourages all of that. It's designed to be skimmed. It invites the click.

What's worse is the false confidence it creates. When something does go wrong later, the first instinct is: "But I approved it!" The button has become a shield — a way to feel accountable without doing any of the work that accountability actually requires. The person signed off, technically. But they weren't really there.


The Control Has to Match the Stakes

If we want humans to genuinely be in the loop, the mechanism of control has to be proportional to what's at stake.

For a grocery order? A button is fine. The cost of getting it wrong is low, and friction would be annoying for no good reason.

For deploying code to production, or surfacing a medical recommendation, or executing a financial decision? A button is not enough. Genuine ownership of those outcomes requires real friction. The interface should demand engagement before it proceeds — maybe a forced question about downstream effects, maybe an explicit sign-off on specific risk factors, something that can't be completed on autopilot.

The AI can absolutely do the heavy lifting. That's the whole point of having it. But the depth of human engagement needs to match how badly things can go wrong. One button cannot carry that weight across every situation.


Why We Keep Building It This Way

So why is the single Approve button so ubiquitous? Honestly, because it's cheap and it makes everyone feel better.

Companies want a record that a human signed off — that's important for liability. Users want to feel like they're not just passive passengers. A button satisfies both needs instantly and with zero friction. It's a design shortcut that preserves the appearance of oversight while quietly hollowing out the reality of it. Nobody has to admit that they're building a rubber stamp, because it doesn't look like one.


What Better Looks Like

The fix isn't to remove approval mechanisms — it's to stop treating approval as binary. The right design differentiates.

Low stakes should feel light. A quick confirm, an easy undo, no drama. High stakes should require something real — not friction for its own sake, but genuine reasoning. If someone can't explain what happens when that null check fails, they haven't actually reviewed the change. The interface should catch that, not paper over it. And for anything irreversible — deleting a database, sending a mass communication, triggering a legal action — the UI itself should feel heavy. That kind of decision shouldn't feel like ordering a pizza.

A button doesn't make someone responsible for a decision. It makes them a witness to one. Those are genuinely different things, and we're going to keep building systems with real accountability gaps if we keep treating them as the same.

Everyone technically approved everything. Nobody actually understood anything. That's the failure mode we're drifting toward, and it's a quiet one.

Previous: Part 1 — The Doing Gap | Next: Part 3 — The Memory Tax