Human-in-the-loop: When should AI stop and ask for permission

Imagine if you asked an AI assistant to comb a Figma file before the demo. A minute later, he renamed 80 layers, removed the “extra” frames from the archive, repainted half of the components into a new primary and compiled everything into the main branch of the Git plugin. Technically completed the task. In fact, he erased three days of work by a colleague who kept drafts in the same file.

It's not a horror story about a machine uprising. This is a typical scenario when AI is too confident in its authority and the person is too confident in AI. Human-in-the-loop (HITL) is not a fashionable term from the discourse, but a specific design principle: where exactly in the flow of work AI is obliged to stop, show intent and wait for confirmation.

The more powerful the agents become – Figma MCP, Cursor, Claude Code, custom pipelines on n8n – the more often the problem is not that AI failed. It's about doing too well and too fast, in the wrong direction.

## Why is this even a problem

Previously, the interface was clear: the user clicked and the system responded. One click, one action. AI breaks that logic. One phrase in a chat can generate dozens of operations: reading files, writing, deleting, network requests, changes in shared documents.

And here's the trust gap:

• The user thinks he has agreed to "file help.".
• AI understood this as “do what you want with all the content.”.
• To roll back change is often either impossible or very expensive.

### Three types of error price

Before designing checkpoints, it is useful to separate actions by reversibility.

• ** Cheap and reversible.** Illuminate the layer, offer a copywriting option, generate a draft in a separate frame. To ask here every time is to stifle the flow.
• Expensive but reversible. Mass renaming, component refactoring, token migration. You can roll back, but it's work hours and nerves.
• Irreversible or external. Commit to main, send a letter, publish to Figma Community, delete files, pay by API, change in production base.

The rule is simple: the farther to the right on this list, the louder and clearer the stop should be.

## Where should AI be asking

A good HITL is not “confirm action” every step of the way. It is a set of conscious checkpoints placed where the price of error is higher than the price of friction.

### Checkpoint 1: before blast radius > 1 object

If an operation involves one layer, one message, one file, you can usually do it. If she touches 10, 100, 1000, be sure to show the list and ask.

On the review, it looks like this: AI says not “renamed 240 layers”, but “found 240 layers to rename, here are the first 10 examples – continue?”.

### Checkpoint 2: Before External Effects

Anything outside the local sandbox:

• sending to Slack, email, messengers;
• commites, pushy, PR, merzhi;
• publication, sharing of links;
• requests for paid APIs;
• rights/access activities.

Here, even one action requires confirmation. Not because AI will fail, but because you can’t retract a message seen by the team.

### Checkpoint 3: Before irreversible removal

Delete frames, branches, files, records in the database. Recycle bin and git history don’t always work: in Figma, remote components break instants throughout the file instantly.

### Checkpoint 4: Change of intent

It's a subtle case. The user asked to “clean the indentations”, and AI on the way decided to “at the same time bring colors to the tokens”. Even if it is useful, it is a new task. Right behavior: finish the original, show the second sentence, wait for the "yes.".

## Anti-patterns that occur most often

• Blind "Apply all." AI shows 40 sentences and one "accept everything" button. A person presses because it is lazy to click 40 times. It's not HITL, it's an imitation.
• Confirmation without context. Perform 17 operations? Yes/No. No list, no examples, no diff. There is nothing to confirm here - only guess.
• Confirmation after the fact. "Did I do X. roll back?" sounds polite, but this is no longer a loop, but a notification. It is especially dangerous for external actions.
• Dialog fatigue. AI asks literally everything, a person gets used to crushing Enter in a day, and at the moment of a really dangerous action does it on the machine.

## Quick checklist for the team

If you are implementing an AI feature, go through these issues before the release:

• For each action of the agent, the blast radius is clear: 1 object, N objects, external effect.
• Irreversible actions require explicit confirmation with a preview.
• The confirmation shows exactly what will happen, not how many operations.
• There is a “undo” for anything that can be rolled back, and there is no undo illusion for something that cannot be rolled back.
• AI does not mix multiple intentions in one confirmation.
• The “man presses Enter without looking” scenario does not lead to disaster.

In short, HITL is not about distrust of the model. This is about interface design, in which a person has real, not decorative control over expensive and irreversible actions. Next, we will understand how to place checkpoints in specific pipelines - from Figma plugins to agents in IDE.

## Workflow: how to embed HITL in a real Pipeline

Checkpoints on paper are half the story. What’s more important is that they work within the specific tool the team is working with. Figma-plugin, agent in IDE, bot in Slack, token migration script – everywhere stops look different, but the logic is the same: first intention, then preview, then action.

### Step 1. Describe intent in words

Before the agent does something, he formulates the plan in natural language: “I will walk through the 18 screens in the Onboarding v3 file, replace hex values with tokens from the Core/Color library, do not touch texts and autolayouts.” This is an insurance against changing intentions on the go: if there is no “removal of unused styles” in the plan, it does not, even if you really want to.

### Step 2. Show me dry-run

Any agent who is going to do more than five operations should be able to dry-run: “Here’s what I’m going to do, nothing has been applied yet.” In Figma, it is a separate before/after frame. In IDE, diff. In the script - log to the console without writing to the database. If dry-run is technically impossible, it is a signal that it is too early to give the feature to the user.

### Step 3. Confirmation with chance to narrow scope

A good confirmation is not "Yes/No" but "Yes/Yes/Only these/No." A person should be able to uncheck three odd cases and apply the other 37. Binary choice makes you either accept garbage or cancel useful work.

### Step 4. Journal application

After confirmation, the agent writes what exactly he did and leaves a pullback point. Not "ready," but "updated 37 layers, log here, undo - Cmd+Z or button below.".

## How to Diagnose if HITL is Broken

Often the problem is not that there are no confirmations, but that they exist but do not work. Symptoms by which this can be seen:

• On the team, someone regularly says, "Oh, I pressed the wrong way.".
• Confirmations slip through without looking - because they are the same for safe and dangerous actions.
• After the work of the agent, it takes time to “fix what he has done.”.
• No one remembers exactly what the agent did yesterday - no log.
• In retro stories pop up "he decided it was better.".

If one point is repeated, it is not user negligence, it is a design debt in the product itself.

## How a designer can apply this to the layout

HITL is not a setup under the hood, it is a visible pattern in the UI. A few tricks that work almost always.

### Divide the buttons by weight

Safe action is the main color, the usual place. Expensive – secondary button, separate position. The irreversible is a destructive style and explicit verb text: not “Continue”, but “Delete 240 layers”.

### Show the object, not the quantity

“Replace the font in 14 frames” is weak. Replace Inter with SF Pro in these frames: Onboarding/Step-1, Onboarding/Step-2... The list of objects removes a person from the work of guessing.

### Make preview mandatory, not optional

If you need to click "show diff" to confirm, half will not press. The diff should be visible immediately, the button next to it.

### Protect "Enter without looking"

For destructive actions – shift the focus from the confirmation button, add a short delay, require to enter the name of the object. It’s annoying exactly once – the moment it saves the file.

## Questions for reviewing the layout with AI-action

When you bring a feature design with an agent to the review, run it through a short list:

• What exactly happens after the click is visible before the click?
• What is the scope of the action, and can it be narrowed right here?
• Is there a way to roll back, and how obvious is it?
• What will a person see if an agent makes a mistake – a mistake, silence, or false success?
• Does confirming a dangerous action differ from confirming a safe one, at least visually?
• What happens if a person closes a window in the middle of an operation?

If the answer to two questions is “don’t know,” the layout isn’t ready yet, no matter what it looks like.

## Segment summary

A working HITL consists of four steps (intention, preview, confirmation with the ability to narrow the scope, journal) and a set of visual techniques that prevent a person from accidentally agreeing to an expensive action. Next, let’s see how this unfolds into specific scenarios – from auto-generation of components to agents who control the product themselves.

## Scenario 1. Automation of Components from Prompt

The designer writes “make a product card in our style” and the agent creates a frame with a photo, price, button. Safe? Almost. It becomes dangerous when the same agent decides to “update” the existing Card/Product component at the same time, because he thinks the new version is better.

Where HITL should be:

• Before writing to the library - always confirmation, even if the change is cosmetic.
• Before replacing the props that break backward compatibility – a separate screen listing instances that will break.
• Automatic detach is never silent.

Anti-pattern: The agent creates a Card/Product v2 next to the old one and thinks it's enough. After a week in the file seven versions, no one knows which is relevant.

## Scenario 2. Massive style refactor

Replacement of color tokens, cleaning of local styles, migration from the old system to the new. This is the area where people most often regret clicking "Apply to all.".

What should be seen before confirmation:

• How many layers are affected and in which files.
• How many of them are master components and how many are instances and individual layers.
• Are there intersections with libraries that mess with other teams.
• What happens to layers that don't fit any rule -- let's skip, mark, ask separately.

If only 312 objects are affected in the confirmation, it is not a HITL, it is a lottery.

## Scenario 3. The agent who rules the code or the product

Here, HITL ceases to be a UX issue and becomes a matter of product credibility. Rules that work in practice:

• Any entry in the sale is through PR, not directly. Even if the agent is "confident.".
• Any data migration — first to copies, then preview diff, then confirmation, then execution.
• Any action that cannot be rolled back in 10 seconds is a separate class of confirmation, different visually from the usual.

Anti-pattern: Autopilot mode, in which the agent decides what to count as a routine. The routine is determined by the command in advance and in writing, not the model in the moment.

## Team context: who is responsible for the agent's decision

When an agent works alone, the person who launched it responds. When an agent works in a shared library or a shared repository, explicit rules are needed, otherwise liability is smeared.

The minimum that is worth recording:

• Who has the right to confirm actions in the shared library.
• Who sees major change notifications and in which channel.
• What is considered “large” is the threshold in numbers, not “by eye”.
• How to roll back someone else’s confirmation if it turned out to be a mistake.

Without it, there is a classic situation: the agent broke something, everyone agrees that the process is to blame, and no one specifically fixes it.

## How to check the quality of the HITL pattern

Before you roll out the agent feature, run it through four tests.

### The "new man" test

Put behind the layout a colleague who was not involved in the design. Give a task where the agent has to do something big. Watch quietly.

• Did he know what was going to happen before the click?
• Did you notice the difference between normal and dangerous confirmation?
• Could you pull back if something went wrong?

### Test 'tired on Friday'

Simulate a mode in which a person clicks quickly and does not read. If in this mode you can accidentally confirm an expensive operation - the pattern is leaky, add friction point by point: focus delay, enter the name of the object, a separate step.

### Agent Mistakes Test

Intentionally slip the agent an ambiguous case, where he is likely to decide incorrectly. Check that the person:

• sees a mistake, not a false “success”;
• understand which of the 37 actions were used and which were not;
• you can only roll back the problem ones without losing the rest.

### Test "in a week"

Open the agent's activity log from seven days ago. Do you understand what was done and why? If there is a journal, but it is impossible to read it, it is the same case that there is no journal.

## How to explain the decision to the team

HITL almost always adds steps. The product will ask why to slow down the flow, the engineer - why to place confirmations, if "and so clear." The argument that works on the review:

• Show a specific case where the lack of a step cost time or data - your own or someone else's, but real.
• Compare the cost of an extra click and the cost of a pullback. Click seconds, rollback clock and nerves.
• Distinguish between friction that irritates every day and friction that rarely works, but at the right moment. The second team is usually calm.
• Attach confirmations to action classes, not individual buttons. “All Class A actions without confirmation, Class B actions with preview, Class C actions with name input” are easier to protect than forty individual decisions.

And a separate technique: offer to measure. How many times in a month did a “dangerous” dialogue work, how many times did a person choose to “cancell” or narrow the scope? If only in one, the pattern has already paid off.

## Segment summary

In advanced scenarios, HITL is not one confirmation, but several classes of actions with different protections, clear rules of team responsibility and four simple quality tests. Next, we’ll put everything together in a working checklist and see how to build HITL into the design process from the beginning, rather than screwing it up at the end.

## Checklist: what should be in place before rolling out the agent

This checklist is not a checklist, but the minimum, without which HITL does not work. Run any agent feature on it before turning it on users.

### Before the action

• Each action is classified as safe, reversible, expensive, irreversible.
• For each class, it is described in advance what confirmation is required.
• The scope is visible: how many objects will affect, in which files, on which pages.
• You can see the agent’s intention in words, not just diff: what he wants to do and why.
• For expensive and irreversible actions – a separate visual mode, different from the usual confirmation.

### During action

• There's progress with the ability to stop, not just "undo what's already done.".
• Intermediate errors are shown immediately, not accumulated until the final.
• Partial success is seen as partial, with no disguise as "ready.".

### After the action

• There is a journal with a human-readable record: what, where, by whom, what has changed.
• The rollback works granularly: you can cancel the part without losing the rest.
• There is a way to find and roll back action in a week, not just in the current session.

If at least one item is not closed, it does not mean “not roll out”. It means knowing where the hole is, and knowingly deciding who is covering it and how.

## Anti-patterns that occur most often

### "Confirm everything."

One dialogue for the entire batch of dozens of actions. The person either presses OK without looking, or cancels everything and loses the useful part. It is treated by splitting into classes and the ability to remove ticks point by point.

### Post-factual confirmation

"Have the agent done X, Y, Z. roll back?" It's not a HITL, it's a damage notice. Confirmation, by definition, prior to action.

### Screaming red for everything

If every second action is highlighted as dangerous, the dangerous ceases to read. Red must be rare, otherwise it becomes a background.

### The "always allow" button

Tempting for speed, devastating for safety. If you really want to, let it be a setup with a clear deadline: “do not ask for an hour”, and not “never”.

### Invisible authorization

The agent acts on behalf of the person who agreed to something a month ago in a chat room. No one can recover who gave the go-ahead and when. Authorization should live alongside action, not correspondence.

### Checkmark magazine

There is a log, but it has lines like action_executed: true. Such a magazine can neither disassemble the incident nor train a beginner. If the record cannot be read aloud to a colleague, it is not.

## Questions for design review

When you look at the layout with the agent, ask not “beautiful”, but:

• What happens if a person clicks “confirm” without reading?
• What is the visual difference between reversible and irreversible?
• Where does the interface show what the agent is going to change before it does?
• Who will see the notification if the action affects the shared resource?
• What does partial failure look like, and is it different from total success?
• How do I know in a week that this action was performed by an agent and not a person?
• Is there a way to roll one action out of the batch without touching the others?
• Which of the confirmations in this float is the most frequent - and has it turned into noise?

If the answer to any of the questions is “don’t know” or “we’ll sort it out somehow” – the layout is not ready for a review, it is ready for revision.

## Practical outcome

HITL is a design task, not a model setup. It is solved at the level of action classes, visual hierarchy of confirmations, logs and command rules, who is responsible for what. The checklist above is not the ideal, but the bottom bar: if it is closed, the agent ceases to be a source of surprises and becomes a tool with which to live in production. Next, the work is simple and boring: once in a sprint to review the thresholds, clean noisy confirmations, add friction to where the incident occurred, and remove from where it interferes for no reason.