Every team using AI to make design work says it keeps a human in the loop. Press for what that means and the answer is usually "a designer looks at it before it ships." One person, glancing at whatever the agent produced, at whatever stage they happen to catch it. That isn't human-in-the-loop design. That's a person standing near the exit hoping to spot problems on their way out the door.
Real human-in-the-loop is a workflow with defined gates: specific checkpoints where a named person decides whether the work advances, using a known standard, before it moves to the next stage. The agent generates. A gate catches. A human approves or returns. Nothing skips ahead. Build it that way and you get the speed of AI with the judgment of a designer. Leave it as a vibe and you get the speed of AI with the quality of luck.
This piece lays out a gate model you can drop into a small team, walks one real feature through all four gates, shows how to size the gates to risk, names the three ways teams get this wrong, and ends with a step you can take this week.
Why "a human reviews it" fails
Every team using AI to make design work says it keeps a human in the loop.
The glance-at-the-exit model breaks for three reasons.
It catches problems too late. If the only review happens right before launch, a structural mistake, wrong information architecture, a missing flow, gets discovered after the polish is done. Now you're either shipping a flawed screen or throwing away finished work. A gate earlier in the process catches the same problem when it's cheap to fix.
It has no standard. "Looks good to me" depends entirely on who's looking and how much coffee they've had. Two reviewers approve different things. The same reviewer approves different things on different days. Without a checklist, approval means "nobody noticed anything," which is not the same as "this is right."
It has no owner. When review is everyone's job in the abstract, it's no one's job in practice. Work ships because each person assumed someone else checked. On a small team moving fast, this is how the broken page goes out.
Gates fix all three: they place the check at the right moment, tie it to a standard, and put a name on it.
The gate model
Four gates carry a piece of work from prompt to production. Not every project needs all four, but the sequence is the same, and the rule is absolute: work advances only when the current gate passes.
Gate 1 — Brief. Before anyone prompts an agent, a human approves the brief. What are we making, for which user, to what end, within which constraints. Agents produce plausible work from vague briefs and correct work from precise ones, so the brief is the highest-leverage gate. Skipping it means reviewing output against a target nobody agreed on. The brief is becoming the real deliverable in an AI workflow, and it deserves a checkpoint.
Gate 2 — Structure. Once the agent generates a first pass, review structure before surface: intent, information architecture, whether the flow does the job. This gate exists to catch the expensive mistakes early, while they cost a re-prompt instead of a rebuild. Approve the bones, then let polish continue.
Gate 3 — Quality. Before anything customer-facing ships, run a full QA pass: states, accessibility, system fidelity, content. This is the gate that stops broken work from reaching users, and it's the one most teams skip because the screen already looks finished. A finished-looking screen with no empty state and failing contrast is exactly what this gate is for.
Gate 4 — Ship. A final owner confirms the work is live-ready: rights cleared on any generated assets, analytics in place, nothing left in a placeholder state. Small, fast, and the last name on the record.
Between gates, the agent and the individual designer move freely. The gates aren't there to slow the making. They're there to stop unreviewed work from advancing a stage it hasn't earned.
The gates in action: one feature, four checkpoints
Say the team is building a "share this report" feature. Watch it move through the gates.
At Gate 1, the designer writes a brief: a logged-in user needs to share a report by link or email, control whether the link expires, and see who has access. The lead reads it and returns it once, because it doesn't say what a user without sharing permissions should see. The designer adds that case. Now the brief is approved, and the agent has a real target instead of "build a share feature."
The agent generates a first pass. At Gate 2, a senior designer looks only at structure. The flow works, but the permissions control is buried in a secondary modal when it's central to the task, and the "who has access" list sits below the fold. Returned with two specific notes. The agent regenerates, the bones are right, and the gate passes. No time wasted polishing a layout that was structurally wrong.
Polish continues. At Gate 3, whoever runs QA finds the failures the happy path hid: no empty state for a report shared with nobody yet, no error state for an expired link, a "Copy link" button at 3:1 contrast, and access-list rows that assume five people and break at fifty. All fixed before a user ever sees them.
At Gate 4, the ship owner confirms the generated illustration in the empty state is one the team has rights to use, checks that the share events are tracked, and confirms no placeholder copy survived. It ships.
Four checkpoints, each catching a different class of problem at the moment it was cheapest to fix. The glance-at-the-exit model would have caught the contrast issue, maybe, and shipped everything else.
Who owns each gate
A gate without an owner is a suggestion. Assign one named person per gate. On a small team, one or two people often cover all four, and that's fine, as long as the name is explicit and the person knows the gate is theirs.
- Brief gate: the design lead, or whoever owns the outcome. They approve the target.
- Structure gate: a senior designer. They approve the bones.
- Quality gate: whoever runs QA, against the checklist. They approve or return with specific fixes.
- Ship gate: the person accountable for what's live. They own the consequences.
Ownership does two things. It gives everyone a clear address for "who do I send this to," which removes the stall where work sits waiting for an unnamed reviewer. And it puts accountability on a human, so "the AI made it" never becomes an excuse for a shipped mistake. That accountability is worth writing down; it belongs in a short AI design policy alongside who approves what.
What each gate checks
A gate is only as good as its standard. Give each one a short, explicit checklist so approval means something.
The structure and quality gates carry the most weight, and they map directly onto a design QA rubric: intent and information architecture at Gate 2, then states, accessibility, system fidelity, and content at Gate 3. Point your reviewers at that rubric so they're checking the same things every time, in the same order, and logging what failed. The log matters more than it looks: a record of what your agent gets wrong at each gate becomes the raw material for better prompts, which raises the quality of the first pass and lightens the review load over time. Building that trust in AI output is a compounding process, not a one-time setting, and we go deeper on it in designing AI features users trust.
Right-size the gates to the risk
Running four gates on a throwaway concept is bureaucracy. Running zero on a checkout flow is negligence. Match the gates to what a mistake would cost.
- Internal or throwaway work (a concept to test an idea, an internal tool nobody outside sees): no mandatory gates. Let people move.
- Low-stakes external work (a minor marketing asset, a blog header): a single quality gate before it ships.
- Standard customer-facing work (a new page, a feature screen): structure and quality gates.
- High-stakes work (anything handling money, personal data, or core flows; anything legal or compliance-adjacent): all four gates, and the ship owner is senior.
The principle is that the number of gates rises with the cost of getting it wrong. A team that applies this stops resenting the process, because the process only shows up where it earns its place.
Three ways gates go wrong
Teams break this in predictable ways. Name them so you can avoid them.
Gate theater. The gate exists on paper, the reviewer clicks approve without checking, and everyone feels covered while nothing gets caught. The fix is a real standard the reviewer runs against, so approval requires actually looking, not just clicking.
The bottleneck reviewer. One person owns every gate, gets buried, and work sits for days waiting on them. The team learns that the gate means delay, and starts routing around it. The fix is a same-day response expectation and, past a certain size, more than one qualified reviewer per gate.
The gate that never returns anything. If a gate has approved every single thing for months, it isn't a gate, it's a rubber stamp, and it's costing time for no benefit. Either the standard is too loose or the gate is in the wrong place. Retire it or sharpen it.
Start Monday
You don't need to design the whole system to begin. This week, add one gate: the structure gate. On the next customer-facing thing an agent generates, before anyone polishes it, have one senior person check intent and information architecture and either approve or return it with specific notes. That single checkpoint catches the most expensive class of mistake, the structural one, at the cheapest possible moment. Once it's habit, add the quality gate. Build the workflow one gate at a time, and keep it from sprawling the same way you keep your stack from becoming design tool sprawl.
The teams that will ship well with AI aren't the ones with a human hovering near the exit. They're the ones who decided, in advance, exactly where a person steps in, what that person checks, and whose name is on the decision. Design the gates once. Then let the agent run.